Hướng dẫn

Hướng dẫn rò rỉ DNS: đóng WebRTC, header và DNS leak

8 tháng 10, 2026đọc 14 phút

Rò rỉ DNS, ứng viên WebRTC hoặc rò rỉ header lộ địa chỉ thật trước khi IP lối ra có ý nghĩa. Đóng kênh bằng socks5h, dump ICE và bài echo.

Rò rỉ DNS xảy ra khi tên máy chủ đích được phân giải trước khi đường hầm proxy tồn tại. Yêu cầu HTTP có thể đi ra qua gw.weproxy.com.tr, trong khi truy vấn vẫn chạm bộ phân giải văn phòng, router nhà hoặc endpoint DoH của trình duyệt. Nhật ký đó giữ IP thật của máy khách và tên vừa được tra. Ứng viên ICE của WebRTC cùng header Forwarded mở kênh thứ hai và thứ ba trong cùng một phiên.

Bài này tách bắt tay TCP khỏi thứ tự phân giải, chỉ ra socks5h khác DNS cục bộ thế nào, và giải thích vì sao UDP của trình duyệt thường nằm ngoài hồ sơ HTTP proxy. Ví dụ dùng cURL, Python và Node.js. Mục tiêu là đặt IP lối ra và mặt định danh (DNS, ICE, header) trên cùng một đường. IP lối ra sạch không đủ khi rò rỉ còn mở.

Rò rỉ DNS xảy ra trước IP lối ra

Mở https://example.com là hai việc. Phân giải hỏi tên trỏ tới địa chỉ nào. Vận chuyển hỏi TCP (và TLS) tới địa chỉ đó bằng cách nào. Proxy thường chỉ nhận việc thứ hai. Việc thứ nhất ở lại máy khách thì đó là rò rỉ DNS.

Bộ phân giải thấy IP nguồn của truy vấn, tên chính xác (QNAME) và kiểu (A, AAAA, HTTPS). Site đích không thấy nhật ký này. Bên vận hành bộ phân giải thì thấy. Đường thu thập log, báo cáo minh bạch hoặc router cấu hình sai biến dấu vết đó thành rủi ro vận hành.

DNS over HTTPS không tự đóng vấn đề. DoH vẫn là một yêu cầu HTTPS. Nếu yêu cầu đó đi vòng hồ sơ proxy, bộ phân giải vẫn thấy IP thật của máy khách cùng QNAME. Nếu chính DoH đi qua proxy, bộ phân giải thấy lối ra proxy. Câu hỏi không phải “DNS đã mã hóa chưa?”. Câu hỏi là “IP nào đã gửi truy vấn?”.

Cách thử: chọn một tên bạn kiểm soát, ví dụ probe-20261008.example.com. Đặt máy khách sau proxy, yêu cầu tên đó một lần, rồi đọc nhật ký DNS có thẩm quyền. Nguồn không phải IP lối ra mong đợi thì rò rỉ DNS là thật. Các trang “DNS leak test” công khai minh họa cùng ý. Nhật ký của bạn chắc hơn, vì bạn thấy bộ phân giải nào đã trả lời.

Bắt tay TCP và thứ tự phân giải

Bắt tay ba bước của TCP (SYN, SYN-ACK, ACK) chỉ bắt đầu sau khi đã biết một địa chỉ. Với proxy, địa chỉ đó không phải lúc nào cũng là origin. Trên HTTP proxy, máy khách mở TCP tới proxy trước, rồi xin đường hầm bằng CONNECT. SOCKS5 làm điều tương tự bằng kênh điều khiển. Bắt tay với origin chạy bên trong đường hầm sau khi đường hầm đã lên.

Thứ tự gần đúng:

Máy khách phân giải tên proxy (gw.weproxy.com.tr). Truy vấn này có thể ở cục bộ. Đó là tên cổng, không phải site đích.
Máy khách mở TCP tới proxy và xác thực.
Máy khách hoặc gửi tên máy chủ cho proxy, hoặc tự phân giải trước.
Proxy mở TCP tới origin (và phân giải nếu bước 3 gửi tên máy chủ).
Máy khách gửi TLS ClientHello trong đường hầm. SNI mang tên origin. Đó là siêu dữ liệu, tách khỏi DNS.

