EDNS Client Subnet và proxy: dải IP nào lộ ở tầng DNS

EDNS Client Subnet và proxy là chuyện một phần địa chỉ IP thật của anh em có thể đi tới máy chủ DNS của trang đích qua resolver, dù request HTTP đã đi qua proxy ở nước khác. ECS là phần mở rộng DNS cho phép resolver như Google Public DNS gửi kèm dải /24 của người hỏi, để trang đích trả địa chỉ máy chủ gần người dùng nhất. ProxyVN gửi truy vấn DNS thật tới 8.8.8.8 và 1.1.1.1 ngày 29/10/2026, có và không có tùy chọn ECS, rồi đọc phản hồi để xem mỗi bên thấy gì.

EDNS Client Subnet và proxy: lớp nào quyết định hành vi

Một request tới trang web gồm hai bước: tra DNS để lấy địa chỉ máy chủ, rồi gửi request HTTP tới địa chỉ đó. Proxy thường chỉ thay đường đi của bước hai. Bước một có thể vẫn diễn ra trên máy anh em, với resolver của máy anh em.

Ba bên trong một lần tra DNS

Ba bên trong một lần tra DNS

Bên thứ nhất là máy của anh em, gửi câu hỏi tới resolver. Bên thứ hai là resolver đệ quy, như máy DNS của nhà mạng, 8.8.8.8 hay 1.1.1.1, đi hỏi thay. Bên thứ ba là máy chủ DNS có thẩm quyền của tên miền, nơi giữ câu trả lời thật.

Không có ECS, máy chủ có thẩm quyền chỉ thấy địa chỉ của resolver. Nó không biết ai đứng sau resolver. Với ECS, resolver gửi kèm một phần địa chỉ của người hỏi, thường là /24 với IPv4. Máy chủ có thẩm quyền nhờ đó biết người hỏi ở vùng nào.

ECS để làm gì

RFC 7871 mô tả ECS như cách giúp mạng phân phối nội dung chọn máy chủ gần người dùng. Resolver công cộng có máy chủ ở nhiều nước. Nếu chỉ dựa vào địa chỉ resolver, người dùng ở Việt Nam đi qua resolver đặt ở Singapore có thể nhận máy chủ ở Singapore thay vì máy gần hơn.

ECS giải chuyện đó bằng cách cho máy chủ có thẩm quyền biết dải mạng thật. Đổi lại, một phần địa chỉ của người dùng đi xa hơn bình thường.

Proxy không đụng tới bước DNS nếu tra ở máy anh em

Với proxy HTTP, máy client gửi tên trang đích cho proxy, proxy tự tra DNS. Lúc đó ECS, nếu có, mang dải mạng của proxy chứ không phải của anh em. Với SOCKS5 kiểu socks5h cũng vậy.

Với SOCKS5 kiểu socks5 không có h, hay với ứng dụng tự tra DNS trước rồi mới mở kết nối qua proxy, bước DNS diễn ra trên máy anh em. Resolver của máy anh em có thể gửi ECS mang dải mạng thật. Request HTTP đi từ IP proxy, còn máy chủ DNS của trang đích lại thấy dải IP nhà mạng của anh em.

Vì sao crawler cần quan tâm

Với phần lớn crawler, ECS không làm hỏng kết quả. Nhưng có ba trường hợp cần để ý. Trường hợp thứ nhất là thu thập nội dung theo vùng, như giá theo quốc gia hay kết quả tìm kiếm theo vùng, khi CDN trả nội dung khác nhau theo máy chủ được chọn. Trường hợp thứ hai là đo tốc độ trang từ nhiều vùng qua proxy, khi máy chủ CDN được chọn theo vùng của DNS chứ không theo vùng của proxy.

Trường hợp thứ ba là các hệ thống chống gian lận ghép tín hiệu từ nhiều tầng. Một phiên đăng nhập có DNS từ dải Việt Nam và HTTP từ IP ở nước khác là một tín hiệu bất thường, cộng thêm với múi giờ, ngôn ngữ và fingerprint. Bài geo-targeting proxy là gì bàn về việc chọn proxy theo vùng.

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

