Hướng dẫn mã lỗi proxy: Cách sửa lỗi 407, 403, 429, 502 và timeout

Mã lỗi proxy cho bạn biết request bị dừng ở tầng nào. 407 nghĩa là proxy không nhận ra bạn, 403 và 429 thường là do website đích từ chối request, còn 502 và 504 cho thấy kết nối giữa proxy và website đích đã bị đứt. Các thông báo timeout và “tunnel connection failed” cũng được đọc theo cùng logic: trước tiên hãy xác định ai tạo ra lỗi, sau đó mới sửa đúng tầng đó.

Bài hướng dẫn này chia các mã lỗi thường gặp nhất thành ba nhóm: xác thực, website đích từ chối và lỗi mạng/timeout. Với mỗi mã, bạn sẽ thấy nguyên nhân điển hình, chỗ cần kiểm tra đầu tiên và cách lỗi hiển thị trong cURL và Python. Các ví dụ dùng địa chỉ gateway của WeProxy là gw.weproxy.com.tr:8989; USER và PASSWORD là thông tin đăng nhập trong bảng điều khiển của bạn.

Ai tạo ra lỗi: proxy hay website đích?

Mỗi request qua proxy gồm hai kết nối riêng biệt. Kết nối thứ nhất nằm giữa client và proxy. Kết nối thứ hai nằm giữa proxy và website đích. Mã lỗi được tạo ra ở một trong hai kết nối này, và cách khắc phục cũng nằm ở phía đó.

Với request HTTPS, client trước tiên gửi CONNECT example.com:443 tới proxy. Nếu proxy trả về 200 Connection Established thì tunnel đã được thiết lập, và mọi mã HTTP nhận được sau đó đều thuộc về website đích. Nếu proxy không thiết lập được tunnel, lỗi sẽ nằm ngay trong phản hồi của CONNECT, chẳng hạn 407, 403, 502. Cách nhanh nhất để phân biệt là xem output của curl -v:

curl -v -x "http://USER:[email protected]:8989" https://api.ipify.org

Nếu output có dòng < HTTP/1.1 200 Connection established thì proxy đã làm xong phần việc của mình. Lỗi xuất hiện sau dòng này nghĩa là vấn đề nằm ở phía website đích. Nếu phản hồi của dòng CONNECT báo lỗi thì vấn đề nằm ở kết nối tới proxy. Với request HTTP thường (không có TLS) sẽ không có CONNECT; khi đó các header trong phản hồi như Server, Via hay cf-ray sẽ cho biết mã lỗi đến từ đâu.

Quy tắc chung:

• 407 luôn đến từ proxy.
• 403, 429 và CAPTCHA phần lớn là quyết định của website đích.
• 502, 503, 504 cho biết proxy không kết nối được tới website đích hoặc không nhận được phản hồi kịp thời.
• Lỗi phía client (curl: (7), ProxyError, ERR_PROXY_CONNECTION_FAILED) xuất hiện khi không kết nối được tới proxy, trước cả khi có mã HTTP.

407 Proxy Authentication Required

407 nghĩa là proxy không chấp nhận request khi chưa xác thực. RFC 9110 định nghĩa mã này: proxy gửi header Proxy-Authenticate trong phản hồi, và client gửi thông tin đăng nhập qua header Proxy-Authorization ở request tiếp theo.

Nguyên nhân thường gặp nhất:

1. Sai username hoặc mật khẩu. Lỗi dính khoảng trắng ở đầu hoặc cuối khi copy từ bảng điều khiển rất phổ biến.
2. Ký tự đặc biệt chưa được mã hóa. Nếu mật khẩu chứa @, :, /, # hoặc % thì phải percent-encode khi đưa vào URL proxy. Mật khẩu p@ss được viết trong URL thành p%40ss. Nếu không mã hóa, client sẽ hiểu phần sau dấu @ là host.
3. Whitelist IP không khớp. Nếu bạn xác thực bằng IP thay vì gửi thông tin đăng nhập, IP mà bạn dùng để ra ngoài phải được đăng ký trong bảng điều khiển. Nếu IP mạng nhà bạn đã đổi hoặc server đi ra bằng một địa chỉ IPv6 khác, bạn sẽ nhận 407.
4. Client không gửi thông tin đăng nhập. Một số thư viện chỉ đọc thông tin xác thực proxy từ URL, số khác lại yêu cầu một tham số riêng. Còn extension trình duyệt thì chờ một cửa sổ pop-up khi dùng proxy có mật khẩu.
5. Gói hết hạn hoặc hết số dư. Gói không còn hoạt động sẽ không được chấp nhận dù thông tin đăng nhập đúng. Hãy kiểm tra trạng thái gói trong bảng điều khiển.

Với các gói WeProxy, bạn có thể dùng đồng thời cả username/mật khẩu và whitelist IP trên HTTP lẫn SOCKS5. Nếu cần dùng thông tin đăng nhập trên nhiều công cụ, thay vì gõ tay định dạng, hãy dùng công cụ chuyển đổi định dạng proxy để chuyển qua lại giữa ip:port:user:pass và dạng URL.

Để mã hóa mật khẩu an toàn trong Python:

from urllib.parse import quote

user = "USER"
password = quote("p@ss:w0rd/1", safe="")
proxy = f"http://{user}:{password}@gw.weproxy.com.tr:8989"
proxies = {"http": proxy, "https": proxy}

403 Forbidden và 429 Too Many Requests

403 nghĩa là request đã được hiểu nhưng bị từ chối. Khi dùng proxy, mã này phần lớn do lớp bảo mật của website đích (WAF, chống bot, rule của CDN) tạo ra. Nếu chính proxy trả về 403 thì thường là ở bước CONNECT, với một port hoặc đích không được phép.

Với 403 đến từ website đích, các nguyên nhân điển hình là: IP có độ uy tín thấp, loại IP không phù hợp với site (ví dụ site chặn toàn bộ IP datacenter), có giới hạn theo quốc gia, hoặc header của request không giống trình duyệt thật. Đổi IP thường là phản xạ đầu tiên, nhưng nếu User-Agent, Accept-Language và cookie chưa nhất quán thì IP mới cũng sẽ nhận cùng một phản hồi.

429 thì rõ ràng là giới hạn tốc độ (rate limit). RFC 6585 định nghĩa mã này, và server thường cho biết bạn cần chờ bao lâu qua header Retry-After. Bộ đếm thường được tính theo từng IP; nó sẽ kích hoạt khi bạn gửi quá nhiều request đồng thời từ cùng một IP ra ngoài.

Các gói WeProxy không giới hạn số kết nối đồng thời và số thread. Vì vậy, khi gặp 429, bên đặt giới hạn gần như luôn là website đích. Những việc cần làm:

• Tuân theo giá trị Retry-After; nếu không có thì dùng exponential backoff (1, 2, 4, 8 giây).
• Giảm số request đồng thời dồn vào một IP.
• Đổi IP sau mỗi request phù hợp với các tác vụ không cần giữ phiên. Với tác vụ cần giữ phiên, hãy dùng sticky session; xem hướng dẫn chọn sticky hay rotating để phân biệt.
• Với các đích đòi hỏi IP có điểm tin cậy cao, hãy chọn rotating residential proxy, hoặc ISP proxy nếu cần một danh tính cố định trong thời gian dài.

Mở rộng pool IP để vượt rate limit không phải là giải pháp nếu điều đó vi phạm điều khoản sử dụng của website đích. Tự động hóa cần được thực hiện trong phạm vi mà website đích cho phép và tuân thủ chính sách sử dụng chấp nhận được.

502, 503 và 504: proxy không kết nối được tới website đích

Ba mã này thuộc nhóm “gateway” và cho thấy proxy gặp sự cố ở phía website đích.

