EADDRNOTAVAIL khi crawl qua proxy: hết cổng hay sai địa chỉ

EADDRNOTAVAIL khi crawl qua proxy là lỗi hệ điều hành báo không cấp được địa chỉ hoặc cổng nguồn cho kết nối mới, thông báo thường gặp là "Cannot assign requested address". Lỗi xảy ra trên máy crawler trước khi gói đầu tiên kịp rời máy, nên đổi proxy hay đổi trang đích đều không giúp. ProxyVN chạy lab thật trên Windows, tái lập ba ca gây mã lỗi 10049, đo cổng nguồn và TIME_WAIT của 300 request theo ba cách gọi để anh em biết lỗi nằm ở đâu.

EADDRNOTAVAIL khi crawl qua proxy: lớp nào quyết định hành vi

Mỗi kết nối TCP được nhận diện bằng bốn giá trị: địa chỉ nguồn, cổng nguồn, địa chỉ đích, cổng đích. Khi crawler mở kết nối tới proxy, hai giá trị đích là địa chỉ và cổng của proxy, cố định. Hai giá trị nguồn do hệ điều hành của máy crawler chọn.

Hệ điều hành chọn cổng nguồn thế nào

Khi chương trình gọi connect mà không chỉ định cổng nguồn, hệ điều hành lấy một cổng trong dải cổng tạm, gọi là ephemeral port. Trên Linux, dải này đặt bằng tham số ip_local_port_range, mặc định 32768 tới 60999 theo tài liệu IP sysctl của nhân Linux. Tức là khoảng 28 nghìn cổng.

Trên Windows hiện đại, theo tài liệu Microsoft về dải cổng động, dải mặc định là 49152 tới 65535, tức 16.384 cổng. Máy lab của ProxyVN lại có dải bắt đầu từ 1024 với 13.977 cổng, cho thấy dải này có thể bị phần mềm khác hoặc quản trị viên đổi.

Vì sao crawl qua proxy dễ hết cổng

Khi đi thẳng tới nhiều trang, mỗi trang có địa chỉ đích khác nhau. Hệ điều hành có thể dùng lại cùng một cổng nguồn cho các đích khác nhau vì bộ bốn giá trị vẫn khác nhau.

Khi đi qua proxy, mọi kết nối đều tới cùng một địa chỉ và cùng một cổng. Ba trong bốn giá trị đã cố định. Chỉ còn cổng nguồn để phân biệt kết nối, nên số kết nối đồng thời tới proxy, cộng số kết nối đang nằm ở TIME_WAIT, không được vượt quá dải cổng tạm.

Proxy biến mọi đích khác nhau thành một đích duy nhất trong mắt hệ điều hành của máy crawler. Đây là lý do crawler đi thẳng chạy ổn, chuyển sang qua proxy thì gặp EADDRNOTAVAIL dù tải không đổi.

TIME_WAIT giữ cổng bao lâu

Khi một kết nối TCP đóng, bên đóng trước giữ cổng ở trạng thái TIME_WAIT thêm một khoảng thời gian. Mục đích là để gói trễ của kết nối cũ không bị nhận nhầm vào kết nối mới dùng cùng bộ bốn giá trị. Trên Linux, khoảng này cố định 60 giây. Trên Windows, mặc định khoảng 120 giây và chỉnh được qua registry.

Trong thời gian đó, cổng không dùng được cho kết nối mới tới cùng đích. Crawler mở rồi đóng kết nối liên tục sẽ để lại một hàng dài cổng ở TIME_WAIT. Số cổng bị giữ bằng tốc độ đóng kết nối nhân thời gian TIME_WAIT.

Điều này giải thích vì sao lỗi xuất hiện sau một lúc chạy chứ không phải ngay đầu. Lúc đầu dải cổng còn trống. Sau khoảng một tới hai phút chạy nhanh, cổng bị giữ đầy dần cho tới khi không còn cổng nào để cấp.

Ba lớp có thể gây lỗi

Lớp thứ nhất là máy crawler, chỗ hết cổng tạm hoặc bind sai địa chỉ. Lớp thứ hai là máy proxy, nơi proxy mở kết nối ra trang đích và cũng có thể hết cổng. Lớp thứ ba là trang đích hoặc đường mạng, nơi kết nối bị từ chối hay không có phản hồi.