Bài DNS leak khi dùng proxy xử lý việc truy vấn DNS đi ngoài proxy. Bài DNS over HTTPS có một đoạn nhắc ECS. Bài này đi vào ECS: nó mang gì, resolver nào gửi, máy chủ nào thấy, và kiểm bằng truy vấn thật.

Giải thích ECS gửi dữ liệu mạng ở tầng DNS và vai trò resolver khi xét EDNS Client Subnet và proxy

Phần này đi vào cấu trúc tùy chọn ECS, quy định cắt bớt địa chỉ và cách resolver công cộng xử lý.

Tùy chọn ECS mang gì

ECS là một tùy chọn trong phần EDNS của gói DNS. Nó có bốn trường: họ địa chỉ, độ dài tiền tố nguồn, độ dài tiền tố phạm vi và địa chỉ. Độ dài tiền tố nguồn cho biết bao nhiêu bit đầu của địa chỉ được gửi. Với /24, ba số đầu của IPv4 được gửi, số cuối là 0.

Khi máy chủ có thẩm quyền trả lời, nó ghi độ dài tiền tố phạm vi: câu trả lời này đúng cho dải rộng bao nhiêu. Resolver dùng phạm vi này để biết câu trả lời có thể dùng lại cho người hỏi khác trong cùng dải hay không.

Cắt bớt địa chỉ vì quyền riêng tư

RFC 7871 khuyến khích resolver cắt địa chỉ IPv4 còn 24 bit và IPv6 còn 56 bit để giấu một phần địa chỉ người dùng. Nhà mạng có thể cắt ngắn hơn, ví dụ 20 bit, nếu biết cả dải lớn ở cùng một khu vực.

RFC cũng ghi người dùng muốn giấu địa chỉ có thể gửi tùy chọn ECS với độ dài nguồn bằng 0. Resolver tôn trọng sẽ không gửi phần địa chỉ nào cho máy chủ có thẩm quyền. Resolver không muốn chuyển tiếp dữ liệu địa chỉ nhận được từ client nên trả REFUSED.

Resolver công cộng xử lý khác nhau

8.8.8.8 và 1.1.1.1

Google Public DNS gửi ECS tới máy chủ có thẩm quyền hỗ trợ nó. Tài liệu ECS của Google Public DNS hướng dẫn máy chủ có thẩm quyền cách hỗ trợ ECS và cách ghi phạm vi.

Cloudflare 1.1.1.1 không gửi ECS. Câu hỏi thường gặp của 1.1.1.1 ghi rõ resolver này không đưa thông tin IP của client vào truy vấn gửi máy chủ có thẩm quyền, trừ một tên miền gỡ lỗi của Akamai.

Resolver của nhà mạng Việt Nam có gửi ECS hay không tùy từng nhà mạng, bài này không kiểm. Resolver nội bộ công ty thường không gửi.

Phạm vi và bộ nhớ đệm của resolver

Resolver lưu câu trả lời theo phạm vi máy chủ có thẩm quyền ghi. Câu trả lời phạm vi /16 được dùng lại cho mọi người hỏi trong dải /16 đó. Câu trả lời phạm vi /0 được dùng lại cho mọi người. Phạm vi hẹp làm resolver phải hỏi lại nhiều hơn.

Tài liệu của Google Public DNS nêu ví dụ về chuyện hai câu trả lời có phạm vi chồng nhau làm resolver trả câu trả lời của dải rộng cho người hỏi ở dải hẹp. Đây là lý do cùng một dải ECS đôi khi nhận câu trả lời khác nhau theo thời điểm, tùy câu nào đang nằm trong bộ nhớ đệm.

IPv6 và ECS

Với IPv6, RFC khuyến nghị cắt còn 56 bit. Một máy ở nhà thường nhận cả một dải IPv6 /56 hoặc /64 từ nhà mạng, nên /56 thường tương ứng một hộ gia đình. Mức chi tiết này cao hơn /24 của IPv4, vốn chứa nhiều khách hàng.

