Khi proxy kết nối thất bại, hãy kiểm tra theo ba lớp: xác nhận IP và vị trí đầu ra trước, sau đó tách lỗi DNS, timeout và chứng chỉ, cuối cùng kiểm tra xác thực, cổng và giao thức.
Proxy đã được cấu hình, tên người dùng và mật khẩu cũng đúng, nhưng khi kiểm tra vẫn báo kết nối thất bại. Nhiều người lúc này lập tức liên hệ nhà cung cấp proxy, đổi node, đổi cổng hoặc thúc giục bộ phận hỗ trợ. Cách này thường kém hiệu quả vì nguyên nhân có thể nằm ở bất kỳ vị trí nào trên toàn bộ đường truyền, còn proxy chỉ là một mắt xích.
Thay vì thử thay đổi ngẫu nhiên, hãy cố định một thứ tự từ ngoài vào trong: trước tiên xác nhận đầu ra có thực sự hoạt động hay không, tiếp theo kiểm tra đường truyền có thông không, rồi mới đến xác thực và giao thức ở lớp ứng dụng. Đi hết ba lớp này sẽ định vị được phần lớn vấn đề.
Đầu ra có thực sự hoạt động không?
Bước này rất dễ bị bỏ qua vì cấu hình trông có vẻ đã thành công. Nhưng cấu hình thành công và lưu lượng thực sự đi qua proxy là hai chuyện khác nhau.
Hãy kiểm tra hai điểm. Thứ nhất, IP có thay đổi không? Ghi lại IP công khai khi không dùng proxy, bật proxy rồi kiểm tra lại. Nếu hai IP giống nhau, lưu lượng hoàn toàn không đi ra qua proxy và các bước kiểm tra sau sẽ vô ích. Thứ hai, vị trí có đúng không? Chi tiết proxy thường có quốc gia, khu vực, bang hoặc tỉnh, thành phố, tọa độ chính xác đến sáu chữ số thập phân và mã bưu chính. Hãy đối chiếu với khu vực đã mua. Nếu múi giờ hệ thống rõ ràng không khớp với khu vực đầu ra thì đó cũng là một dấu hiệu rủi ro.
Khi đầu ra không có hiệu lực, nguyên nhân thường nằm ở các thiết lập còn sót lại trên máy chứ không phải phía nhà cung cấp. Nếu công cụ mạng dùng trước đó không dọn sạch khi thoát, hệ thống có thể vẫn còn các biến môi trường như HTTP_PROXY, HTTPS_PROXY, hoặc các công tắc Web Proxy, SOCKS Proxy trên macOS vẫn bật. Khi đó client tưởng rằng mình đang đi theo proxy hệ thống nhưng yêu cầu thực tế lại bỏ qua proxy. Xóa các thiết lập còn sót rồi kiểm tra lại thường hữu ích hơn việc cấu hình lại toàn bộ proxy.
Ba lỗi thường gặp ở lớp đường truyền
Sau khi xác nhận đầu ra không có vấn đề, hãy kiểm tra xem yêu cầu có thực sự đến được đích hay không.
Phân giải DNS là điểm nghẽn đầu tiên. Biểu hiện có thể là phân giải thất bại hoặc kết quả rõ ràng sai, chẳng hạn tên miền đáng lẽ trỏ đến dịch vụ đích lại phân giải ra một địa chỉ lạ. Hãy thử dùng DNS công cộng để phân giải lại hoặc xóa cache DNS cục bộ, rồi xem có khôi phục không.
Loại thứ hai là hết thời gian kết nối. Khi cổng bị tường lửa hoặc phần mềm bảo mật chặn, yêu cầu thường quay mãi rồi timeout. Lúc này cần kiểm tra quy tắc cho phép cổng, đồng thời chú ý xem môi trường như mạng nội bộ doanh nghiệp hoặc Wi-Fi công cộng có hạn chế riêng hay không. Có một cách kiểm tra nhanh: kết nối trực tiếp mà không dùng proxy. Nếu lúc đó cũng không mở được bất kỳ website nào, vấn đề nằm ở mạng cơ bản, không liên quan đến proxy. Khởi động lại router hoặc chuyển sang điểm phát sóng di động để xác nhận.
Lỗi chứng chỉ cần được xem riêng. Khi thấy thông báo chứng chỉ không đáng tin cậy hoặc handshake thất bại, nhiều người trước tiên nghĩ rằng lưu lượng bị giải mã hoặc chứng chỉ bị thay thế. Điều đó có thể xảy ra, nhưng còn một nguyên nhân kín đáo hơn: thời gian trên máy không chính xác. Nhiều cơ chế xác thực và phiên phụ thuộc vào dấu thời gian. Nếu thời gian cục bộ lệch thời gian máy chủ hơn 5 phút, việc xác minh chữ ký có thể thất bại và kết nối bị từ chối; trên HTTPS, nó biểu hiện thành lỗi xác minh chứng chỉ. Khi gặp lỗi chứng chỉ, hãy kiểm tra luôn trạng thái đồng bộ thời gian hệ thống. Nếu bất thường, bật đồng bộ tự động, hiệu chỉnh ngay, khởi động lại client rồi thử lại.
Đừng nhập sai xác thực và giao thức
Nếu có thể kết nối đến máy chủ proxy nhưng lưu lượng vẫn không hoạt động, vấn đề phần lớn nằm ở lớp ứng dụng.
Phổ biến nhất là thông tin xác thực. Tên người dùng, mật khẩu và phương thức xác thực của proxy phải khớp với thông tin nhà cung cấp đưa ra; đổi mật khẩu nhưng không cập nhật cấu hình cũng rất thường gặp. Ở chế độ cấu hình thủ công, còn phải xác nhận số cổng đã nhập trùng với cổng mà chính công cụ proxy đang lắng nghe. Hai con số có thể trông giống nhau, nhưng nhập sai là hoàn toàn không kết nối được.
Loại thứ hai là giao thức không khớp. HTTP, HTTPS và SOCKS5 không thể dùng lẫn: nếu nhà cung cấp đưa SOCKS5 nhưng cấu hình lại chọn HTTP, kiểm tra chắc chắn thất bại. Cũng cần xác nhận proxy có cho phép truy cập website và cổng đích hay không, vì một số proxy hạn chế mục tiêu hoặc giao thức.
Cách nhanh nhất để phân biệt lỗi node và lỗi cấu hình là đổi sang một node khác để thử. Nếu đổi xong dùng được, vấn đề nằm ở node ban đầu; nếu vẫn không được, quay lại kiểm tra cấu hình và đường truyền. Đừng liên tục thay nhiều tham số cùng lúc; mỗi lần chỉ đổi một biến và ghi lại kết quả, nếu không chính thao tác của bạn có thể che mất nguyên nhân thật.
Kết nối được không có nghĩa môi trường đã dùng được
Có thêm một bẫy thường gặp. Proxy hiển thị kết nối bình thường nhưng tài khoản vẫn thường xuyên kích hoạt cơ chế kiểm soát rủi ro. Vấn đề khi đó có thể không phải có kết nối được hay không, mà là đầu ra này có giống một người dùng bình thường hay không.
Vẫn cần kiểm tra các mục quen thuộc: vị trí đầu ra có khớp với khu vực đăng ký tài khoản không; loại IP có hợp lý không, vì nền tảng có thể có mức độ tin cậy khác nhau với IP trung tâm dữ liệu và IP dân cư; IP này trước đây có bị website đích đánh dấu không? Nếu cùng một IP từng chạy nhiều hoạt động bất thường, người dùng về sau cũng có thể bị liên lụy. Sau khi kiểm tra kết nối đạt, hãy dành thêm vài phút để xác nhận độ sạch của đầu ra.
Nếu một thiết bị cần chạy nhiều môi trường, tốt nhất là đầu ra theo quan hệ một-một: mỗi môi trường có đầu ra riêng. Như vậy khi có vấn đề có thể định vị riêng, và nếu một đầu ra bị đánh dấu thì chỉ môi trường tương ứng bị ảnh hưởng thay vì tất cả cùng ngắt. Trong quản lý nhiều môi trường, PurpleMark cấu hình và cô lập đầu ra riêng cho từng môi trường chính theo logic này.
Các phương pháp khắc phục này chỉ phục vụ trao đổi kỹ thuật. Hãy sử dụng các công cụ và dịch vụ liên quan trong khuôn khổ pháp luật và quy định hiện hành.