Mỗi lớp cho thông báo khác nhau ở phía crawler. Phần lớn bài này đi vào việc đọc đúng thông báo để biết lớp nào đang hỏng.

Ranh giới với các bài đã có

Bài ERR_ADDRESS_UNREACHABLE nói về lỗi trình duyệt không tới được địa chỉ đích. Bài máy chủ proxy từ chối kết nối xử lý lỗi phía proxy. Bài này chỉ xét lỗi cấp địa chỉ và cổng nguồn trên máy chạy crawler.

EADDRNOTAVAIL khi crawl qua proxy: chẩn đoán thiếu địa chỉ hoặc cổng tạm

Một đích duy nhất

Cùng một mã lỗi có thể đến từ ba nguyên nhân khác nhau. Trước khi tăng dải cổng hay chỉnh TIME_WAIT, cần biết đang gặp nguyên nhân nào.

Định nghĩa theo tài liệu

Trang man connect ghi EADDRNOTAVAIL xảy ra khi socket chưa được bind và hệ điều hành thấy mọi cổng trong dải cổng tạm đều đang bận. Trang man bind ghi thêm trường hợp bind tới một giao diện không tồn tại hoặc một địa chỉ không thuộc máy.

Trên Windows, bảng mã lỗi Winsock ghi WSAEADDRNOTAVAIL mang số 10049. Lỗi thường do bind tới địa chỉ không hợp lệ với máy, hoặc do connect tới địa chỉ hay cổng không hợp lệ như địa chỉ 0 hoặc cổng 0.

Ba nguyên nhân hay gặp

Bảng: Ba nguyên nhân hay gặp

Nguyên nhân	Khi nào xảy ra	Dấu hiệu
Hết cổng tạm	Mở kết nối mới rất nhanh tới cùng proxy	Lỗi xuất hiện sau một lúc chạy, tăng theo tải
Bind tới địa chỉ không thuộc máy	Cấu hình chọn IP nguồn sai, IP đã bị gỡ	Lỗi ngay từ request đầu
Địa chỉ hoặc cổng proxy không hợp lệ	Biến proxy rỗng, cổng 0, địa chỉ 0.0.0.0	Lỗi ngay từ request đầu

Nguyên nhân thứ nhất phụ thuộc thời gian và tải. Hai nguyên nhân sau là lỗi cấu hình, xuất hiện ngay và lặp lại y hệt. Chỉ cần nhìn thời điểm lỗi xuất hiện là loại được một nửa khả năng.

Ca bind sai địa chỉ trong crawler thật

Nhiều crawler chạy trên máy có nhiều địa chỉ IP và chọn địa chỉ nguồn cho từng worker. Thư viện requests không có tùy chọn này sẵn, nhưng có thể làm qua adapter tùy biến. Thư viện như pycurl có tùy chọn interface, aiohttp có tham số local_addr trong connector.

Khi địa chỉ được gỡ khỏi máy, ví dụ IP phụ của máy ảo bị thu hồi, mọi worker gắn địa chỉ đó bắt đầu báo EADDRNOTAVAIL ngay. Lỗi không liên quan tới proxy, nhưng log thường hiện là lỗi kết nối proxy vì thư viện bọc ngoài.

Ca cấu hình proxy rỗng

Biến môi trường HTTP_PROXY bị đặt sai thành "http://0.0.0.0:8080" hoặc cổng bị đọc nhầm thành 0 khi tách chuỗi ip:port:user:pass. Thư viện vẫn cố kết nối và nhận lỗi địa chỉ không hợp lệ. Bài định dạng proxy có cách tách chuỗi đúng để tránh ca này.

Thiết kế lab EADDRNOTAVAIL khi crawl qua proxy: phiên bản và phép đo

Lab chạy ngày 29/10/2026 trên Windows 10, Python 3.12.10 và requests 2.34.2. Một proxy HTTP tự viết chạy ở 127.0.0.1 cổng 9485, chuyển request tới máy chủ đích ở cổng khác cùng máy.

Proxy lab hoạt động thế nào