Nếu máy có IPv6 và resolver gửi ECS cho truy vấn qua IPv6, dải được gửi có thể nhận diện hộ gia đình rõ hơn. Lab không kiểm truy vấn IPv6 vì máy lab không có tuyến IPv6 ra ngoài.

ECS khác IP geolocation

IP geolocation là việc trang web tra cơ sở dữ liệu vị trí theo địa chỉ IP đã kết nối tới nó, tức IP thoát của proxy. Bài IP geolocation giải thích phần này. ECS là thông tin ở tầng DNS, chỉ máy chủ DNS có thẩm quyền thấy, máy chủ web không thấy trực tiếp.

Nhưng nếu máy chủ DNS và máy chủ web cùng một chủ, như mạng phân phối nội dung lớn, chủ đó có cả hai thông tin. Họ có thể thấy truy vấn DNS từ dải Việt Nam và request HTTP từ IP proxy Mỹ trong cùng một khoảng thời gian.

Thiết kế lab EDNS Client Subnet và proxy: phiên bản và phép đo

Lab chạy ngày 29/10/2026 lúc 21:25 giờ Việt Nam trên Windows 10, Python 3.12.10, dnspython 2.9.0. Truy vấn gửi bằng UDP trực tiếp tới 8.8.8.8 và 1.1.1.1 từ mạng của máy lab, không qua proxy.

Tên miền gỡ lỗi của Google

Tên o-o.myaddr.l.google.com là tên Google dùng để gỡ lỗi. Truy vấn bản ghi TXT của tên này qua Google Public DNS trả về địa chỉ của máy resolver Google đã hỏi, và nếu có ECS thì thêm một dòng ghi dải edns0-client-subnet mà Google đã gửi. Đây là cách nhìn trực tiếp ECS từ phía máy chủ có thẩm quyền.

Các ca truy vấn

Ca một hỏi 8.8.8.8 không kèm ECS. Ca hai kèm ECS dải 14.160.32.0/24, một dải của nhà mạng Việt Nam. Ca ba kèm ECS dải 8.8.4.0/24 ở Mỹ. Ca bốn kèm ECS độ dài 0. Ca năm kèm ECS /32, tức địa chỉ đầy đủ. Ca sáu và bảy hỏi 1.1.1.1 không kèm và có kèm ECS.

Thêm một nhóm hỏi bản ghi A của www.google.com và www.youtube.com với các dải ECS khác nhau, để xem câu trả lời và phạm vi có đổi theo dải hay không.

Vì sao chọn các dải ECS này

Dải 14.160.32.0/24 thuộc một nhà mạng lớn ở Việt Nam, đại diện người dùng trong nước. Dải 8.8.4.0/24 là dải của Google ở Mỹ, luôn được định tuyến và có vị trí rõ. Dải 126.0.0.0/24 thuộc một nhà mạng ở Nhật. Ba dải ở ba vùng cho phép so phạm vi trả về.

Chọn dải có thật và được định tuyến quan trọng, vì máy chủ có thẩm quyền có thể bỏ qua ECS mang dải riêng hay dải dành cho tài liệu. Khi đó kết quả không phản ánh hành vi thật.

Không công bố dải mạng của máy lab

Ca một trả về dải /24 thật của nhà mạng máy lab. Bài không ghi con số này, chỉ ghi là dải /24 của nhà mạng. Anh em tự chạy sẽ thấy dải của mình.

Kết quả kỳ vọng

Google có ECS sẽ trả dòng edns0-client-subnet. Cloudflare không trả dòng này. ECS độ dài 0 làm Google không gửi dải nào.

Tái lập EDNS Client Subnet và proxy: luồng bình thường và ca có kiểm soát

Phần này đưa mã truy vấn và kết quả thật.

Mã truy vấn

import dns.message, dns.query, dns.edns
 
def q(server, name, rtype, ecs=None):
    opts = [dns.edns.ECSOption(ecs[0], ecs[1])] if ecs else []
    m = dns.message.make_query(name, rtype, use_edns=0, options=opts)
    r = dns.query.udp(m, server, timeout=4)
    ans = [rr.to_text() for s in r.answer for rr in s]
    ecs_back = [o.to_text() for o in r.options if isinstance(o, dns.edns.ECSOption)]
    return r.rcode(), ans, ecs_back
 
