Proxy SOCKS5 và HTTP khác nhau thế nào? Nắm rõ trước khi cấu hình vào trình duyệt vân tay

Khi chọn proxy, phần lớn mọi người chỉ nhìn vùng, băng thông và giá, ít ai dừng lại ở cột loại proxy — HTTP hay SOCKS5. Vậy mà chính cột đó quyết định ba thứ: yêu cầu DNS phát đi từ phía nào, lưu lượng UDP có đi qua được không, và proxy có viết lại header của bạn hay không. Bình thường những điều này gần như không cảm nhận được, nhưng một khi cấu hình proxy vào môi trường trình duyệt vân tay như MakoBrowser, chúng ảnh hưởng trực tiếp đến chất lượng môi trường. Dưới đây nói rõ hai loại khác nhau ở đâu, rồi đưa ra cách chọn và quy trình cấu hình, kiểm tra hoàn chỉnh.

Khác biệt cốt lõi: một loại hiểu ngôn ngữ web, một loại chỉ chuyển tiếp dữ liệu

HTTP proxy hoạt động ở tầng ứng dụng, đọc được các yêu cầu HTTP đi qua nó nên cũng có khả năng chỉnh sửa. SOCKS5 chỉ là kênh chuyển tiếp thông dụng, không quan tâm bên trong là gì.

Khi truy cập trang http, HTTP proxy nhìn thấy địa chỉ và header của yêu cầu; khi truy cập https, trình duyệt gửi trước một yêu cầu CONNECT để tạo đường hầm, sau khi đường hầm hình thành thì nội dung không còn hiển thị với proxy — bước này được mô tả rõ trong tài liệu MDN về phương thức CONNECT. Nói cách khác, HTTP proxy xử lý HTTPS cũng dựa vào đường hầm, chỉ là năng lực của nó luôn xoay quanh giao thức HTTP.

SOCKS5 thì khác. RFC 1928 mô tả nó là lớp đệm giữa tầng ứng dụng và tầng vận chuyển, đồng thời định nghĩa ba lệnh CONNECT, BIND, UDP ASSOCIATE. Nói theo cách dễ hiểu: nó không phân tích nội dung lưu lượng, chỉ chuyển dữ liệu nguyên trạng đến đích, và chuyển không chỉ TCP.

Khác biệt khi dùng đến chủ yếu nằm ở mấy điểm sau:

• Đi được loại lưu lượng nào: HTTP proxy xử lý HTTP và HTTPS; SOCKS5 chuyển tiếp được mọi lưu lượng TCP và hỗ trợ UDP ngay từ đầu.
• Có sửa yêu cầu của bạn không: HTTP proxy nhìn thấy nội dung yêu cầu ở tầng HTTP, một số triển khai còn thêm các header như Via, X-Forwarded-For; SOCKS5 không thay đổi nội dung tầng ứng dụng.
• Cách xác thực: HTTP proxy thường dùng xác thực Basic, thông tin đăng nhập chỉ là chuỗi base64, an toàn phụ thuộc vào HTTPS; SOCKS5 có thương lượng xác thực riêng, RFC 1929 định nghĩa riêng cách dùng tên đăng nhập kèm mật khẩu.
• Thói quen cổng: dịch vụ SOCKS truyền thống chạy trên cổng 1080, nhưng nhà cung cấp cho cổng nào thì điền cổng đó.

Sau khi cấu hình vào trình duyệt vân tay, thứ thực sự gây vấn đề là DNS và UDP

Chọn sai loại proxy, vấn đề xuất hiện đầu tiên thường không phải là không kết nối được, mà là yêu cầu DNS âm thầm đi qua mạng nội bộ.

DNS được phân giải ở phía nào quyết định có rò rỉ hay không

Tên miền được phân giải ở phía nào phụ thuộc vào cấu hình của client, chứ không phải tên loại proxy. SOCKS5 hỗ trợ giao thẳng tên miền cho phía proxy xử lý — RFC 1928 định nghĩa riêng địa chỉ loại tên miền. Nhưng mặc định client không nhất thiết làm vậy: lấy Firefox làm ví dụ, phải tích ô dùng proxy DNS khi dùng SOCKS v5 thì việc phân giải mới đi qua proxy; không tích thì client phân giải tên miền thành IP ngay tại máy rồi mới giao cho proxy, yêu cầu DNS rơi vào tay nhà mạng nội bộ. Đây là nguồn rò rỉ DNS qua proxy phổ biến nhất.