Proxy lab là một chương trình Python nhỏ dùng socket, nhận request HTTP dạng proxy, mở kết nối mới tới trang đích cho mỗi request rồi chuyển phản hồi về. Khi trang đích không kết nối được, proxy trả 502 kèm thông báo lỗi trong thân phản hồi. Cách làm này giống hành vi của nhiều proxy forward đơn giản.

Trang đích là máy chủ HTTP trả trang ngắn có Content-Length, hỗ trợ keep-alive. Như vậy, khi client giữ kết nối, cả hai chặng đều có thể được giữ. Lab đo phía client tới proxy, là chặng mà EADDRNOTAVAIL xảy ra trên máy crawler.

Ba ca tái lập mã lỗi

Ca 1 tạo socket rồi bind tới 192.0.2.10, địa chỉ trong dải dành cho tài liệu, không thuộc máy. Ca 2 connect tới 0.0.0.0. Ca 3 connect tới 127.0.0.1 cổng 0. Ba ca đều nhắm vào định nghĩa của Microsoft về địa chỉ không hợp lệ.

Ca 4 bind cổng nguồn cố định ba lần liên tiếp với SO_REUSEADDR để xem Windows có cho dùng lại cổng hay không. Đây là đối chứng cho chuyện cổng nguồn bị giữ.

Hai ca đối chiếu với lỗi gần giống

Ca 5 gửi request qua requests tới proxy ở cổng 9487, nơi không có gì lắng nghe. Ca 6 gửi request qua proxy đang chạy nhưng trang đích ở cổng 9488 đã tắt. Hai ca này cho thông báo trông gần giống EADDRNOTAVAIL nếu chỉ đọc lướt.

Ba cách gọi 300 request

Ca 7 dùng requests.get trực tiếp, không Session, mỗi request mở kết nối mới. Ca 7b tạo một Session mới cho mỗi request rồi đóng. Ca 8 dùng một Session cho cả 300 request.

Mỗi ca ghi số cổng nguồn khác nhau đã dùng, thời gian chạy và trạng thái các kết nối tới cổng 9485 bằng netstat sau khi chạy. Netstat tách phía proxy với phía client, vì cả hai cùng chạy trên máy lab.

Kết quả kỳ vọng

Ca 1, 2, 3 ra WSAEADDRNOTAVAIL. Ca 5 ra lỗi bị từ chối kết nối, không phải lỗi địa chỉ. Ca 6 ra mã HTTP 502 từ proxy. Ca 7 và 7b dùng 300 cổng nguồn. Ca 8 dùng một cổng.

Tái lập EADDRNOTAVAIL khi crawl qua proxy: ca thành công và ca lỗi có kiểm soát

Phần này đưa mã cốt lõi và số liệu thật từ lab. Không có ca nào cố tình làm cạn cổng của máy, vì làm vậy sẽ ảnh hưởng mọi chương trình khác đang chạy. Thay vào đó, lab đo tốc độ tiêu cổng và tính ra thời điểm cạn.

Ba ca gây mã 10049

import socket
 
def thu(fn):
    s = socket.socket()
    try:
        fn(s)
        return "ok"
    except OSError as e:
        return e.errno, e.winerror, str(e)
    finally:
        s.close()
 
print(thu(lambda s: s.bind(("192.0.2.10", 0))))
print(thu(lambda s: s.connect(("0.0.0.0", 9485))))
print(thu(lambda s: s.connect(("127.0.0.1", 0))))

Cả ba ca đều trả errno 10049, tên WSAEADDRNOTAVAIL, thông báo "The requested address is not valid in its context". Ba nguyên nhân khác nhau, cùng một mã. Vì vậy chỉ nhìn mã lỗi không đủ, phải nhìn thêm cấu hình và thời điểm.

Ca 4 bind cổng nguồn cố định ba lần liên tiếp đều thành công vì mỗi lần socket cũ đã đóng trước khi mở socket mới và chưa có kết nối thật nào được thiết lập.

Ca proxy chết và ca trang đích chết

Ca 5, proxy không chạy, requests ném ProxyError với dòng cuối là WinError 10061 "No connection could be made because the target machine actively refused it". Đây là lỗi bị từ chối kết nối, mã 10061, khác 10049.