print(q("8.8.8.8", "o-o.myaddr.l.google.com", "TXT"))
print(q("8.8.8.8", "o-o.myaddr.l.google.com", "TXT", ("14.160.32.0", 24)))
print(q("1.1.1.1", "o-o.myaddr.l.google.com", "TXT"))

Kết quả với tên gỡ lỗi của Google

Bảng: Kết quả với tên gỡ lỗi của Google

Ca	Resolver	ECS gửi	Dòng edns0-client-subnet trả về	ECS trong phản hồi
1	8.8.8.8	Không	Dải /24 của nhà mạng máy lab	Không
2	8.8.8.8	14.160.32.0/24	14.160.32.0/24	14.160.32.0/24, phạm vi /24
3	8.8.8.8	8.8.4.0/24	8.8.4.0/24	8.8.4.0/24, phạm vi /24
4	8.8.8.8	0.0.0.0/0	Không có	0.0.0.0/0, phạm vi /0
5	8.8.8.8	14.160.32.17/32	Không có	Mã REFUSED, phạm vi /0
6	1.1.1.1	Không	Không có	Không
7	1.1.1.1	14.160.32.0/24	Không có	Không

Ca một là kết quả đáng chú ý nhất. Máy lab không gửi ECS, nhưng Google tự lấy địa chỉ nguồn của truy vấn, cắt còn /24 rồi gửi cho máy chủ có thẩm quyền. Máy chủ DNS của Google nhìn thấy dải mạng thật của máy lab.

Ca hai và ba cho thấy client có thể tự đặt ECS và Google chuyển tiếp đúng dải đó. Ca bốn với độ dài 0 làm Google không gửi dải nào, đúng như RFC mô tả cách giấu địa chỉ.

Ca năm gửi địa chỉ đầy đủ /32. Lần thử đầu hết thời gian chờ, lần hai Google trả mã 5, tức REFUSED, kèm ECS phạm vi /0. Google từ chối chuyển tiếp địa chỉ dài hơn mức họ chấp nhận.

Ca sáu và bảy với 1.1.1.1 không có dòng edns0-client-subnet, kể cả khi client tự gửi ECS. Cloudflare bỏ tùy chọn này, đúng như FAQ ghi.

Kết quả với bản ghi A

Bảng: Kết quả với bản ghi A

Tên	ECS gửi	Phạm vi trả về	Các địa chỉ trả về
www.google.com	Không	Không	142.251.150 tới 157
www.google.com	14.160.32.0/24	/20	142.251.150 tới 157
www.google.com	8.8.4.0/24	/24	142.251.150 tới 157
www.google.com	126.0.0.0/24	/16	142.251.150 tới 157
www.youtube.com	14.160.32.0/24	/20	142.251.150 tới 157

Địa chỉ trả về cho www.google.com nằm trong cùng một khối 142.251.150 tới 142.251.157 dù dải ECS ở Việt Nam, Mỹ hay Nhật. Google dùng anycast, nên dải ECS không làm đổi khối địa chỉ trong lần đo này. Phạm vi trả về thì khác: /20 cho dải Việt Nam, /24 cho dải Mỹ, /16 cho dải Nhật.

Phạm vi khác nhau cho thấy máy chủ có thẩm quyền của Google có đọc ECS và quyết định mức chi tiết theo vùng. Với mạng phân phối nội dung không dùng anycast, địa chỉ trả về sẽ đổi theo dải ECS. Lab chưa thử một mạng như vậy.

Đọc phần phản hồi ECS

Phần ECS trong phản hồi có hai độ dài: nguồn là dải đã gửi, phạm vi là dải câu trả lời áp dụng. Ở ca hai, cả hai đều /24, nghĩa là câu trả lời cho tên gỡ lỗi chỉ đúng với đúng dải đó. Ở ca bốn, phạm vi /0, nghĩa là câu trả lời dùng chung cho mọi người.

Khi phạm vi trả về bằng 0 dù đã gửi dải cụ thể, máy chủ có thẩm quyền không dùng ECS cho tên đó. Đây là cách nhanh để biết một tên miền có chọn câu trả lời theo vùng hay không.