502 Bad Gateway: Proxy đã kết nối tới đích nhưng không nhận được phản hồi hợp lệ, hoặc không thiết lập được kết nối. Có thể server đích đang tắt, proxy không phân giải được tên miền đích, hoặc thiết bị đầu ra trong pool residential bị offline giữa chừng. Vì IP residential và mobile đến từ thiết bị thật nên thỉnh thoảng gặp 502 là bình thường; thử lại thường là đủ.

503 Service Unavailable: Server đích hoặc một tầng trung gian tạm thời không phục vụ. Trang bảo trì hoặc cơ chế chống quá tải của website đích sẽ trả về mã này. Nếu có Retry-After thì hãy tuân theo.

504 Gateway Timeout: Proxy không nhận được phản hồi từ đích kịp thời. API chậm, vị trí địa lý xa hoặc trang nặng đều có thể gây ra mã này. Chọn quốc gia đầu ra gần server đích sẽ giúp rút ngắn khoảng cách giữa proxy và đích.

Để phân biệt, hãy mở cùng URL đó mà không qua proxy. Nếu không dùng proxy vẫn lỗi thì vấn đề nằm ở website đích. Nếu chỉ lỗi khi dùng proxy và thử lại thì hết, đó là sự cố của một điểm đầu ra riêng lẻ trong pool. Nếu lỗi lặp lại liên tục, hãy báo cho đội hỗ trợ biết đích nào, thời điểm nào và gói nào.

Lỗi timeout và lỗi kết nối

Timeout xảy ra ở hai giai đoạn khác nhau, và mỗi loại nói lên một điều khác nhau:

• Connect timeout: Client không mở được kết nối TCP tới proxy. Địa chỉ gateway sai, port bị đóng hoặc mạng nội bộ/firewall đang chặn kết nối.
• Read timeout: Kết nối đã được thiết lập nhưng hết thời gian chờ phản hồi. Lỗi này thường do website đích chậm hoặc chuỗi phản hồi dài.

Để tách bạch hai loại, hãy đặt hai mức thời gian riêng trong thư viện. Với Python requests, timeout=(10, 30) cho 10 giây để kết nối và 30 giây để đọc. Nếu chỉ đặt một giá trị, cả hai giai đoạn sẽ dùng chung và việc chẩn đoán sẽ khó hơn.

Nếu hoàn toàn không kết nối được tới proxy, hãy kiểm tra phía cục bộ trước: dùng công cụ kiểm tra port để xác nhận port 8989 trên địa chỉ gw.weproxy.com.tr đang mở khi nhìn từ bên ngoài, sau đó kiểm tra xem mạng của bạn có cho phép kết nối ra port này không. Mạng doanh nghiệp và một số nhà cung cấp cloud chặn kết nối ra các port không tiêu chuẩn.

Trên trình duyệt, cùng một tình huống sẽ hiển thị dưới tên khác. Chrome hiển thị ERR_PROXY_CONNECTION_FAILED khi không kết nối được tới proxy, và ERR_TUNNEL_CONNECTION_FAILED khi đã kết nối tới proxy nhưng không thiết lập được tunnel. Đằng sau trường hợp thứ hai thường là một phản hồi của proxy như 407 hoặc 502.

Bảng mã lỗi

curl: (35) thường xuất hiện khi bạn kết nối tới một HTTP proxy bằng scheme https://. Scheme trong URL proxy mô tả giao thức của proxy, không phải của website đích. Ngay cả khi truy cập đích HTTPS, địa chỉ proxy vẫn được viết với http://.

Phản hồi lỗi của SOCKS5

SOCKS5 không dùng mã HTTP. RFC 1928 phản hồi yêu cầu kết nối bằng một trường “reply”. Các thư viện thường hiển thị giá trị này dưới dạng thông báo:

Trong SOCKS5, xác thực là một bước riêng (RFC 1929). Nếu username/mật khẩu bị từ chối, kết nối sẽ đóng với thông báo kiểu “authentication failed”; đây là lỗi tương đương 407 trong HTTP. Để DNS được phân giải ở phía proxy, hãy dùng socks5h:// thay vì socks5://; nếu không sẽ xảy ra rò rỉ DNS. Chi tiết xem trong hướng dẫn về rò rỉ DNS, còn khác biệt giữa hai giao thức có trong bài HTTP vs SOCKS5.

Bắt lỗi và thử lại trong Python

requests trả về lỗi proxy dưới các loại exception riêng biệt. Bắt tất cả bằng một except duy nhất sẽ làm mất thông tin chẩn đoán. Ví dụ dưới đây sẽ backoff rồi thử lại với các mã tạm thời (429, 502, 503, 504), còn các lỗi cố định thì báo cáo riêng từng loại:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

proxy = "http://USER:[email protected]:8989"

retry = Retry(
    total=5,
    backoff_factor=1,
    status_forcelist=[429, 502, 503, 504],
    allowed_methods=["GET", "HEAD"],
    respect_retry_after_header=True,
)

session = requests.Session()
session.mount("http://", HTTPAdapter(max_retries=retry))
session.mount("https://", HTTPAdapter(max_retries=retry))
session.proxies = {"http": proxy, "https": proxy}

try:
    r = session.get("https://api.ipify.org?format=json", timeout=(10, 30))
    print(r.status_code, r.text)
except requests.exceptions.ProxyError as e:
    print("Proxy từ chối hoặc không kết nối được (407 / kết nối):", e)
except requests.exceptions.ConnectTimeout:
    print("Timeout khi kết nối tới proxy: kiểm tra port và firewall")
except requests.exceptions.ReadTimeout:
    print("Website đích không phản hồi: thay đổi read timeout hoặc quốc gia đầu ra")
except requests.exceptions.SSLError as e:
    print("Lỗi TLS: kiểm tra scheme của proxy", e)

Với đích HTTPS, 407 không đến dưới dạng một phản hồi HTTP mà nằm trong ProxyError với thông báo “Tunnel connection failed: 407”. Đừng thêm 407 vào danh sách thử lại: thử lại với thông tin đăng nhập sai sẽ không thay đổi kết quả. Xem thêm ví dụ cho các ngôn ngữ khác tại trang tích hợp Python và tích hợp Node.js.

Trình tự chẩn đoán từng bước

1. Ghi lại IP của bạn khi không dùng proxy bằng công cụ My IP.
2. Xác nhận port của gateway có thể truy cập được bằng công cụ kiểm tra port. Nếu không truy cập được, vấn đề nằm ở mạng cục bộ.
3. Lấy IP của bạn qua proxy bằng curl -v -x ... https://api.ipify.org. Nếu IP trả về là IP đầu ra của proxy, nghĩa là xác thực và tunnel đều hoạt động.
4. Lặp lại cùng lệnh với URL đích. Nếu lỗi nằm trong phản hồi CONNECT thì kiểm tra phía proxy; nếu nằm sau tunnel thì kiểm tra phía website đích.
5. Xác minh thêm rằng proxy hoạt động bình thường bằng proxy checker.
6. Với 429 và 403, rà soát lại số request đồng thời, header và loại IP. Với 502/504, test không qua proxy và tách riêng read timeout.
7. Nếu sự cố vẫn tiếp diễn, hãy liên hệ đội hỗ trợ kèm URL đích, mã lỗi, thời gian (kèm múi giờ) và tên gói. Đính kèm output của curl -v (đã xóa mật khẩu) sẽ giúp chẩn đoán nhanh hơn.

Phần lớn lỗi proxy có thể tóm gọn trong ba câu: 407 là chuyện thông tin đăng nhập, 403 và 429 là quyết định của website đích, 5xx và timeout là đoạn đường giữa proxy và website đích. Khi gắn lỗi vào đúng tầng, bạn sẽ chọn đúng giữa đổi IP, sửa mật khẩu hay chờ đợi.