Ca 6, proxy chạy nhưng trang đích tắt, requests không ném lỗi mà nhận mã HTTP 502 từ proxy. Thân phản hồi ghi proxy không kết nối được tới upstream với lỗi 10061. Lỗi của trang đích được proxy chuyển thành mã HTTP.

EADDRNOTAVAIL không bao giờ đi kèm mã HTTP, vì kết nối chưa từng được mở. Thấy 502 hay 504 là biết kết nối tới proxy đã thành công.

Ba cách gọi và số cổng nguồn

300 cổng hay 1 cổng

Bảng: Ba cách gọi và số cổng nguồn

Ca	Cách gọi	Số cổng nguồn	Thời gian	TIME_WAIT phía client sau ca
Trước khi chạy	Không	Không	Không	117
7	requests.get không Session	300	1,70 giây	223
7b	Session mới mỗi request	300	1,09 giây	523
8	Một Session cho 300 request	1	1,52 giây	524

Ca 7 và 7b đều tiêu 300 cổng nguồn cho 300 request. Ca 8 chỉ dùng một cổng, kết nối được giữ suốt 300 request.

Số TIME_WAIT phía proxy tăng từ 185 lên 379 sau ca 7 rồi đứng yên. Số phía client chỉ tăng 106 sau ca 7 nhưng tăng đủ 300 sau ca 7b. Lý do là bên nào đóng kết nối trước thì bên đó giữ TIME_WAIT. Ở ca 7, phần lớn kết nối do proxy đóng. Ở ca 7b, Session đóng chủ động nên phía client giữ.

Tính thời điểm cạn cổng

Ở ca 7b, máy tiêu khoảng 275 cổng mỗi giây. Mỗi cổng bị giữ ở TIME_WAIT thêm một khoảng thời gian, trên Windows mặc định khoảng 120 giây, trên Linux là 60 giây. Với 13.977 cổng của máy lab, số cổng bị giữ sẽ chạm trần sau khoảng 51 giây chạy liên tục.

Trên Linux với 28.232 cổng mặc định và TIME_WAIT 60 giây, tốc độ tối đa bền vững là khoảng 470 kết nối mới mỗi giây tới cùng một proxy. Vượt mức đó, EADDRNOTAVAIL sẽ xuất hiện. Con số này đạt được dễ dàng với crawler bất đồng bộ hàng trăm tác vụ.

Ca 8 thì không có giới hạn này. Một kết nối giữ suốt cả lô, không tiêu thêm cổng. Dù chạy bao lâu, số cổng bị giữ vẫn là một.

Đọc log, gói tin và response để tách EADDRNOTAVAIL khi crawl qua proxy với lỗi gần giống

Phần này gom các thông báo hay gặp, lệnh đếm cổng và cách đọc từng thứ để khoanh vùng.

Bảng thông báo theo lớp

Lỗi nằm ở lớp nào

Bảng: Bảng thông báo theo lớp

Thông báo trong log	Mã	Lớp gây lỗi	Có mã HTTP
Cannot assign requested address	EADDRNOTAVAIL, Linux 99	Máy crawler	Không
The requested address is not valid in its context	WSAEADDRNOTAVAIL 10049	Máy crawler	Không
Connection refused	ECONNREFUSED, Windows 10061	Proxy không lắng nghe	Không
502 Bad Gateway	Không	Proxy không tới được đích	Có
504 Gateway Timeout	Không	Đích không trả lời kịp	Có
407 Proxy Authentication Required	Không	Sai thông tin xác thực	Có

Bốn dòng dưới đều có bài riêng trên ProxyVN. Bài 502 Bad Gateway và lỗi ERR_CONNECTION_REFUSED xử lý hai lỗi hay bị nhầm nhất với EADDRNOTAVAIL.

Lệnh đếm cổng trên Linux

cat /proc/sys/net/ipv4/ip_local_port_range
ss -tan state time-wait dst 203.0.113.50:8080 | wc -l
ss -tan state established dst 203.0.113.50:8080 | wc -l
ss -s

Dòng đầu cho dải cổng. Hai dòng sau đếm kết nối tới proxy theo trạng thái, thay địa chỉ bằng proxy thật. Dòng cuối cho tổng hợp. Nếu tổng TIME_WAIT cộng ESTABLISHED tới proxy gần bằng độ rộng dải cổng, nguyên nhân là hết cổng tạm.