Thời gian và mất gói

Mỗi truy vấn mất khoảng 50 tới 160 mili giây. Một số truy vấn UDP hết thời gian chờ ở lần đầu và thành công ở lần thử lại. Đây là mất gói bình thường của UDP, không liên quan ECS.

Đọc log, gói tin và response để tách nguyên nhân khi xét EDNS Client Subnet và proxy

Phần này giúp trả lời câu hỏi thực tế: crawler qua proxy có đang lộ dải mạng thật qua DNS không, và có ảnh hưởng tới kết quả không.

Xác định ai tra DNS cho trang đích

DNS và HTTP hai vùng

Bước đầu là biết bước DNS diễn ra ở đâu. Với proxy HTTP và HTTPS, proxy tra. Với SOCKS5, xem URL proxy là socks5 hay socks5h. Với trình duyệt cấu hình SOCKS5, xem tùy chọn proxy DNS khi dùng SOCKS. Bài cách sử dụng SOCKS5 proxy có chi tiết.

Nếu proxy tra DNS, ECS của máy anh em không liên quan. Nếu máy anh em tra, resolver nào đang dùng quyết định có ECS hay không.

Xác định resolver và ECS của nó

Chạy truy vấn TXT tới o-o.myaddr.l.google.com bằng resolver mặc định của máy. Nếu kết quả có dòng edns0-client-subnet với dải nhà mạng của anh em, resolver đó đang đi qua Google và Google đang gửi ECS. Tên gỡ lỗi này chỉ có ý nghĩa khi truy vấn đi tới Google, với resolver khác cần cách kiểm riêng.

Nếu máy dùng resolver của nhà mạng, kiểm cấu hình mạng để biết địa chỉ resolver, rồi hỏi tên gỡ lỗi tương ứng nếu có. Akamai có tên whoami.ds.akahelp.net cho mục đích tương tự với nhiều resolver.

Bảng triệu chứng

Bảng: Bảng triệu chứng

Hiện tượng khi crawl qua proxy	Có thể do ECS	Lý do khác cần loại trước
Trang trả nội dung vùng Việt Nam dù proxy ở Mỹ	Có, nếu DNS tra ở máy và CDN chọn máy chủ theo ECS	Cookie vùng, header ngôn ngữ, IP proxy không đúng vùng
Trang chậm bất thường qua proxy	Có, nếu DNS trả máy chủ gần Việt Nam mà request đi từ Mỹ	Proxy chậm, trang đích chậm
Hệ thống chống gian lận nghi ngờ	Có thể, khi DNS và HTTP ở hai vùng	Fingerprint, múi giờ, WebRTC
Không có khác biệt gì	ECS không gửi hoặc trang không dùng ECS	Không cần xử lý

Dòng hai là triệu chứng ít người nghĩ tới. Crawler tra DNS ở Việt Nam, nhận địa chỉ máy chủ CDN gần Việt Nam, rồi gửi request từ proxy Mỹ tới máy chủ đó. Đường đi vòng qua Thái Bình Dương hai lần.

Kiểm nhanh bằng dòng lệnh

Không cần viết script, lệnh dig trên Linux hoặc macOS có tùy chọn +subnet để gửi ECS và hiển thị phần OPT của phản hồi. Truy vấn TXT tên gỡ lỗi của Google kèm +subnet bằng dải muốn thử là đủ để thấy Google chuyển tiếp gì. nslookup của Windows không hỗ trợ ECS, nên trên Windows dùng script như lab.

Khi kiểm resolver mặc định của máy, bỏ +subnet. Kết quả sẽ cho biết resolver có tự thêm ECS hay không.

Ghi lại kết quả để so sau

ECS phụ thuộc resolver, nhà mạng và chính sách có thể đổi. Ghi lại ngày kiểm, resolver, dải trả về và phạm vi. Khi crawler bắt đầu nhận nội dung vùng lạ, so với bản ghi cũ để biết có gì thay đổi ở tầng DNS.

Gói tin cho thấy gì