Nếu bước 3 phân giải cục bộ, rò rỉ DNS xong trước bắt tay với origin. Thấy TLS “qua proxy” không xóa dòng nhật ký đó.

HTTP CONNECT để tên máy chủ ở proxy

HTTP proxy mang HTTPS bằng phương thức CONNECT. Máy khách gửi CONNECT example.com:443 HTTP/1.1. Tên máy chủ đi tới proxy. Máy khách đúng cách không biến tên đó thành bản ghi A trước. Proxy mở TCP tới origin, trả 200 Connection Established, máy khách hoàn tất TLS trong đường hầm.

Trong mô hình này, truy vấn DNS của đích không được chạm bộ phân giải của máy khách. Nếu vẫn chạm, thư viện đã gọi getaddrinfo trước CONNECT. Một số máy khách HTTP cũ khai đã cấu hình proxy nhưng vẫn phân giải cục bộ. Đối chiếu bằng nhật ký. Đừng tin mỗi nhãn giao thức.

Với HTTP thuần, máy khách gửi URL tuyệt đối: GET http://example.com/path. Phân giải vẫn nằm ở proxy. Công việc hằng ngày hầu hết là đường TLS CONNECT.

Cổng WeProxy cần tên người dùng và mật khẩu tại gw.weproxy.com.tr:8989. Nếu mật khẩu có @, : hoặc /, phải mã hóa phần trăm trong URL. Nếu không, máy khách coi tên người dùng là host và CONNECT không bắt đầu. Đó là lỗi kết nối, không phải rò rỉ, và các đội hay lẫn hai việc.

SOCKS5, DNS cục bộ và socks5h

SOCKS5 không xem byte ứng dụng. RFC 1928 mang đích dưới dạng IPv4 (ATYP 0x01), tên miền (ATYP 0x03) hoặc IPv6 (ATYP 0x04). Tên miền nghĩa là proxy phân giải. Địa chỉ IPv4 nghĩa là máy khách đã phân giải.

socks5h không phải giao thức riêng. Đó là lược đồ curl và nhiều thư viện dùng để nói “gửi tên máy chủ cho proxy”. Trong curl, --socks5 phân giải cục bộ. --socks5-hostname và socks5h:// dùng ATYP 0x03. Cùng mật khẩu, cùng cổng, đường DNS khác.

Đừng nhầm với UDP. DNS cổ điển là UDP/53, nhưng DNS từ xa qua SOCKS5 không cần UDP ASSOCIATE. Máy khách không phát truy vấn. Nó gửi tên máy chủ trên kênh điều khiển, và proxy dùng bộ phân giải của chính nó. UDP ASSOCIATE dành cho game, thoại và một số đường STUN. Hướng dẫn UDP proxy và so sánh HTTP với SOCKS5 tách các lớp này.

Gói residential tĩnh tại Thổ Nhĩ Kỳ cung cấp HTTP và SOCKS5 thuần. UDP ASSOCIATE không có trên các gói đó. Điều này không chặn DNS từ xa qua socks5h. SOCKS5 không có UDP vẫn mang tên máy chủ dạng ATYP 0x03. Việc cần UDP phải theo ma trận vị trí. Buộc bài kiểm rò rỉ DNS vào huy hiệu UDP sẽ cho âm tính giả.

Vì sao rò rỉ WebRTC đi vòng proxy

WebRTC là cách trình duyệt gom IP ứng viên cho media. RTCPeerConnection tạo ứng viên host từ giao diện cục bộ, ứng viên server-reflexive qua STUN và ứng viên relay qua TURN. Ứng viên host và server-reflexive là socket UDP không đi qua HTTP proxy của trang. Hồ sơ “mọi lưu lượng trình duyệt” thường chỉ đưa TCP 80/443 vào đường hầm.

Lối ra của trang có thể trông như residential trong khi dòng ICE vẫn hiện IP nhà hoặc văn phòng. Peer, hoặc chính script của trang, có thể đọc ứng viên đó. Kiểu ứng viên được ghi trong RTCPeerConnection trên MDN. Đây là thiết kế của API, không phải lỗi ngẫu nhiên.