Lệnh ss chưa được ProxyVN chạy trên Linux trong bài này. Cú pháp theo tài liệu của iproute2.

Lệnh đếm cổng trên Windows

netsh int ipv4 show dynamicport tcp
netstat -ano -p tcp | findstr :9485 | findstr TIME_WAIT

Lệnh đầu được chạy thật trên máy lab, cho kết quả dải bắt đầu từ 1024 với 13.977 cổng. Lệnh sau là cách đếm đã dùng trong lab, thay 9485 bằng cổng proxy thật.

Gói tin cho thấy gì

Khi lỗi là EADDRNOTAVAIL, tcpdump hay Wireshark trên máy crawler không thấy gói SYN nào cho kết nối bị lỗi. Kernel từ chối trước khi tạo gói. Đây là bằng chứng mạnh nhất rằng lỗi nằm trên máy crawler.

Khi lỗi là từ chối kết nối, sẽ thấy gói SYN đi ra và gói RST quay về. Khi lỗi là timeout, thấy SYN đi ra nhiều lần mà không có gì về. Bài Wireshark proxy hướng dẫn lọc gói theo địa chỉ proxy.

Ghi log đủ để chẩn đoán lần sau

Khi crawler bắt ngoại lệ kết nối, nên ghi cả mã lỗi gốc chứ không chỉ tên ngoại lệ ngoài cùng. Với requests, ngoại lệ gốc nằm trong thuộc tính __context__ hoặc trong chuỗi lỗi. Một dòng log gồm thời điểm, proxy, mã errno và số request đã gửi trong phút đó là đủ để thấy lỗi tăng theo tải.

Ghi thêm số kết nối mới mở mỗi phút giúp so trực tiếp với ngưỡng tính ở phần trên. Nếu con số vượt khoảng 400 mỗi giây tới một proxy trên Linux, lỗi hết cổng gần như chắc sẽ đến. Nếu con số thấp mà vẫn lỗi, quay lại kiểm cấu hình địa chỉ.

Khi proxy là bên hết cổng

Proxy mở kết nối ra trang đích cũng tiêu cổng tạm trên máy proxy. Nếu máy proxy hết cổng, phía crawler không thấy EADDRNOTAVAIL mà thấy 502 hoặc 503 từ proxy, kèm thân phản hồi nhắc tới lỗi địa chỉ. Với proxy thương mại, đây là việc của nhà cung cấp. Với proxy tự dựng, áp dụng cùng cách xử lý ở phần dưới trên máy proxy.

Xử lý EADDRNOTAVAIL khi crawl qua proxy theo bằng chứng và checklist

Checklist EADDRNOTAVAIL

Cách xử lý đi theo nguyên nhân đã xác định. Với hết cổng tạm, thứ tự ưu tiên là dùng lại kết nối, mở rộng dải cổng, rồi mới tới chỉnh TIME_WAIT.

Dùng lại kết nối

Đây là cách hiệu quả nhất theo số liệu lab: 300 request chỉ dùng một cổng thay vì 300. Với requests, tạo một Session cho mỗi worker và gắn proxy vào Session. Với aiohttp, dùng một ClientSession cho cả lô. Với httpx, dùng một Client.

Kết nối chỉ được giữ khi proxy và trang đích hỗ trợ keep-alive. Proxy HTTP thường giữ kết nối phía client. Với HTTPS qua CONNECT, đường hầm tới mỗi trang đích là một kết nối riêng, nên dùng lại được khi gọi nhiều request tới cùng trang. Bài proxy tunnel là gì giải thích đường hầm CONNECT.

Đừng đóng kết nối sớm bằng header Connection: close nếu không cần. Một số mã mẫu trên mạng thêm header này để "tránh treo", vô tình buộc mỗi request mở kết nối mới.

Cấu hình bể kết nối cho requests và aiohttp

Session của requests dùng bể kết nối của urllib3, mặc định giữ tối đa 10 kết nối cho mỗi máy đích. Với crawler đa luồng chung một Session, nếu số luồng lớn hơn 10, các kết nối thừa sẽ bị đóng sau khi dùng và mở lại lần sau. Kết quả là vẫn tiêu cổng dù đã dùng Session.