Wireshark hiển thị tùy chọn ECS trong phần OPT của gói DNS, gồm họ địa chỉ, độ dài tiền tố và địa chỉ. Bắt gói DNS trên máy client chỉ thấy ECS nếu client tự gửi. ECS do resolver thêm vào không đi qua máy client, chỉ thấy được qua tên gỡ lỗi như lab dùng.

Xử lý EDNS Client Subnet và proxy theo bằng chứng và checklist

Checklist ECS

Cách xử lý đi từ đơn giản: để proxy tra DNS. Phần lớn trường hợp dừng ở đó.

Để proxy tra DNS

Dùng proxy HTTP hoặc SOCKS5 kiểu socks5h. Trong requests, viết socks5h trong URL proxy. Trong curl, dùng --socks5-hostname thay cho --socks5. Khi proxy tra DNS, ECS nếu có sẽ mang dải của proxy, khớp với IP thoát.

Đây cũng là cách chống rò DNS nói chung. Một thay đổi giải cả hai vấn đề. Với crawler viết bằng httpx hay aiohttp, kiểm thư viện có hỗ trợ socks5h không, vì không phải thư viện nào cũng hiểu chữ h giống requests.

Kiểm lại sau khi đổi cấu hình

Sau khi chuyển sang socks5h hoặc proxy HTTP, cần kiểm lại. Cho crawler gọi một trang hiển thị thông tin DNS và IP, hoặc bắt gói trên máy client để chắc không còn truy vấn DNS tới tên trang đích. Nếu vẫn thấy truy vấn, có thành phần nào đó trong ứng dụng tự tra DNS trước khi gửi qua proxy.

Thành phần hay tự tra DNS là thư viện kiểm tra chứng chỉ, bộ lấy robots.txt chạy riêng, hoặc mã ghi log tra ngược tên. Mỗi thứ cần được đưa qua proxy hoặc tắt bước tra DNS.

Đổi resolver khi phải tra DNS ở máy

Nếu ứng dụng buộc phải tra DNS ở máy, dùng resolver không gửi ECS như 1.1.1.1. Lab cho thấy 1.1.1.1 không gửi ECS kể cả khi client tự đặt. Hoặc tự gửi ECS độ dài 0 nếu thư viện DNS cho phép, như ca bốn của lab với Google.

Gửi ECS của vùng mong muốn

Ngược lại, khi kiểm thử nội dung theo vùng, có thể chủ động gửi ECS của dải mạng ở vùng cần thử để nhận câu trả lời DNS cho vùng đó. Cách này hợp với kiểm tra cấu hình CDN, không thay được proxy vì request HTTP vẫn đi từ IP thật. Bài kiểm thử website theo khu vực có cách làm đầy đủ bằng proxy.

Proxy tự dựng và resolver của proxy

Khi tự dựng proxy trên máy chủ thuê, proxy dùng resolver của máy chủ đó. Nếu resolver là Google Public DNS, ECS sẽ mang dải của máy chủ thuê, khớp vùng với IP thoát. Đó là hành vi mong muốn.

Nếu máy chủ thuê đặt ở một vùng nhưng dùng resolver đặt ở vùng khác không gửi ECS, máy chủ có thẩm quyền chỉ thấy vùng của resolver. CDN có thể chọn máy chủ theo vùng resolver, xa với IP thoát. Đặt resolver cùng vùng hoặc dùng resolver có ECS cho máy chủ proxy giúp tránh lệch.

Crawler bất đồng bộ dùng resolver riêng

Một số thư viện bất đồng bộ như aiohttp có thể dùng bộ phân giải riêng thay vì của hệ điều hành. Khi kết hợp với proxy SOCKS5 không có h, bộ phân giải này tra DNS ở máy client. Kiểm cấu hình thư viện để biết DNS đi đâu, rồi áp cùng cách xử lý.

Khi nào nên để ECS

ECS không phải lúc nào cũng cần tắt. Với người dùng thường không dùng proxy, ECS giúp nhận máy chủ CDN gần hơn và tải trang nhanh hơn. Với crawler mà proxy đặt cùng vùng với máy, ECS của máy và vùng proxy trùng nhau, không gây lệch. Chỉ cần xử lý khi DNS và HTTP đi từ hai vùng khác nhau.

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