HTTP proxy thường giao tên máy chủ cho proxy phân giải, nhưng cũng không nên mặc định: WebRTC kết nối trực tiếp, trình duyệt phân giải trước và lưu lượng không đi qua proxy đều có thể đẩy yêu cầu phân giải về máy nội bộ.

Kiểm tra không phức tạp. Sau khi khởi động môi trường, truy cập bất kỳ trang kiểm tra rò rỉ DNS nào, xem máy chủ phân giải thuộc vùng nào. Nếu hiển thị nhà mạng nội bộ thì việc phân giải không đi theo proxy.

Hỗ trợ UDP quan trọng khi nào

Trình duyệt khi truy cập site hỗ trợ HTTP/3 sẽ thử đi QUIC, mà QUIC dựa trên UDP. Khi proxy chỉ hỗ trợ TCP, lưu lượng tự động lùi về TCP, trang vẫn mở bình thường, hằng ngày không cảm nhận được khác biệt. Trường hợp thực sự cần SOCKS5 là khi trong môi trường còn chạy công cụ phụ thuộc UDP.

Chỉ vận hành web thì UDP không phải yếu tố quyết định; môi trường có công cụ bổ sung thì nó mới là.

Khi nào dùng SOCKS5, khi nào HTTP là đủ

Chọn loại không dựa vào cái nào cao cấp hơn, mà chỉ dựa vào cấu trúc lưu lượng của bạn và loại mà nhà cung cấp đưa ra.

Vài tiêu chí có thể đối chiếu trực tiếp:

1. Nhà cung cấp chỉ đưa loại HTTP, mà kịch bản chỉ là trình duyệt đi lưu lượng web: dùng thẳng HTTP proxy, hoàn toàn đủ.
2. Trong môi trường ngoài trình duyệt còn công cụ phụ thuộc UDP, hoặc muốn giảm bề mặt lộ DNS: ưu tiên SOCKS5.
3. Cần proxy làm cache, lọc nội dung, kiểm toán truy cập: HTTP proxy phù hợp hơn, giá trị của nó nằm ở chỗ đọc được nội dung yêu cầu.
4. Chỉ mở nhiều tài khoản để làm mạng xã hội hoặc vận hành shop: cả hai loại đều đáp ứng, khoảng cách thực sự không nằm ở giao thức.

Có hai hiểu lầm lan truyền rộng nên tách bạch. Một là cho rằng SOCKS5 chắc chắn nhanh hơn — tốc độ phụ thuộc băng thông, tải và khoảng cách đường truyền của máy chủ proxy, không liên quan trực tiếp đến loại giao thức. Hai là cho rằng SOCKS5 ẩn danh hơn — nó chỉ không thay đổi nội dung lưu lượng, chứ không giấu bạn là ai, việc có lưu log hay không tùy nhà cung cấp proxy.

Cũng cần nhắc: loại proxy chỉ là một tham số trong việc chọn. Proxy có độc quyền không, vùng có ổn định không, có đổi IP liên tục không, ảnh hưởng đến cách ly môi trường thường lớn hơn loại giao thức. Băn khoăn rất lâu về loại proxy mà lại dùng một proxy chia sẻ đổi IP liên tục thì đã sai thứ tự.

Cấu hình proxy trong trình duyệt vân tay: từ điền loại đến kiểm tra hiệu lực

Cấu hình chỉ vài bước, nhưng sai thứ tự sẽ làm lại nhiều lần. Trước tiên kiểm tra ngoài môi trường, rồi cấu hình trong môi trường, cuối cùng kiểm tra lại trong trình duyệt.

1. Xác nhận proxy hoạt động trước. Sau khi có host, cổng, loại và thông tin xác thực, hãy kiểm tra kết nối một lần ngoài môi trường, như vậy phân biệt được proxy không dùng được và cấu hình môi trường có vấn đề.

2. Mở cài đặt proxy của môi trường, chọn loại. Loại phải trùng với loại nhà cung cấp đưa. Điền proxy SOCKS5 thành HTTP sẽ không kết nối được ngay, mà thông báo lỗi thường rất mơ hồ, dễ chẩn đoán nhầm thành lỗi môi trường.

   

3. Điền host, cổng và thông tin xác thực. Có tên đăng nhập mật khẩu thì điền, chú ý đừng dán kèm khoảng trắng thừa, đây là lỗi sơ đẳng phổ biến nhất.

   

4. Sau khi lưu, chạy một lần kiểm tra proxy trong môi trường, xác nhận IP đầu ra, quốc gia và vùng đúng như mong đợi.