Cách sửa là gắn HTTPAdapter với pool_maxsize bằng số luồng. Khi đó mỗi luồng giữ một kết nối tới proxy suốt lô. Một cách khác là mỗi luồng giữ Session riêng, đơn giản hơn và tránh chia sẻ trạng thái cookie giữa các luồng.

Với aiohttp, TCPConnector có tham số limit cho tổng số kết nối và limit_per_host cho mỗi máy đích. Đặt limit_per_host bằng số tác vụ đồng thời muốn chạy qua proxy. Với httpx, tham số Limits có max_keepalive_connections quyết định số kết nối được giữ lại sau khi dùng.

Giới hạn tốc độ mở kết nối mới

Nếu bắt buộc phải mở kết nối mới cho mỗi request, ví dụ để đổi IP qua proxy xoay theo kết nối, hãy giới hạn tốc độ. Với dải 28 nghìn cổng và TIME_WAIT 60 giây, giữ dưới 400 kết nối mới mỗi giây tới một proxy.

Proxy xoay theo kết nối là ca cần chú ý. Mỗi kết nối mới cho một IP mới, nên crawler có xu hướng mở thật nhiều kết nối. Bài proxy xoay và proxy tĩnh giúp chọn loại proxy hợp với kiểu tải này.

Mở rộng dải cổng

Mở rộng dải cổng là cách nhanh khi cần chạy lô gấp mà chưa kịp sửa mã. Nó không đòi khởi động lại crawler trên Linux, chỉ có hiệu lực cho kết nối mới. Trên Windows, thay đổi qua netsh cũng áp dụng ngay, nhưng nên kiểm lại bằng lệnh show sau khi đặt. Ghi lại giá trị cũ trước khi đổi để quay lại được khi có sự cố với dịch vụ khác.

Trên Linux:

sysctl -w net.ipv4.ip_local_port_range="15000 65000"

Trên Windows, theo tài liệu Microsoft:

netsh int ipv4 set dynamicport tcp start=10000 num=55000

Dải mới không được chồng lên cổng mà dịch vụ trên máy đang lắng nghe. Với Linux, có thể giữ chỗ cho cổng dịch vụ bằng ip_local_reserved_ports. Mở rộng dải chỉ dời thời điểm cạn, không xóa nguyên nhân.

Chỉnh TIME_WAIT và tái sử dụng

Linux có tcp_tw_reuse, cho phép dùng lại cổng đang ở TIME_WAIT cho kết nối mới khi an toàn về mặt giao thức. Tài liệu nhân ghi giá trị 1 bật toàn cục, 2 chỉ cho loopback, và khuyên không đổi khi chưa có chuyên gia tư vấn.

Với crawler gọi tới proxy, tcp_tw_reuse bằng 1 thường giải được hết cổng mà không cần mở rộng dải. Nhưng đây là thay đổi toàn máy, ảnh hưởng mọi dịch vụ khác. Thử trên máy riêng cho crawler trước.

Đừng dùng tcp_tw_recycle trong hướng dẫn cũ. Tùy chọn này đã bị gỡ khỏi nhân Linux từ lâu vì gây lỗi với client sau NAT.

Sửa lỗi cấu hình

Với ca bind sai địa chỉ, kiểm danh sách IP nguồn của crawler với địa chỉ đang có trên máy bằng ip addr hoặc ipconfig. Bỏ IP không còn khỏi danh sách và cho worker tự chuyển khi gặp lỗi.

Với ca địa chỉ proxy rỗng, in chuỗi proxy đã tách ra trước khi dùng, che mật khẩu. Kiểm cổng là số dương, địa chỉ không phải 0.0.0.0 và không rỗng.

Giới hạn suy luận của bài

Lab chạy trên Windows, không làm cạn cổng thật để tránh ảnh hưởng máy. Thời điểm cạn là tính từ tốc độ đo được và độ rộng dải, chưa đo trực tiếp. Phần Linux, ss, tcp_tw_reuse lấy theo tài liệu chính thức ngày 29/10/2026, chưa chạy.