Lab chỉ kiểm hai resolver công cộng từ một mạng nhà ở Việt Nam, vào một thời điểm. Hành vi của resolver nhà mạng và của các mạng phân phối nội dung khác chưa được kiểm. Kết quả với www.google.com cho thấy anycast không đổi khối địa chỉ theo ECS, nhưng không suy ra được cho mọi trang.

Ca /32 bị REFUSED là quan sát một lần, có thể phụ thuộc chính sách của Google tại thời điểm đó. Tài liệu chính thức đọc ngày 29/10/2026.

Checklist EDNS Client Subnet và proxy

• Xác định proxy hay máy client tra DNS cho trang đích.
• Ưu tiên proxy HTTP hoặc socks5h để proxy tra DNS.
• Nếu máy client tra DNS, kiểm resolver bằng tên gỡ lỗi o-o.myaddr.l.google.com.
• Dùng resolver không gửi ECS khi cần giấu dải mạng.
• Hoặc gửi ECS độ dài 0 nếu thư viện cho phép.
• Khi nội dung theo vùng sai, loại cookie, ngôn ngữ và IP proxy trước rồi mới nghĩ tới ECS.
• Khi kiểm CDN theo vùng, có thể gửi ECS của vùng cần thử.

Proxy đặt ở đúng vùng và tự tra DNS sẽ cho DNS và HTTP cùng một vùng. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi để proxy tra DNS cho mọi trang đích.

Câu hỏi thường gặp về EDNS Client Subnet và proxy

ECS có lộ địa chỉ IP đầy đủ không?

Thường không. Resolver cắt còn /24 với IPv4, tức giấu số cuối. Nhưng /24 vẫn đủ để biết nhà mạng và khu vực.

Dùng VPN có giải được không?

VPN đưa cả DNS và HTTP qua đường hầm nếu cấu hình đúng, nên resolver thấy địa chỉ VPN. Nếu VPN để DNS đi ngoài đường hầm, ECS vẫn mang dải thật.

DNS over HTTPS có tắt ECS không?

Không. DoH mã hóa đường từ client tới resolver. Resolver vẫn có thể gửi ECS cho máy chủ có thẩm quyền. Cần chọn resolver không gửi ECS.

Trình duyệt chống phát hiện có bị ảnh hưởng không?

Có, nếu trình duyệt tra DNS ở máy trong khi đi web qua proxy. Nhiều trình duyệt chống phát hiện cho proxy tra DNS khi dùng SOCKS5, nhưng nên kiểm từng hồ sơ. Kiểm bằng trang kiểm tra rò DNS khi đã bật proxy.

Máy chủ web có thấy ECS không?

Không trực tiếp. Chỉ máy chủ DNS có thẩm quyền thấy. Nếu cùng một chủ vận hành cả hai, họ có thể ghép thông tin.

Proxy dân cư có khác proxy datacenter về ECS không?

Khác ở dải mà ECS mang khi proxy tra DNS. Proxy dân cư tra DNS bằng resolver của mạng dân cư, dải ECS là dải dân cư. Proxy datacenter cho dải của trung tâm dữ liệu. Với trang chọn nội dung theo vùng, cả hai đều cho đúng vùng nếu proxy đặt đúng nước.

Có cần lo ECS nếu chỉ crawl trang tĩnh?

Thường không. ECS chủ yếu ảnh hưởng việc chọn máy chủ CDN. Với trang không dùng CDN theo vùng, khác biệt rất nhỏ.

EDNS Client Subnet và proxy và những điều cần nhớ

EDNS Client Subnet và proxy liên quan khi DNS được tra ở máy anh em mà request lại đi qua proxy. Lab thật cho thấy 8.8.8.8 tự gửi dải /24 nhà mạng của máy lab, 1.1.1.1 không gửi, ECS độ dài 0 giấu được dải. Để proxy tra DNS bằng proxy HTTP hoặc socks5h là cách gọn nhất. Cần proxy đúng vùng khi xử lý EDNS Client Subnet và proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.