購買代理前如何測試 DNS 洩漏
HTTP 請求成功經過代理,不代表目的網域也由代理解析。查詢可能仍從本機、企業或電信商 DNS 送出。對某些代理模式,這是預期行為;對另一些模式,則可能造成隱私、區域或路由偏差。購買容量前,應明確每個主機名稱由誰解析,並驗證實際路徑符合設計。

本指南只使用你擁有或獲准測試的網域、DNS 區域與網頁端點,不依賴可能蒐集識別資訊、且難以解釋結果的第三方「洩漏測試」頁面。
先定義什麼才算洩漏
出現 DNS 查詢不等於洩漏。除非直接設定代理閘道 IP,客戶端通常必須先解析代理閘道。真正要判斷的是:目的主機名稱是否在預期的代理邊界外被解析。
先為兩類查詢寫下預期責任方:
| 查詢 | 預期解析器 |
|---|---|
| 代理閘道主機名稱 | 通常是客戶端側解析器 |
| 透過 HTTP 代理存取目的端 | 取決於請求形式與客戶端行為 |
| 透過 CONNECT 存取目的端 | 通常把主機名稱交給代理解析 |
| SOCKS5 本機 DNS 模式 | 客戶端側解析器 |
| SOCKS5 遠端 DNS 模式 | 代理側解析器 |
不要把閘道查詢誤判為目的端洩漏;同樣地,看到網頁出口正確,也不能證明目的 DNS 留在代理路徑內。
準備受控觀察區域
在自有 DNS 區域下建立專用子網域,並開啟權威 DNS 的最小化紀錄。準備一個回傳合成測試識別碼的 HTTPS 端點。每次請求使用新的隨機標籤,避免快取掩蓋解析路徑。
只記錄必要證據:查詢名稱、類型、權威伺服器接收時間、適度彙總後的解析來源網路、請求識別碼與網頁請求時間。可使用截斷或彙總資訊時,不保存完整客戶端位址,並在測試前設定較短保留期。
測試主機名稱不得包含客戶名稱、帳號、郵件或祕密。不要把代理憑證寫入 DNS 標籤、URL 或紀錄。
建立協定矩陣
透過每種支援模式存取同一受控目的端:
- 直接連線,作為本機 DNS 對照;
- 使用絕對目的 URL 的一般 HTTP 代理;
- 透過 HTTP CONNECT 存取 HTTPS 目的端;
- 若支援,測試 HTTPS 代理傳輸;
- SOCKS5 本機網域解析;
- SOCKS5 遠端網域解析;
- IPv4-only、IPv6-only 與雙棧目的端紀錄;
- 冷解析,以及超過已知快取間隔後的重複請求。
先固定一個代理工作階段與一個區域。理解基本邊界後再擴展至輪換出口,否則解析器變化容易與出口輪換混淆。
觀察客戶端側
在專用測試主機或容器中擷取 DNS 活動,篩選唯一目的標籤與代理閘道名稱。實際方式取決於系統,以及解析器使用傳統 DNS、DNS over TLS 或 DNS over HTTPS。
在乾淨的遠端解析情境中,客戶端可能解析代理閘道,但不應查詢唯一目的標籤。若本機出現目的查詢,先排除應用程式預先擷取、憑證探索、健康檢查或代理函式庫外的直連驗證。
先執行單一請求、無重試、清空應用 DNS 快取的測試,再以正常連線池與重試重複,以找出隱藏路徑。
關聯權威 DNS 與網頁證據
權威紀錄能證明有人查詢唯一名稱,但可見來源通常是遞迴解析服務,而不是代理出口。應使用時間與合成識別碼關聯事件,不要假設解析器 IP 必須等於網頁出口 IP。
重點解釋四種結果:
- 本機出現查詢,網頁請求經代理: 目的 DNS 離開預期的遠端解析邊界。
- 本機無查詢,權威端在代理請求附近收到查詢: 與代理側解析一致。
- 權威端沒有新查詢: 可能是快取、重用連線或請求尚未進入解析。
- 同時出現本機與遠端特徵: 可能存在預先擷取、回退、重試或多層解析器。
每個用例都以新標籤重複,一次觀察不足以支援採購決策。
驗證失敗路徑
健康策略在錯誤時也必須成立。在受控區域建立不存在的名稱、延遲回應與短 TTL 紀錄變更,確認遠端解析失敗時客戶端不會靜默直連重試。
記錄 NXDOMAIN、逾時與位址族失敗由本機解析器、代理閘道或目的流程回傳。檢查重試仍維持相同的代理與 DNS 策略。即使成功率提高,繞過代理的回退仍是安全缺陷。
使用代理容錯移轉演練驗證失敗關閉,並搭配代理延遲歸因測試把 DNS 時間從閘道與目的端延遲中分離。
以業務指標比較服務商
針對每個區域與代理模式報告:
- 符合預期解析責任的請求比例;
- 驗證成功率;
- 可觀察時的 DNS p50 與 p95;
- 連線與總耗時 p50/p95;
- 每個有效結果的重試數;
- IPv4/IPv6 成功率拆分;
- 出口區域與解析區域一致性;
- 每個有效業務結果的成本。
若低 DNS 延遲來自違反策略的本機解析,就不應被評為較優。正確路由與回應驗證優先於原始速度。
採購驗收條件
可要求遠端解析樣本中沒有無法解釋的本機目的查詢、沒有直連回退、各支援區域的解析責任穩定,且有效成功率高於業務門檻。允許的快取與解析器區域差異應預先寫明。
客戶端升級、代理模式變更、DNS 函式庫變更、容器映像更新與服務商閘道遷移後都要重測。解析責任是一項可能在沒有明顯應用錯誤時退化的設定屬性。
檢查清單
- [ ] 閘道與目的端的解析責任分別記錄。
- [ ] DNS 區域與 HTTPS 端點由團隊控制且已獲授權。
- [ ] 每次請求使用新的合成主機名稱標籤。
- [ ] 客戶端觀察涵蓋適用的加密 DNS 路徑。
- [ ] HTTP、CONNECT 與 SOCKS 模式分別測試。
- [ ] SOCKS 本機 DNS 與遠端 DNS 行為未混淆。
- [ ] 冷解析、快取與重用連線分別統計。
- [ ] NXDOMAIN、逾時與紀錄變更失敗仍維持代理路徑。
- [ ] 紀錄中沒有代理憑證或個人資料。
- [ ] 結果依區域、位址族與有效業務結果比較。
常見問題
代理閘道的 DNS 查詢本身算洩漏嗎?
通常不算。客戶端往往必須解析閘道才能連線。測試必須區分閘道名稱與目的名稱。
DNS 解析器 IP 應該和代理出口 IP 相同嗎?
不一定。代理服務可能使用獨立遞迴解析叢集。應透過受控權威紀錄、時間關聯與服務說明驗證責任,而不是只比較兩個 IP。
為什麼第二次請求沒有新的 DNS 查詢?
結果可能已快取,應用也可能重用代理連線。使用新的隨機主機名稱,並分開報告冷、暖情境。
HTTPS 能防止 DNS 洩漏嗎?
不能。HTTPS 保護選定目的端後的應用流量;除非代理模式把主機名稱交給遠端解析,否則 DNS 仍可能在本機發生。
公共 DNS 洩漏測試網站能取代這種方法嗎?
它們適合快速提示,卻通常無法解釋協定模式、快取、責任方與重試。受控區域能關聯證據,也能減少向第三方暴露識別資訊。
代理只能用於合法且已獲授權的業務。遵守隱私要求、目的端規則、速率限制與資料最小化原則,不得利用 DNS 或代理技術繞過存取控制或隱藏違規活動。