Thời gian TIME_WAIT trên Windows có thể đổi qua registry và khác giữa các phiên bản. Con số 120 giây chỉ để ước lượng.

Checklist EADDRNOTAVAIL khi crawl qua proxy

• Đọc dòng cuối traceback, xác định mã là 99, 10049 hay mã khác.
• Lỗi ngay từ đầu thì kiểm cấu hình proxy và địa chỉ nguồn.
• Lỗi sau một lúc chạy thì đếm TIME_WAIT và ESTABLISHED tới proxy.
• So tổng với độ rộng dải cổng tạm.
• Dùng một Session hoặc Client cho mỗi worker.
• Bỏ header Connection: close nếu không cần.
• Giới hạn tốc độ mở kết nối mới khi dùng proxy xoay theo kết nối.
• Chỉ mở rộng dải cổng hay bật tcp_tw_reuse sau khi đã dùng lại kết nối.

Với crawler cần nhiều IP mà vẫn muốn giữ kết nối lâu, có thể chia tải ra nhiều proxy tĩnh thay vì một proxy xoay theo từng kết nối. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay, giao thức HTTP và SOCKS5. Anh em có thể mua proxy giá rẻ tại trang chủ ProxyVN rồi chia mỗi worker một proxy để mỗi cổng đích chỉ nhận tải của một worker.

Câu hỏi thường gặp về EADDRNOTAVAIL khi crawl qua proxy

Đổi proxy khác có hết lỗi không?

Nếu lỗi là hết cổng tạm, đổi sang proxy có địa chỉ hoặc cổng khác sẽ mở ra một dải cổng mới vì bộ bốn giá trị đổi. Lỗi tạm hết nhưng quay lại khi proxy mới cũng bị tiêu hết. Dùng lại kết nối mới là cách sửa gốc.

Chia tải ra nhiều proxy có giúp không?

Có. Mỗi cặp địa chỉ và cổng proxy có dải cổng nguồn riêng. Mười proxy cho mười lần sức chứa. Đây là cách hợp lý khi crawler buộc phải mở nhiều kết nối mới.

Lỗi EADDRINUSE khác gì EADDRNOTAVAIL?

EADDRINUSE là địa chỉ và cổng đã được dùng, thường gặp khi bind cổng cố định đang bận. EADDRNOTAVAIL là không cấp được, do hết cổng tạm hoặc địa chỉ không thuộc máy.

Docker có làm lỗi này nặng hơn không?

Container đi ra ngoài qua NAT của máy chủ. Nhiều container cùng đi tới một proxy dùng chung dải cổng NAT của máy chủ. Lỗi có thể xuất hiện ở tầng NAT, hiện thành timeout thay vì EADDRNOTAVAIL trong container.

Lỗi chỉ xảy ra trên một máy trong cụm thì sao?

Kiểm dải cổng của máy đó, có thể đã bị phần mềm khác thu hẹp như máy lab của ProxyVN. Kiểm thêm số dịch vụ khác trên máy đang mở kết nối ra ngoài, vì chúng dùng chung dải cổng.

Tăng số luồng có làm lỗi đến sớm hơn không?

Có, nếu mỗi luồng mở kết nối mới cho mỗi request. Tốc độ tiêu cổng tăng theo số luồng. Nếu mỗi luồng giữ kết nối, tăng luồng chỉ thêm đúng số kết nối giữ, không tiêu thêm cổng theo thời gian.

Proxy SOCKS5 có khác không?

Không khác về cổng nguồn. Kết nối tới proxy SOCKS5 cũng là TCP tới một địa chỉ và cổng cố định. Cách xử lý giống proxy HTTP.

EADDRNOTAVAIL khi crawl qua proxy và những điều cần nhớ

EADDRNOTAVAIL khi crawl qua proxy là lỗi trên máy crawler, xảy ra trước khi có gói tin nào rời máy. Trong lab, 300 request không dùng lại kết nối tiêu 300 cổng, một Session chỉ tiêu một cổng. Đọc thời điểm lỗi, đếm TIME_WAIT tới proxy, dùng lại kết nối trước khi chỉnh kernel. Cần proxy ổn định để giữ kết nối lâu khi xử lý EADDRNOTAVAIL khi crawl qua proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.