Chạy đoạn sau một lần trong hồ sơ bạn đưa ra production. Nếu typ host hoặc typ srflx không phải lối ra proxy, rò rỉ WebRTC đang mở.

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
})
pc.createDataChannel('leak-check')
pc.onicecandidate = (event) => {
  if (event.candidate) console.log(event.candidate.candidate)
}
const offer = await pc.createOffer()
await pc.setLocalDescription(offer)

Cách đóng là chính sách, không phải khẩu hiệu. Đặt Chromium WebRtcIPHandlingPolicy thành disable_non_proxied_udp để UDP không qua proxy ngừng tạo ứng viên. Chính sách doanh nghiệp hoặc cờ --force-webrtc-ip-handling-policy=disable_non_proxied_udp làm cùng việc. Lặp lại bản dump. Danh sách phải trống hoặc chỉ còn relay. Cờ “đã bật” không phải bằng chứng cho đến khi dòng ICE đổi.

Trình duyệt anti-detect có thể gắn chính sách vào hồ sơ. Vẫn dump ICE một lần cho mỗi hồ sơ. Khi nhân bản hồ sơ, cờ đôi khi rơi.

Rò rỉ header và đường bên IPv6

DNS và WebRTC lộ máy khách ở tầng mạng. Rò rỉ header là proxy hoặc máy khách ghi IP máy khách vào yêu cầu tới origin. Forward proxy đúng cách không gắn địa chỉ máy khách. Đừng lẫn reverse proxy (nginx, CDN) với forward proxy. Reverse proxy thêm X-Forwarded-For là kiến trúc của nó. Exit proxy của bạn chuyển giá trị đó tới origin là một lỗi riêng.

Forwarded và X-Forwarded-For

Header cần xem: X-Forwarded-For, Forwarded (RFC 7239), X-Real-IP, Via, Client-IP. Gửi một yêu cầu qua proxy tới endpoint echo. Nếu phần phản chiếu hiện IP văn phòng, địa chỉ nội bộ của hồ sơ trình duyệt, hoặc chuỗi Via do proxy thêm, hãy ghi lại.

curl -sS -x "http://USER:[email protected]:8989" \
  "https://httpbin.org/headers"

USER và PASSWORD là thông tin từ bảng điều khiển. Nếu các header đó vắng, yêu cầu này không cho thấy rò rỉ header. Nếu có, tách “mã của ta thêm” (interceptor axios, tiện ích trình duyệt) khỏi “một hộp giữa thêm”. Thư viện đôi khi đặt X-Forwarded-For: 10.x cho có vẻ hữu ích. Origin coi giá trị đó là thật.

Happy Eyeballs và IPv6

Nếu máy khách có đường IPv6 đang chạy và hồ sơ proxy chỉ IPv4, Happy Eyeballs (RFC 8305) có thể đua AAAA với A. IPv6 đi thẳng tới ISP thì không vào proxy. Dấu hiệu: echo IPv4 hiện proxy, echo IPv6 hiện tiền tố nhà.

So hai trạng thái bằng công cụ kiểm IPv6, hồ sơ bật và tắt. Việc không cần IPv6 thì tắt IPv6 cho hồ sơ đó. Đó là bản sửa hẹp. Việc cần IPv6 thì lối ra cũng phải là IPv6. Nếu không, lưu lượng bạn tưởng đã qua proxy chỉ qua một nửa. Lối ra proxy IPv6 phủ trường hợp thứ hai. Bản thân chúng không đóng rò rỉ IPv4.

So các kênh rò rỉ

Kênh	Cái gì rò	Nguyên nhân thường gặp	Cách đóng
DNS	IP thật + QNAME	Phân giải cục bộ trên SOCKS5, DoH ngoài proxy	`socks5h` / `--socks5-hostname`, đưa DoH vào đường hầm
WebRTC	IP host và srflx	UDP trình duyệt ngoài proxy	`disable_non_proxied_udp`, dump ICE
Header	IP máy khách tại origin	`X-Forwarded-For`, `Forwarded`, `Via`	Thử echo, gỡ interceptor
IPv6	Tiền tố ISP	Happy Eyeballs, proxy chỉ IPv4	Tắt IPv6 trên hồ sơ hoặc dùng lối ra IPv6
SNI	Tên origin (không phải IP của bạn)	TLS ClientHello	Siêu dữ liệu riêng; đừng gọi là rò rỉ DNS