5. Sau khi khởi động môi trường, kiểm tra lại một lần trong trình duyệt. Tập trung vào ba mục: IP đầu ra, vị trí phân giải DNS và WebRTC.

6. Cố định lại. Một tài khoản ứng với một đầu ra cố định, đừng đổi node liên tục để trông an toàn hơn — việc đổi liên tục tự nó là một tín hiệu bất thường.

Bước 4 và bước 5 kiểm tra hai việc khác nhau: kiểm tra trong môi trường xác nhận đường proxy có thông không, kiểm tra trong trình duyệt xác nhận lưu lượng có rò rỉ đi chỗ khác không. Chỉ làm cái đầu thì rất dễ bỏ sót DNS và WebRTC.

Ba việc kiểm tra bắt buộc sau khi cấu hình

Cấu hình proxy xong không có nghĩa là đã hiệu lực; IP đầu ra, vị trí phân giải DNS và WebRTC đều phải xác nhận riêng.

• IP đầu ra và vùng: truy cập bất kỳ trang tra IP nào, xác nhận hiển thị IP của proxy chứ không phải IP máy, vùng khớp với mô tả của nhà cung cấp.
• Vị trí phân giải DNS: dùng trang kiểm tra rò rỉ DNS để xem máy chủ phân giải thuộc về đâu. Mục này trong trường hợp SOCKS5 cũng là trọng điểm, vì vị trí phân giải phụ thuộc cấu hình client, không thể mặc định.
• WebRTC: kiểm tra trình duyệt có lộ IP thật qua WebRTC không. Vấn đề này rất phổ biến ở trình duyệt thường chỉ đổi proxy mà không làm cách ly môi trường.

Còn một điểm dễ bị bỏ qua: múi giờ, ngôn ngữ và vùng hệ thống phải khớp với vùng đầu ra. Cấu hình proxy Mỹ mà múi giờ vẫn ở Đông Bát, mâu thuẫn này dễ bị chú ý hơn cả việc chọn sai loại giao thức.

Nếu trên tay có mười mấy hay vài chục môi trường cần cấu hình, cố định loại, đầu ra và vùng thành cấu hình tái sử dụng sẽ đỡ hơn điền tay mỗi lần. Đây cũng là lý do MakoBrowser quản lý proxy cùng môi trường — môi trường, tài khoản và đầu ra mạng được duy trì ở cùng một chỗ, khi đổi người tiếp nhận không cần hỏi lại tài khoản này gắn node nào. Muốn chạy thử một môi trường trước, có thể bắt đầu từ việc cài client ở trang tải về.

Câu hỏi thường gặp

SOCKS5 và HTTP proxy cái nào nhanh hơn

Không có đáp án cố định. Tốc độ phụ thuộc băng thông, tải, khoảng cách đường truyền và site đích của máy chủ proxy, ít liên quan đến loại giao thức. Thay vì băn khoăn loại, hãy xem chất lượng đường truyền của proxy.

Trình duyệt vân tay có bắt buộc dùng SOCKS5 không

Không bắt buộc. Khi chỉ chạy lưu lượng web và nhà cung cấp chỉ đưa loại HTTP thì HTTP proxy vẫn dùng được. Ưu điểm của SOCKS5 tập trung ở hỗ trợ UDP và phân giải DNS từ xa có thể kiểm soát, khi môi trường có công cụ phụ thuộc UDP thì mới ưu tiên.

Điền proxy xong rồi, sao vẫn hiện IP thật

Ba nguyên nhân phổ biến: chọn sai loại khiến proxy không thực sự hiệu lực, trình duyệt kết nối trực tiếp qua WebRTC, DNS vẫn phân giải tại máy. Làm theo thứ tự ở mục trên, cơ bản xác định được là khâu nào.

HTTP proxy có truy cập được trang HTTPS không

Được. Trình duyệt sẽ lập một đường hầm trên proxy bằng phương thức CONNECT, lưu lượng trong đường hầm được mã hóa, proxy không thấy nội dung trang cụ thể. Đây là cách chuẩn để HTTP proxy xử lý HTTPS.

Loại proxy có ảnh hưởng an toàn tài khoản không

Bản thân loại proxy không quyết định kết quả tài khoản, thứ thực sự có tác dụng là đầu ra có ổn định không, vùng có khớp tài khoản không, có đổi liên tục không. Không công cụ nào đảm bảo tài khoản không bị nền tảng xác minh, cấu hình môi trường sạch sẽ, tránh biến động bất thường mới là phần bạn kiểm soát được.