高階 IP 與 DNS 洩漏測試：全面檢測網路安全

許多使用者以為購買「住宅代理」就能完全偽裝為普通家庭使用者，但現代風控系統並不單純依賴 IP 歸屬地資料庫（如 IP2Location 或 MaxMind）的分類標籤。雖然購買的住宅代理在資料庫中標記為 ISP/家庭寬頻，但轉發流量的出口閘道器通常執行在 Linux 雲伺服器上，從而產生顯性的跨層矛盾：一是協議棧特徵，出口伺服器在 TCP 握手時輸出標準的 Linux 選項序列（MSS, SACK_PERM, TS, NOP, WS），而非 Windows 或 Apple 的原生選項序；二是鏈路 MTU 差異，家庭 PPPoE 寬頻的 MTU 通常為 1492，行動網路通常為 1400～1430，而機房裸乙太網則是標準的 1500（MSS=1460）。當風控系統檢測到家庭 IP 背後伴隨雲服務商協議棧與乙太網 MTU 時，便會判定其為代理鏈路。

💡 可前往 代理匿名度檢測 檢視你的 TCP 終結位置與鏈路拓撲結構。

IP 地址與物理地理位置之間並不存在硬體層面的固定繫結。定位結果主要取決於各查詢站點所採用的商業 GeoIP 資料庫以及其資料更新週期：一是資料庫源與採集演算法差異，不同廠商（如 MaxMind、IP2Location、DB-IP）分析 BGP 路由宣告、whois 註冊資訊及網路測繪資料的權重與頻率不同，更新週期從數天到數月不等；二是 Anycast（任播）與 CDN 多節點路由，Cloudflare 等服務商在全球數百個資料中心共用相同 IP 段，使用者的請求會被自動排程至最近的邊緣節點；三是廣播 IP 跨國遷移，雲服務商將某國註冊的 IP 排程至另一國機房使用時，若資料庫未同步便會出現偏差。本站透過多探針物理光速 RTT 延遲測距輔助交叉驗證真實物理區域。

IP 欺詐風險分（Fraud Score / Risk Score）是風控系統用於量化評估一個 IP 地址潛在惡意活動或偽裝程度的綜合指標（通常介於 0 到 100 分之間，分值越高風險越大）。其核心評估維度包括：一是歷史黑名單與信譽記錄，檢查該 IP 在近期是否存在惡意爬蟲、撞庫攻擊、垃圾郵件傳送或濫用行為；二是網路型別與 ASN 屬性，資料中心（Hosting/DataCenter）與公開代理節點的初始風險基準通常顯著高於家庭住宅寬頻（Residential）與移動蜂窩網路；三是多端點與協議一致性，評估同一會話中是否存在 IPv4/IPv6 出口分離、DNS 解析出口跨國偏離或 WebRTC 洩露等異常。

💡 建議使用 分流與路由洩漏檢測 排查是否存在多出口分流導致的風險評分異常。

即使開啟了 VPN 或代理，你的真實網路身份仍可能透過旁路協議暴露：一是 DNS 洩漏，當瀏覽器發起域名解析時，若代理客戶端未完整接管系統底層 DNS，作業系統會直接向本地寬頻運營商（ISP）的 DNS 伺服器傳送明文查詢，導致運營商與目標站點獲知你的真實訪問記錄與地理位置；二是 WebRTC 洩漏，WebRTC 是瀏覽器用於實時音影片通訊的內建協議，建立 P2P 連線時會繞過常規 HTTP/SOCKS 代理層，直接透過 UDP 向 STUN 伺服器傳送探測包，從而暴露本機的真實區域網與公網 IP。本站首頁會在毫秒級時間內檢測你的 DNS 出口與 WebRTC 狀態。

💡 如需進一步排查系統級指紋與 WebRTC 本地地址暴露，可使用 瀏覽器指紋檢測。

首頁的網路棧面板並行跑三條相關探針：一條打只有 A 記錄的域名（iptestv4.myipdns.com），一條打只有 AAAA 記錄的域名（iptestv6.myipdns.com），第三條打一個 A 與 AAAA 兩族都有的雙棧域名。前兩條是強制的——那兩個名字各自只解析出一族地址，你的系統想選也沒得選，所以能分別拿到你在 IPv4 與 IPv6 上各自的真實出口。第三條不強制，它反過來觀察你的系統自己選了哪一族，這就是「優先協議」那一欄：結果由作業系統與瀏覽器的地址選擇策略決定（Happy Eyeballs，RFC 8305：雙棧都可達時先試 IPv6，連不上才回落 IPv4），不是我們指定的。三條擺在一起才有意義，因為大量代理與 VPN 客戶端只接管 IPv4：如果你的 IPv4 出口落在代理的 ASN 上、IPv6 出口卻仍是寬頻運營商的，而優先協議顯示 IPv6，那麼你訪問雙棧站點時大部分流量根本沒有走隧道——這是最常見的一類「VPN 開著、身份照樣暴露」，而且它不報任何錯。