Đừng nhầm SNI với rò rỉ DNS. SNI mang tên origin trong TLS, và origin vốn chờ tên đó. Vấn đề là một bộ phân giải mà origin không thấy, ghi cùng tên đó cạnh IP thật của bạn.

Thử từng bước với cURL, Python và Node.js

Thông tin dưới đây là chỗ giữ. Trước hết ghi địa chỉ khi chưa có proxy bằng công cụ My IP. Lặp lại với proxy, hoặc gọi api.ipify.org. Hai địa chỉ trùng nhau nghĩa là đường hầm chưa lên. Đừng bắt đầu bài DNS.

cURL

# HTTP proxy: CONNECT mang tên máy chủ
curl -sS -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS cục bộ — rủi ro rò rỉ
curl -sS --socks5 "USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS từ xa
curl -sS --socks5-hostname "USER:[email protected]:8989" https://api.ipify.org
echo

Lệnh thứ hai và thứ ba có thể in cùng một IP lối ra. Khác biệt DNS không hiện trên echo IP. Nó hiện trong nhật ký có thẩm quyền của một tên bạn kiểm soát. Lệnh thứ ba ghi IP lối ra và lệnh thứ hai ghi IP máy khách thì chẩn đoán xong.

Python

requests ghi tên máy chủ vào CONNECT khi HTTPS dùng HTTP proxy. SOCKS5 cần requests[socks] (PySocks). socks5:// trên nhiều bản cài phân giải cục bộ. DNS từ xa cần lược đồ socks5h://.

import requests

proxies = {
    "http": "socks5h://USER:[email protected]:8989",
    "https": "socks5h://USER:[email protected]:8989",
}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=30)
print(response.text)

Nếu HTTP proxy là đủ, dùng lược đồ http:// và bỏ PySocks. Tích hợp Python đi cùng dạng cổng. Khi trust_env=True, biến HTTP_PROXY đè từ điển trong mã. Trong lúc thử hãy đặt Session.trust_env = False, nếu không bạn sẽ gỡ “file ghi socks5h, tiến trình đi HTTP”.

Node.js

fetch sẵn của Node không lấy proxy hệ thống. Với HTTP proxy, ProxyAgent của undici đặt tên máy chủ lên CONNECT. Với SOCKS5 và DNS từ xa, dùng socks5h:// cùng socks-proxy-agent để agent gửi ATYP 0x03. Lớp bọc gọi dns.lookup rồi nối tới IP sẽ mang rò rỉ trở lại.

import { ProxyAgent, fetch } from 'undici'

const proxy = new ProxyAgent('http://USER:[email protected]:8989')
const response = await fetch('https://api.ipify.org', { dispatcher: proxy })
console.log(await response.text())

Tích hợp Node.js dùng cùng dạng cổng. Agent tiêm bằng global-agent hoặc NODE_OPTIONS có thể che ProxyAgent trong file. Chạy thử trong tiến trình sạch.

Giới hạn tốc độ, phiên sticky và hồ

Sau khi rò rỉ đóng, cùng IP lối ra vẫn chạm giới hạn của đích. 429 và Retry-After (ngữ nghĩa HTTP nằm trong RFC 9110) xuất hiện khi quá nhiều yêu cầu đồng thời nằm trên một địa chỉ. Phiên sticky giữ cookie và local storage ổn định. Nó cũng chất bộ đếm lên IP đó. Hồ xoay theo từng yêu cầu trải bộ đếm và cắt tính liên tục của phiên.

Đừng trộn hai bài toán. Xoay IP không đóng rò rỉ DNS. Mỗi lối ra mới, bộ phân giải vẫn thấy IP thật của bạn. Sửa DNS và WebRTC trước, rồi mới tới chính sách hồ.

import time
import requests

