Happy Eyeballs khi kết nối proxy: IPv4, IPv6 và độ trễ 2 giây
Happy Eyeballs khi kết nối proxy là cơ chế thử song song địa chỉ IPv6 và IPv4 của tên máy proxy, lấy địa chỉ nào kết nối được trước. Khi chương trình không có cơ chế này, nó thử lần lượt từng địa chỉ, và một địa chỉ không phản hồi có thể làm mỗi kết nối chậm thêm vài giây. ProxyVN đo thật trên Windows: cùng một proxy chỉ nghe IPv4, viết bằng tên localhost thì requests mất 2,05 giây cho mỗi request, viết bằng 127.0.0.1 chỉ mất 0,015 giây, còn asyncio bật Happy Eyeballs rút xuống 0,26 giây.
Happy Eyeballs khi kết nối proxy: lớp nào quyết định hành vi
Khi anh em cấu hình proxy bằng tên máy, ví dụ proxy.example.vn:8080, chương trình phải tra DNS để lấy địa chỉ IP. Nếu tên đó có cả bản ghi A cho IPv4 và AAAA cho IPv6, chương trình nhận về nhiều địa chỉ. Chọn địa chỉ nào và thử theo thứ tự nào là việc của thư viện mạng, không phải của proxy.
Thứ tự địa chỉ do hệ điều hành trả về
Hàm getaddrinfo của hệ điều hành trả danh sách địa chỉ đã sắp xếp theo quy tắc chọn địa chỉ. Trên hầu hết hệ điều hành hiện đại, IPv6 được xếp trước IPv4 khi máy có địa chỉ IPv6. Trên máy lab, tên localhost trả về ::1 trước, rồi mới tới 127.0.0.1.
Thứ tự này không cho biết địa chỉ nào dùng được. Nó chỉ là ưu tiên. Nếu proxy chỉ nghe trên IPv4, địa chỉ IPv6 đứng đầu danh sách sẽ thất bại, và thời gian thất bại quyết định mỗi kết nối chậm bao nhiêu.
Thử lần lượt và thử chạy đua
Thử lần lượt và chạy đua
Cách cũ là thử lần lượt: kết nối địa chỉ đầu, chờ thành công hoặc lỗi, rồi mới thử địa chỉ sau. Nếu địa chỉ đầu bị từ chối ngay, độ trễ nhỏ. Nếu địa chỉ đầu không phản hồi, chương trình chờ hết thời gian chờ kết nối rồi mới chuyển.
Happy Eyeballs là cách mới. RFC 8305 mô tả phiên bản 2: bắt đầu kết nối địa chỉ đầu, nếu sau một khoảng ngắn chưa xong thì mở kết nối tới địa chỉ tiếp theo song song. Kết nối nào xong trước được dùng, các kết nối còn lại bị hủy. RFC khuyến nghị khoảng chờ giữa hai lần thử là 250 mili giây.
Happy Eyeballs không làm kết nối nhanh hơn, nó chặn trường hợp một địa chỉ hỏng làm cả kết nối chậm.
Các mốc thời gian trong RFC 8305
RFC 8305 đặt ra vài mốc thời gian. Mốc thứ nhất là độ trễ phân giải: khi bản ghi A về trước bản ghi AAAA, chương trình chờ thêm khoảng 50 mili giây để AAAA kịp về rồi mới bắt đầu, vì IPv6 được ưu tiên. Mốc thứ hai là độ trễ giữa hai lần thử, khuyến nghị 250 mili giây.
RFC ghi độ trễ giữa hai lần thử không nên dưới 100 mili giây để tránh mở quá nhiều kết nối thừa, và không nên quá 2 giây để người dùng không phải chờ lâu. Một số triển khai tự điều chỉnh mốc này theo độ trễ khứ hồi đo được từ các kết nối trước.
RFC còn khuyến nghị xen kẽ hai họ địa chỉ trong danh sách thử: một IPv6, một IPv4, rồi lại IPv6. Như vậy nếu tên máy có nhiều địa chỉ IPv6 hỏng, địa chỉ IPv4 vẫn được thử sớm thay vì đứng cuối hàng.
Proxy và trang đích tra DNS ở hai chỗ khác nhau
Với proxy HTTP, máy client chỉ tra DNS cho tên proxy. Tên trang đích được gửi nguyên văn trong request hoặc lệnh CONNECT, và proxy tự tra DNS cho trang đích. Happy Eyeballs ở máy client vì vậy chỉ ảnh hưởng chặng client tới proxy.
Với SOCKS5, tùy cấu hình. Dạng socks5h cho proxy tra tên trang đích. Dạng socks5 cho client tra tên trang đích rồi gửi địa chỉ IP sang proxy. Bài DNS leak khi dùng proxy giải thích khác biệt này. Bài này chỉ xét chặng client tới proxy.
Ranh giới với bài IPv4 và IPv6
Bài proxy IPv4 và IPv6 so sánh hai loại proxy theo địa chỉ thoát. Bài này không bàn proxy thoát ra bằng giao thức nào, mà bàn chuyện máy client kết nối tới proxy bằng địa chỉ nào khi tên proxy có cả hai loại bản ghi.
Tách lựa chọn IPv4 và IPv6 tới tên máy proxy với DNS của trang đích khi Happy Eyeballs khi kết nối proxy
Phần này chia rõ hai lần tra DNS trong một request qua proxy và chỉ ra lần nào chịu ảnh hưởng của Happy Eyeballs.
Lần tra thứ nhất: tên proxy
Ứng dụng đọc cấu hình proxy, thấy tên máy, gọi getaddrinfo. Kết quả là danh sách địa chỉ. Ứng dụng kết nối TCP tới một địa chỉ trong danh sách, theo cách thử lần lượt hoặc thử chạy đua tùy thư viện.
Lần tra này diễn ra trên máy client, dùng DNS của máy client. Nếu proxy cấu hình bằng địa chỉ IP thay vì tên, không có lần tra này và không có chuyện chọn giữa IPv4 với IPv6.
Lần tra thứ hai: tên trang đích
Hai lần tra DNS
Proxy nhận request có tên trang đích, tự tra DNS, tự chọn địa chỉ. Proxy có thể có Happy Eyeballs hoặc không, tùy phần mềm. Phía client không kiểm soát được bước này và cũng không thấy được nó.
Nếu trang đích chậm vì proxy chọn sai giao thức, triệu chứng sẽ là phản hồi lệnh CONNECT chậm hoặc mã 504, không phải bước kết nối tới proxy chậm. Đây là cách tách hai lớp khi đo.
Ba kiểu cấu hình proxy và rủi ro
Cách viết proxy |
Lần tra DNS ở client |
Rủi ro chọn sai địa chỉ |
|---|---|---|
203.0.113.50:8080 |
Không |
Không có |
proxy.example.vn:8080, chỉ có bản ghi A |
Có, một địa chỉ |
Không có |
proxy.example.vn:8080, có cả A và AAAA |
Có, hai địa chỉ |
Có, nếu proxy không nghe ở một trong hai |
localhost:8080 cho proxy cục bộ |
Có, ::1 và 127.0.0.1 |
Có, nếu proxy chỉ nghe 127.0.0.1 |
Dòng cuối là ca gặp nhiều nhất trên máy cá nhân. Các công cụ proxy cục bộ như trình chặn quảng cáo, công cụ chuyển tiếp, proxy chạy trong Docker thường chỉ nghe 127.0.0.1, trong khi người dùng gõ localhost trong cấu hình.
Bài proxy 127.0.0.1 giải thích địa chỉ loopback. Bài này cho thấy vì sao gõ localhost và gõ 127.0.0.1 có thể khác nhau tới hai giây mỗi kết nối.
Kiểm bản ghi DNS của tên proxy
Trước khi đo, xem tên proxy có những bản ghi nào. Lệnh nslookup với tên proxy trên Windows, hoặc dig cho bản ghi A và AAAA trên Linux, cho danh sách địa chỉ. Nếu chỉ có bản ghi A, bài này không áp dụng cho chặng client tới proxy.
Một số nhà cung cấp proxy dùng tên chung cho nhiều cổng hoặc nhiều máy, và tên đó có thể có bản ghi AAAA trỏ tới hạ tầng web chứ không phải máy proxy. Khi đó địa chỉ IPv6 tồn tại nhưng không có dịch vụ proxy ở cổng anh em dùng.
Thời gian thất bại quyết định độ trễ
Khi địa chỉ IPv6 thất bại, có ba kiểu thất bại với thời gian khác nhau. Bị từ chối, tức nhận gói RST, thường nhanh. Không có tuyến đường, tức máy không có IPv6 ra ngoài, báo lỗi gần như ngay. Không phản hồi, tức gói bị bỏ trên đường, phải chờ hết thời gian chờ kết nối.
Trên Windows có một điểm đặc biệt: bị từ chối không trả lỗi ngay mà thử lại SYN vài lần, mất khoảng hai giây. Đây chính là nguồn gốc độ trễ hai giây trong lab.
Thiết kế lab Happy Eyeballs khi kết nối proxy: phiên bản và phép đo
Lab chạy ngày 29/10/2026 trên Windows 10 build 19045, Python 3.12.10, requests 2.34.2 và curl 8.13.0 bản đi kèm Windows, dùng Schannel.
Hai proxy giả lập
Proxy thứ nhất nghe ở 127.0.0.1 cổng 9570, chỉ IPv4. Proxy thứ hai nghe ở ::1 cổng 9571, chỉ IPv6. Cả hai nhận request HTTP và trả 200 với thân ngắn. Mục tiêu là đo bước kết nối, nên proxy không chuyển tiếp đi đâu.
Các phép đo
Phép đo một tra getaddrinfo cho localhost để xem thứ tự địa chỉ. Phép đo hai dùng socket.create_connection, hàm thử lần lượt của thư viện chuẩn, tới localhost với từng proxy. Phép đo ba dùng asyncio.open_connection với tham số happy_eyeballs_delay để trống và bằng 0,25 giây.
Phép đo bốn gửi request bằng requests qua proxy viết là http://localhost:9570 và http://127.0.0.1:9570. Phép đo năm làm tương tự bằng curl, đọc thời gian kết nối và địa chỉ thật curl đã dùng.
Ca nhánh IPv6 không phản hồi
Lab thêm một ca giả lập tên proxy có cả bản ghi AAAA trỏ tới 2001:db8::1, địa chỉ dành cho tài liệu, và bản ghi A trỏ tới 127.0.0.1. Cách giả lập là thay hàm getaddrinfo trong Python để trả hai địa chỉ này cho tên proxy.lab.test. Mục tiêu là xem nhánh IPv6 không ai trả lời làm chậm bao nhiêu.
Vì sao dùng loopback
Loopback cho phép dựng cả hai phía trên một máy mà không phụ thuộc mạng ngoài, và localhost có sẵn cả bản ghi IPv4 lẫn IPv6. Đây cũng là ca thật: proxy cục bộ, công cụ chuyển tiếp và proxy chạy trong container đều thường được gọi bằng localhost.
Nhược điểm là loopback không mô phỏng được mạng thật có độ trễ và có thiết bị chặn gói. Phép đo nhánh IPv6 không phản hồi được thêm vào để bù phần này, dù kết quả cho thấy máy lab không mô phỏng được ca đó.
Kết quả kỳ vọng
Thử lần lượt tới localhost khi proxy chỉ nghe IPv4 sẽ chậm khoảng hai giây trên Windows. Thử chạy đua với khoảng 0,25 giây sẽ chậm khoảng 0,25 giây. Viết thẳng 127.0.0.1 không chậm.
Tái lập Happy Eyeballs khi kết nối proxy: luồng nhanh và luồng chậm có kiểm soát
Phần này đưa mã cốt lõi và số liệu thật. Mỗi dòng trong bảng là một lần đo riêng.
Thứ tự địa chỉ của localhost
import socket
print([a[4][0] for a in socket.getaddrinfo("localhost", 9570, type=socket.SOCK_STREAM)])Kết quả: danh sách gồm ::1 rồi 127.0.0.1. IPv6 đứng trước, đúng với ưu tiên mặc định của Windows khi có loopback IPv6.
Bảng đo kết nối
2,05 giây và 0,015 giây
Phép đo |
Đích |
Địa chỉ kết nối được |
Thời gian |
|---|---|---|---|
create_connection |
localhost, proxy chỉ IPv4 |
127.0.0.1 |
2,055 giây |
create_connection |
localhost, proxy chỉ IPv6 |
::1 |
0,016 giây |
create_connection |
127.0.0.1, proxy chỉ IPv4 |
127.0.0.1 |
0,000 giây |
asyncio, không Happy Eyeballs |
localhost, proxy chỉ IPv4 |
127.0.0.1 |
2,038 giây |
asyncio, happy_eyeballs_delay 0,25 |
localhost, proxy chỉ IPv4 |
127.0.0.1 |
0,261 giây |
requests qua proxy |
http://localhost:9570 |
200 |
2,047 giây |
requests qua proxy |
http://127.0.0.1:9570 |
200 |
0,015 giây |
curl -x |
http://localhost:9570 |
127.0.0.1, 200 |
kết nối 0,218 giây |
curl -x |
http://127.0.0.1:9570 |
127.0.0.1, 200 |
kết nối 0,0006 giây |
Ba dòng đầu cho thấy hàm thử lần lượt mất hơn hai giây vì thử ::1 trước, bị từ chối theo kiểu Windows, rồi mới sang 127.0.0.1. Khi proxy nghe ở ::1 thì nhanh vì địa chỉ đầu đã đúng.
requests chậm đúng như hàm thử lần lượt
Request qua proxy viết bằng localhost mất 2,047 giây, gần bằng create_connection. requests dùng urllib3, và urllib3 kết nối theo kiểu thử lần lượt từng địa chỉ do getaddrinfo trả về. Với crawler gửi hàng nghìn request, nếu mỗi request mở kết nối mới, mỗi request mất thêm hai giây.
Đổi proxy thành http://127.0.0.1:9570 đưa thời gian về 0,015 giây. Không đổi gì khác. Một chữ localhost trong cấu hình có thể làm crawler chậm hơn trăm lần ở bước kết nối.
curl có Happy Eyeballs sẵn
curl kết nối tới proxy localhost trong 0,218 giây và dùng địa chỉ 127.0.0.1. curl có Happy Eyeballs với khoảng chờ mặc định 200 mili giây theo trang man curl ở tùy chọn --happy-eyeballs-timeout-ms. Sau 200 mili giây nhánh ::1 chưa xong, curl mở nhánh 127.0.0.1 và nhánh này thắng.
Điều này giải thích một hiện tượng hay gặp: thử proxy bằng curl thấy nhanh, đưa vào script Python thì chậm. Hai công cụ chọn địa chỉ theo hai cách khác nhau.
asyncio cần bật tay
asyncio của Python có Happy Eyeballs nhưng mặc định tắt. Gọi open_connection hoặc create_connection không có tham số happy_eyeballs_delay thì hành vi giống thử lần lượt, mất 2,038 giây. Truyền happy_eyeballs_delay=0.25, giá trị mà tài liệu asyncio ghi là khuyến nghị của RFC 8305, thì còn 0,261 giây.
reader, writer = await asyncio.open_connection("localhost", 9570, happy_eyeballs_delay=0.25)Thư viện như aiohttp có tùy chọn tương ứng trong connector ở các phiên bản mới. Cần kiểm tài liệu của phiên bản đang dùng.
Tác động lên crawler nhiều luồng
Với crawler 20 luồng, mỗi luồng mở kết nối mới cho mỗi request, mỗi request phạt 2 giây. Nếu một request bình thường mất 0,5 giây, phần phạt làm thông lượng giảm còn khoảng một phần năm. Crawler dự kiến chạy một giờ sẽ chạy năm giờ.
Điều khó chịu là crawler không báo lỗi nào. Mọi request đều thành công, chỉ chậm. Người vận hành thường đổ lỗi cho proxy chậm hoặc trang đích chậm, đổi proxy khác cũng cấu hình bằng tên máy, và vấn đề vẫn còn.
Ca nhánh IPv6 không phản hồi
Ca giả lập 2001:db8::1 không cho độ trễ như kỳ vọng. Kết nối thẳng tới 2001:db8::1 báo lỗi trong 0,012 giây. Máy lab không có tuyến IPv6 ra ngoài, nên hệ điều hành từ chối ngay mà không gửi gói nào. Cả ba cách kết nối tới proxy.lab.test đều xong trong khoảng 0,001 giây.
Kết quả này vẫn có ích. Nó cho thấy độ trễ chỉ xuất hiện khi nhánh IPv6 thất bại chậm. Trên máy không có IPv6, nhánh IPv6 thất bại nhanh và thử lần lượt không bị phạt. Trên máy có IPv6 nhưng đường IPv6 tới proxy bị chặn im lặng, thử lần lượt sẽ chờ hết thời gian chờ kết nối, có thể tới 21 giây trên Windows.
Đọc log, gói tin và response để tách nguyên nhân khi Happy Eyeballs khi kết nối proxy
Khi crawler chậm ở bước kết nối tới proxy, nguyên nhân có thể là chọn địa chỉ, proxy quá tải hay mạng chậm. Phần này đưa cách tách.
Đo thời gian kết nối riêng
curl có biến time_connect cho thời gian tới lúc kết nối TCP xong và remote_ip cho địa chỉ thật đã dùng. Chạy curl với -w "%{time_connect} %{remote_ip}" qua proxy viết bằng tên và bằng địa chỉ IP. Nếu bản viết bằng tên chậm hơn hẳn, nghi phạm là chọn địa chỉ.
Trong Python, đo riêng bước kết nối bằng socket.create_connection tới tên proxy, như lab. Thời gian ở bước này không bao gồm xác thực proxy hay trang đích.
Dấu hiệu của chọn sai địa chỉ
Dấu hiệu |
Chọn sai địa chỉ |
Proxy quá tải |
Mạng chậm |
|---|---|---|---|
Độ trễ kết nối |
Gần như cố định, ví dụ 2 giây |
Dao động theo giờ |
Dao động |
Viết proxy bằng IP |
Hết chậm |
Vẫn chậm |
Vẫn chậm |
curl so với Python |
curl nhanh hơn |
Như nhau |
Như nhau |
Gói tin |
SYN tới IPv6 trước, rồi SYN tới IPv4 |
Bắt tay chậm |
Độ trễ khứ hồi cao |
Dấu hiệu rõ nhất là độ trễ gần như cố định. Hai giây trên Windows khi bị từ chối, hoặc đúng bằng thời gian chờ kết nối khi không phản hồi. Proxy quá tải hay mạng chậm cho độ trễ dao động.
Gói tin cho thấy gì
Bắt gói trên máy client khi kết nối tới proxy viết bằng tên, sẽ thấy gói SYN tới địa chỉ IPv6 của proxy trước. Nếu proxy không nghe IPv6, thấy RST quay về hoặc không thấy gì. Sau đó mới thấy SYN tới địa chỉ IPv4.
Với Happy Eyeballs, hai gói SYN cách nhau khoảng 200 tới 250 mili giây. Với thử lần lượt, khoảng cách bằng thời gian thất bại của nhánh đầu. Bài Wireshark proxy có cách lọc gói theo địa chỉ proxy.
Đọc lỗi khi cả hai nhánh đều hỏng
Khi cả IPv6 lẫn IPv4 tới proxy đều thất bại, thư viện thử lần lượt chỉ báo lỗi của địa chỉ cuối cùng. Anh em thấy lỗi từ chối kết nối tới 127.0.0.1 mà không biết trước đó đã có một lần thử ::1 thất bại. Thời gian lỗi dài hơn thường lệ là gợi ý duy nhất.
asyncio khi bật Happy Eyeballs gom lỗi của mọi nhánh. Đọc kỹ thông báo sẽ thấy cả hai địa chỉ. Đây là một lợi ích phụ khi chẩn đoán.
Log của proxy
Nếu tự quản proxy, log của proxy cho biết client kết nối bằng địa chỉ nào. Proxy nghe trên cả IPv4 và IPv6 sẽ thấy client tới bằng IPv6. Nếu chính sách cho phép theo IP chỉ khai báo IPv4 của client, kết nối IPv6 sẽ bị từ chối xác thực, sinh ra lỗi 407 hoặc 403 khó hiểu.
Đây là ca ngược: chọn được địa chỉ, kết nối nhanh, nhưng proxy nhìn thấy client bằng địa chỉ IPv6 không nằm trong danh sách cho phép. Bài xác thực proxy bằng IP whitelist hay user password giúp chọn cách xác thực tránh ca này.
Xử lý Happy Eyeballs khi kết nối proxy theo bằng chứng và checklist
Checklist Happy Eyeballs
Cách xử lý đi từ đơn giản tới phức tạp. Phần lớn trường hợp dừng ở bước đầu.
Viết proxy bằng địa chỉ IP
Nếu proxy có địa chỉ cố định, viết thẳng địa chỉ IP trong cấu hình. Không có lần tra DNS, không có chọn địa chỉ. Đây là cách đơn giản nhất và lab cho thấy hiệu quả: 2,047 giây xuống 0,015 giây.
Với proxy cục bộ, viết 127.0.0.1 thay cho localhost. Nếu proxy nghe trên ::1, viết [::1] với dấu ngoặc vuông trong URL.
Cho proxy nghe trên cả hai giao thức
Nếu tự quản proxy và muốn giữ tên máy, cấu hình proxy nghe trên cả IPv4 và IPv6. Khi đó địa chỉ nào đứng đầu cũng kết nối được ngay. Với Squid, thêm dòng http_port cho địa chỉ IPv6. Với proxy chạy trong Docker, chú ý Docker có bật IPv6 cho mạng hay không.
Bỏ bản ghi AAAA nếu không phục vụ IPv6
Nếu tên proxy có bản ghi AAAA nhưng proxy không phục vụ IPv6, bản ghi đó là nguồn gây chậm cho mọi client. Gỡ bản ghi AAAA khỏi DNS cho tên proxy, hoặc dùng tên riêng chỉ có bản ghi A cho cổng proxy.
Ép giao thức ở phía client
curl có tùy chọn -4 để chỉ dùng IPv4. Trong Python, có thể truyền family khi tra địa chỉ nếu tự viết kết nối. Với requests, không có tùy chọn sẵn để ép IPv4 cho proxy. Cách thường dùng là viết proxy bằng IP, hoặc vá hàm chọn họ địa chỉ của urllib3, cách này ảnh hưởng toàn tiến trình.
Bật Happy Eyeballs khi có thể
Với asyncio, truyền happy_eyeballs_delay=0.25. Với curl, giữ mặc định. Với thư viện khác, kiểm tài liệu xem có tùy chọn tương tự không. Happy Eyeballs không thay cho cấu hình đúng, nhưng giới hạn thiệt hại khi một địa chỉ hỏng.
Docker, WSL và máy ảo
Proxy chạy trong Docker Desktop hay WSL trên Windows thường được truy cập qua localhost. Tùy cấu hình chuyển tiếp cổng, cổng đó có thể chỉ mở trên IPv4 hoặc chỉ trên IPv6 của máy chủ. Đây là nơi hay gặp đúng ca của lab.
Cách kiểm nhanh là kết nối thử tới cả 127.0.0.1 và [::1] ở cổng proxy. Địa chỉ nào kết nối được ngay là địa chỉ nên ghi trong cấu hình. Nếu cả hai đều được, dùng localhost cũng không sao.
Giữ kết nối
Độ trễ chọn địa chỉ chỉ xảy ra khi mở kết nối mới. Crawler dùng lại kết nối tới proxy bằng Session hoặc Client chỉ chịu độ trễ ở kết nối đầu. Hai giây cho một kết nối giữ suốt lô thì không đáng kể, hai giây cho mỗi request thì rất đáng kể.
Kiểm lại sau khi sửa
Sau khi đổi cấu hình, chạy lại đúng phép đo đã dùng để phát hiện: curl với time_connect, hoặc vài request Python có đo thời gian. Thời gian kết nối phải về mức vài mili giây với proxy cục bộ, hoặc bằng độ trễ khứ hồi tới proxy với proxy ở xa.
Ghi con số trước và sau vào ghi chú vận hành. Lần sau có người đổi cấu hình proxy về dạng tên máy, con số này giúp nhận ra ngay vấn đề cũ quay lại. Với crawler chạy định kỳ, thêm thời gian kết nối trung bình vào log tổng kết mỗi lô là đủ để theo dõi lâu dài.
Giới hạn suy luận của bài
Lab chạy trên Windows với loopback, nên độ trễ hai giây là hành vi riêng của Windows khi bị từ chối. Linux trả lỗi từ chối ngay, nên cùng ca localhost trên Linux sẽ không chậm. Ca nhánh IPv6 không phản hồi chưa đo được vì máy lab không có tuyến IPv6, phần mô tả dựa trên RFC 8305 và số đo SYN retry của Windows.
Hành vi của urllib3 và aiohttp có thể thay đổi giữa các phiên bản. Bài ghi theo requests 2.34.2 và Python 3.12.10 ngày 29/10/2026.
Checklist Happy Eyeballs khi kết nối proxy
- Tra DNS tên proxy, xem có cả bản ghi A và AAAA không.
- Kiểm proxy nghe trên giao thức nào.
- Đo thời gian kết nối khi viết proxy bằng tên và bằng IP.
- So curl với Python để biết thư viện có Happy Eyeballs không.
- Ưu tiên viết proxy bằng IP, hoặc 127.0.0.1 cho proxy cục bộ.
- Cho proxy nghe cả hai giao thức, hoặc gỡ bản ghi AAAA không dùng.
- Bật happy_eyeballs_delay khi dùng asyncio.
- Giữ kết nối để độ trễ chỉ xảy ra một lần.
Khi nhà cung cấp cấp proxy bằng địa chỉ IP cố định, anh em không phải lo chọn sai địa chỉ ở bước kết nối. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5; anh em có thể mua proxy uy tín tại trang chủ ProxyVN rồi viết thẳng địa chỉ IP vào cấu hình crawler.
Câu hỏi thường gặp về Happy Eyeballs khi kết nối proxy
Proxy IPv6 có bị ảnh hưởng không?
Proxy thoát ra bằng IPv6 là chuyện khác. Bài này nói về bước client kết nối tới proxy. Proxy thoát bằng giao thức nào cũng có thể gặp vấn đề chọn địa chỉ nếu tên proxy có hai loại bản ghi.
Trình duyệt có bị không?
Chrome, Firefox và Safari đều có Happy Eyeballs, nên trình duyệt ít bị chậm vì lý do này. Script và công cụ dòng lệnh mới là nơi hay gặp.
Vì sao trên Linux không thấy chậm?
Linux trả lỗi từ chối kết nối ngay, không thử lại SYN như Windows. Nếu nhánh IPv6 bị chặn im lặng thì Linux vẫn chậm, có khi lâu hơn Windows vì thời gian chờ kết nối mặc định dài hơn.
Đổi thứ tự ưu tiên IPv4 trên Windows có được không?
Được, Windows có cách chỉnh bảng ưu tiên tiền tố để IPv4 đứng trước. Nhưng đây là thay đổi toàn máy, ảnh hưởng mọi ứng dụng. Viết proxy bằng IP là cách hẹp và an toàn hơn.
SOCKS5 có gặp vấn đề này không?
Có, ở bước kết nối tới proxy SOCKS5 nếu proxy viết bằng tên máy. Bước bắt tay SOCKS5 diễn ra sau khi TCP đã kết nối, nên độ trễ chọn địa chỉ cộng thẳng vào thời gian mỗi kết nối.
Có cần lo nếu proxy cấu hình bằng IP?
Không. Không có tra DNS ở client nên không có chọn địa chỉ.
Happy Eyeballs có ảnh hưởng IP mà trang đích thấy không?
Không. Trang đích thấy IP thoát của proxy. Happy Eyeballs ở client chỉ quyết định client nói chuyện với proxy bằng địa chỉ nào.
Happy Eyeballs khi kết nối proxy và những điều cần nhớ
Happy Eyeballs khi kết nối proxy quyết định một địa chỉ hỏng có làm chậm mọi kết nối hay không. Lab đo thật: proxy localhost chỉ nghe IPv4 làm requests chậm 2,05 giây mỗi kết nối, viết 127.0.0.1 còn 0,015 giây, asyncio bật Happy Eyeballs còn 0,26 giây. Viết proxy bằng IP, giữ kết nối, bật Happy Eyeballs khi có. Cần proxy IP cố định để tránh lỗi chọn địa chỉ khi tính tới Happy Eyeballs khi kết nối proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.