⚠ 我們只能告訴你兩族出口是否落在不同的網路裡，不能替你判斷你的代理軟體該怎麼配。反過來也一樣：IPv6 那一欄顯示不可用不等於安全，它可能只是你的網路沒有 IPv6，也可能是代理把 IPv6 整個關掉了——後者恰恰是正確做法。

我們不去讀你的系統設定——瀏覽器里根本讀不到，任何聲稱能讀到你 DNS 配置的網頁都是在猜。真實做法是反過來測：本站自己執行一臺權威 DNS 伺服器，每次檢測臨時生成一個隨機子域名（形如 k3f9x2ab.leakv4.myipdns.com）讓你的瀏覽器去解析。這個名字全世界只出現過這一次，任何快取裡都不會有，所以你的解析鏈路必須一路回源問到我們這臺伺服器上，我們記下是誰來問的，再把這個地址回給頁面。所以「DNS 出口」這一欄顯示的是你的遞迴解析器真正出網的地址，不是你在系統裡填的那個地址：你填 8.8.8.8，來問我們的會是那個叢集裡某臺實際出網的機器，它完全可能在另一個國家；大型公共解析本身就是 anycast 加叢集，同一次檢測裡出現好幾個不同地址也很正常。真正的判據不是「地址對不對得上」，而是：這個出口落在你自己的寬頻運營商網路裡，而你的 IP 出口在代理上——那才是 DNS 沒跟著走隧道。

⚠ 這套方法只看得到我們自己這臺權威伺服器被誰問過；你查詢過的其它域名我們看不到，也無從看到。它還有一個已知盲區：如果你的代理把 DNS 也一併接管了，我們看到的就是代理商的解析器——那說明沒有洩漏給運營商，但你的解析記錄對代理商是可見的，那是另一個問題，本站測不出來。

透過 WebRTC 向多臺 STUN 伺服器各發一次探測，收集回來的 srflx 候選——也就是你的地址經 NAT 對映之後對方實際看到的公網 IP 與埠。判據只有一條：把候選按對映出的公網 IP 分組，同一個 IP 下出現了兩個以上不同埠，判為對稱型 NAT（每換一個目標就換一個對映埠）；否則判為錐型 NAT（同一個內網埠對外始終對映到同一個公網埠）。先分組再比埠這一步是刻意加的：在分流代理環境下，不同 STUN 伺服器可能走不同出口，埠自然對不上，但那是路徑不同造成的、不是 NAT 造成的，不分組就會把這種情況一律誤判成對稱型。顯示「未知」有兩種成因：一是 4 秒超時內一個 srflx 候選都沒收到（瀏覽器禁用了 WebRTC、被擴充套件攔截、或 UDP 出不去）；二是只收到一個候選、且它的公網 IP 與你訪問本站的入口 IP 對不上，此時無法分辨是瀏覽器去重還是流量分流，我們寧可顯示未知。

⚠ 誠實說明：我們只區分錐型與對稱型兩類，不區分完全錐形／受限錐形／埠受限錐形。RFC 3489 那套四分類需要主動控制源埠與目標地址的組合去反覆探測，瀏覽器裡的 WebRTC 不提供這種控制權；網頁工具報出四類中的某一類時，多半隻是把這兩類結果重新貼了個標籤。

首頁檢測由幾組請求組成：連線本站幾個子網域，分別在 IPv4、IPv6 和不同 HTTP 版本上收集通訊協定疊特徵；詢問幾家第三方 IP 查詢服務和 WebRTC，確認不同目標看到的出口是否一致；解析隨機子網域，確認 DNS 是由誰替你解析的；向本站其他地區節點發送探測，從幾個地點共同核驗；向幾個常見網站測量延遲。

⚠ 代價是首頁會連線至不少網域，廣告阻擋器或嚴格的隱私擴充功能有時會攔截其中一部分。被攔截的那一欄顯示灰點、停在未知狀態，不會拿其他結果去補。