def get_with_backoff(url, proxies, attempts=5):
    delay = 1.0
    response = None
    for _ in range(attempts):
        response = requests.get(url, proxies=proxies, timeout=30)
        if response.status_code != 429:
            return response
        retry_after = response.headers.get("Retry-After", "")
        time.sleep(float(retry_after) if retry_after.isdigit() else delay)
        delay = min(delay * 2, 30)
    return response

Lùi thời gian không phải cách “vượt” một lần chặn. Nếu đích trả khóa tài khoản hoặc thân rỗng thay vì 429, hồ lớn hơn khuếch đại lỗi. Hạ đồng thời, tôn trọng Retry-After, và chỉ chọn địa lý khi việc thật sự cần lối ra đó.

Bước cần độ tin cao hơn hợp với hồ IP residential xoay. Khi cùng một danh tính phải ở lại nhiều giờ, hạ tầng proxy residential tĩnh giữ một lối ra cố định. Việc phòng thủ yếu và độ trễ chặt hợp các lựa chọn proxy datacenter. Chọn sản phẩm sau bài kiểm rò rỉ. Kênh trước, sản phẩm sau.

Với việc nhắm Thổ Nhĩ Kỳ, lối ra Thổ Nhĩ Kỳ giúp lớp geo của site và nhật ký DNS của bạn kể cùng một quốc gia. Ánh xạ vị trí nằm ở vị trí proxy Thổ Nhĩ Kỳ. Trỏ lối ra Thổ Nhĩ Kỳ vào site nước khác không phải lỗi giao thức. Đó là lệch pha bạn không cần, trừ khi việc đòi hỏi.

Địa chỉ IP là dữ liệu cá nhân khi nó có thể xác định một người. Ở EU, định nghĩa nằm trong Quy định 2016/679 trên EUR-Lex. Ở Thổ Nhĩ Kỳ, Luật 6698 (KVKK) đăng trên mevzuat.gov.tr. Bài này không phải tư vấn pháp lý. Nhật ký DNS và ứng viên WebRTC có thể mang IP thật của bạn tới bộ phân giải bên thứ ba hoặc script của trang. Nếu dữ liệu bạn thu thập gồm IP của người khác, mục đích và thời gian lưu cần được xem riêng.

robots.txt không phải danh sách kiểm soát truy cập. RFC 9309 định nghĩa nó là ưu tiên thu thập tự nguyện. Mở được URL qua proxy không gỡ một lệnh cấm. Điều khoản của đích, quy tắc dữ liệu cá nhân theo GDPR hoặc KVKK, và chính sách sử dụng được chấp nhận của WeProxy cùng áp dụng. Tự động hóa ở lại các bề mặt công khai và được phép.

Danh sách kiểm trên lối ra WeProxy

Ghi IP không proxy bằng My IP.
Lặp lại qua HTTP CONNECT hoặc socks5h. Đừng tiếp tục nếu địa chỉ không đổi.
Đọc nhật ký DNS có thẩm quyền của một tên bạn kiểm soát. Nguồn không phải lối ra nghĩa là phân giải cục bộ.
Dump ICE trong trình duyệt. Nếu srflx là IP nhà, áp chính sách WebRTC và dump lại.
Tìm X-Forwarded-For và Forwarded trên endpoint echo.
Nếu IPv6 đang bật, lặp kiểm tra IPv6 trong hồ sơ proxy.
Khi gặp 429, sửa đồng thời và Retry-After trước. Đừng cố đóng rò rỉ DNS bằng một hồ lớn hơn.
Sau bài thử, xóa thông tin đăng nhập khỏi lịch sử shell và log CI. Mật khẩu trong URL biến bài kiểm rò rỉ thành một sự cố riêng.

Khi rò rỉ DNS đã đóng, ứng viên WebRTC khớp proxy, và yêu cầu tới origin không mang IP máy khách, IP lối ra là mặt định danh duy nhất. Sticky hay xoay, residential hay datacenter là câu hỏi có ích sau đó. Đổi sản phẩm theo thứ tự ngược không đổi những gì bộ phân giải đã ghi.

Xem giá Quay lại tất cả bài viết