Proxy kết nối được chưa có nghĩa là dùng tốt. Bài viết đưa ra năm kiểm tra có thể lặp lại: đối chiếu vị trí và nhà mạng, phân biệt IP dân cư hay trung tâm dữ liệu, đo kết nối và mất gói, kiểm tra rò rỉ DNS/WebRTC, rồi theo dõi dấu hiệu IP bị đánh dấu theo thời gian.
Sau khi cấu hình proxy, việc trang web báo đã kết nối mới chỉ là bước đầu tiên. Điều thực sự quyết định môi trường có dùng được hay không nằm ở những chi tiết thường bị bỏ qua: địa chỉ thoát thuộc về ai, dải địa chỉ là dân cư hay trung tâm dữ liệu, yêu cầu DNS được gửi từ đâu và WebRTC có làm lộ địa chỉ thật hay không.
Năm mục dưới đây, kèm cách làm cụ thể, có thể kiểm tra lần lượt trong khoảng mười phút.
1. Vị trí và nhà mạng có đúng không?
Mở bất kỳ trang nào hiển thị IP hiện tại và kiểm tra ba điểm: quốc gia và thành phố có đúng khu vực bạn cần không, tên nhà mạng có khớp với nhà cung cấp đã mua không, và ASN có đúng như thông tin được công bố không.
Bước này giúp phát hiện một lỗi phổ biến: nhà cung cấp nói node ở Đức nhưng thực tế điểm thoát lại ở Mỹ. Dữ liệu giữa các cơ sở dữ liệu IP cũng có thể không đồng nhất, nên các trang tra cứu khác nhau có thể cho kết quả khác nhau. Hãy đối chiếu hai hoặc ba nguồn và lấy tổ chức đăng ký trong bản ghi whois làm chuẩn.
Đồng thời kiểm tra IPv6. Trong một số môi trường, lưu lượng trình duyệt đi qua proxy nhưng IPv6 vẫn đi ra từ mạng cục bộ. Hãy dùng trang kiểm tra chỉ IPv6 để xác nhận kết quả cũng trỏ về điểm thoát proxy. Nếu vẫn hiển thị địa chỉ thật của bạn, môi trường chỉ được che chắn một phần.
2. Dải dân cư hay dải trung tâm dữ liệu?
Loại IP còn dễ bị bỏ qua hơn vị trí nhưng ảnh hưởng thường trực tiếp hơn. IP dân cư được đăng ký cho nhà mạng băng rộng, còn IP trung tâm dữ liệu thuộc dải địa chỉ của nhà cung cấp cloud hoặc IDC. Sự khác biệt này có thể tra cứu công khai trong các cơ sở dữ liệu loại IP.
Cách đơn giản là kiểm tra tổ chức đăng ký của ASN. Tên có các từ Cloud, Hosting, Data Center hoặc VPS thường là dải trung tâm dữ liệu; còn Telecom, Broadband, Cable hoặc Communications thường là dải dân cư hoặc ISP. Kết hợp thêm reverse DNS: IP dân cư thường có bản ghi đảo do nhà mạng cấp, còn PTR của IP trung tâm dữ liệu thường theo định dạng tên miền của nhà cung cấp cloud.
Nếu dùng máy chủ cloud tự dựng làm proxy, điểm thoát chắc chắn là IP trung tâm dữ liệu. Đây là đặc điểm của hạ tầng và không thể thay đổi bằng cấu hình. Ưu điểm là ổn định, kiểm soát được và IP chỉ do bạn sử dụng; nhược điểm là loại IP. Yếu tố nào quan trọng hơn tùy vào mức độ nghiêm ngặt của cơ chế kiểm soát rủi ro trên nền tảng mục tiêu: trong tình huống ít nghiêm ngặt, dải trung tâm dữ liệu có thể vẫn ổn; còn tình huống nghiêm ngặt hơn có thể cần proxy dân cư hoặc ISP.
3. Khả năng kết nối và mất gói
Kết nối được không đồng nghĩa với ổn định. Ping trong thời gian ngắn có thể không phát hiện vấn đề; cần quan sát liên tục trong một khoảng thời gian.
Hãy ping liên tục hoặc gửi yêu cầu lặp lại tới một mục tiêu cố định vài trăm lần, rồi xem tỷ lệ mất gói và độ dao động của độ trễ. Kết quả tốt là không mất gói và độ trễ ổn định trong cùng một mức. Mất gói ngắt quãng hoặc độ trễ tăng giảm mạnh thường là dấu hiệu nghẽn tuyến hoặc thiếu băng thông. Muốn xác định chính xác đoạn nào, hãy kiểm tra theo từng chặng: trước tiên đo từ máy cục bộ tới máy chủ proxy, sau đó từ máy chủ tới trang mục tiêu. Chặng nào tệ rõ rệt thì nút thắt nằm ở đó.
Loại proxy cũng phải khớp. SSH, SOCKS5 và HTTP không thể cấu hình lẫn lộn; giao thức chọn ở client phải đúng với giao thức thực tế được mở trên server, nếu không có thể thấy kết nối nhưng lưu lượng không đi được. Cổng cũng tương tự. Nếu cổng mặc định như SSH 22 bị nhà cung cấp chặn, hãy sửa quy tắc firewall trước khi nghi ngờ mật khẩu.
4. DNS và WebRTC có bị rò rỉ không?
Hai mục này quyết định vị trí thật của bạn có thể bị lộ qua một kênh khác hay không.
Để kiểm tra rò rỉ DNS, truy cập trang hỗ trợ DNS leak test và xem yêu cầu phân giải được gửi từ node nào. Nếu resolver cuối cùng vẫn nằm ở mạng cục bộ, việc lưu lượng đi qua proxy cũng chưa đủ: nền tảng có thể suy ra khu vực thật từ vị trí phân giải DNS rồi đối chiếu với vị trí IP. Cách xử lý là bật phân giải DNS từ xa trong môi trường hoặc chọn loại proxy hỗ trợ phân giải DNS qua proxy.
Rò rỉ WebRTC khó nhận biết hơn. Trình duyệt thu thập thông tin về giao diện mạng cục bộ để phục vụ liên lạc peer-to-peer; trong một số cấu hình, nó có thể bỏ qua proxy và làm lộ địa chỉ nội bộ, thậm chí địa chỉ công khai. Mở trang kiểm tra WebRTC và xem trong các địa chỉ candidate có IP thật của bạn hay không. Nếu có, hãy tắt WebRTC trong trình duyệt hoặc cài đặt môi trường, hoặc giới hạn để nó chỉ đi qua proxy.
5. Múi giờ và ngôn ngữ có nhất quán không?
Nếu điểm thoát hiển thị ở Mỹ nhưng trình duyệt dùng giờ Bắc Kinh, ngôn ngữ tiếng Trung và phông chữ được render theo kiểu tiếng Trung, đây là một mâu thuẫn rõ ràng. Hãy đặt múi giờ, ngôn ngữ và vùng giao diện phù hợp với vị trí IP. Không cần cố tình giả lập chính xác một thành phố cụ thể.
Theo dõi lâu dài để biết IP có bị đánh dấu hay không
Các kiểm tra phía trên có thể hoàn tất trong ngày, nhưng uy tín IP chỉ đánh giá được theo thời gian. Hãy theo dõi các tín hiệu như CAPTCHA xuất hiện thường xuyên hơn trên trang mục tiêu, đăng nhập bắt đầu thường xuyên yêu cầu xác minh lần hai, các chức năng vốn hoạt động bình thường bị hạn chế, hoặc cùng một trang lập tức hoạt động bình thường trở lại khi đổi mạng.
Nếu chỉ sau vài thao tác mà xác minh đã liên tục được kích hoạt, thường có hai nguyên nhân: loại IP không phù hợp, hoặc dải địa chỉ trước đây đã được nhiều người dùng và tích lũy lịch sử. Kiểm tra các cơ sở dữ liệu chống lạm dụng có thể cho biết dải này từng bị đánh dấu hay chưa. Đây là lúc lợi thế của máy chủ tự dựng thể hiện rõ: từ ngày mua, IP chỉ do bạn dùng nên lịch sử bắt đầu sạch.
Có hai hướng xử lý thực tế: chuyển sang proxy dân cư hoặc đổi sang node ở khu vực có ít người dùng hơn.
Thứ tự nên kiểm tra ngay trong ngày cấu hình
- Dùng trang tra cứu IP để đối chiếu vị trí, nhà mạng và ASN, sau đó kiểm tra rò rỉ IPv6
- Dựa trên tổ chức đăng ký ASN và reverse DNS để xác định dải dân cư hay trung tâm dữ liệu
- Gửi vài trăm yêu cầu liên tục để xem mất gói và dao động độ trễ; nếu cần thì kiểm tra theo từng chặng
- Dùng DNS leak test và WebRTC test để xác nhận không lộ điểm thoát thật
- Đồng bộ múi giờ, ngôn ngữ và vùng giao diện với vị trí IP
Sau đó, cứ một đến hai tuần lại kiểm tra tần suất CAPTCHA và xác minh lần hai rồi ghi chép lại. Khi một đội cùng duy trì nhiều môi trường, việc cố định quan hệ giữa từng môi trường với điểm thoát và các tham số sẽ tiết kiệm rất nhiều công sức. Có thể dùng tính năng quản lý nhiều môi trường của các công cụ như PurpleMark ở bước này.
Proxy chạy được và proxy đạt yêu cầu là hai chuyện khác nhau. Cái thứ nhất chỉ cần cấu hình đúng; cái thứ hai phải kiểm tra từng mục. Những phần chưa kiểm tra — rò rỉ DNS, WebRTC và loại IP — là những yếu tố dễ âm thầm làm giảm độ tin cậy của toàn bộ môi trường nhất.
