開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
甚麼是 IPv6 洩漏？VPN 已連線仍可能繞過隧道的原因
Ryan Foster
2026年10月5日· 7 分鐘讀完
IPv6 洩漏是指 IPv6 流量走出你原本期望的 VPN 保護路徑，即使其他流量已使用隧道。IPv4 及 IPv6 必須分開測試：IPv4 出口改變不代表 IPv6 已受保護，沒有 IPv6 結果也可能只是該網絡沒有可用的 IPv6。
關鍵要點：
- 雙棧裝置的 IPv4 與 IPv6 可以有不同路由結果。
- 各個可用地址族都要比較連線前後的觀察。
- 基線本來無法使用 IPv6 時，沒有結果不足以下結論。
- 優先採用有文件支持的覆蓋或封鎖；臨時停用只是可還原的診斷。
IPv6 洩漏為何可以與正常 VPN 連線並存？
雙棧裝置能以 IPv4 或 IPv6 通訊。VPN 可能只為一種地址族加入路由及政策，另一種卻未套用預期保護。應用程式便可能從未覆蓋的介面連到目的地，而 VPN 仍顯示已連線。RFC 7359 討論雙棧隧道流量洩漏與緩解考慮；IESG 附註亦指出，未覆蓋介面及分流是更廣泛的政策問題。［1］
IPv6 並非因此天生不安全。真正問題是預期覆蓋範圍與有效路徑不相符。獲正確支援的隧道可以承載 IPv6，文件訂明的政策也可以改為封鎖。實際產品採用哪種行為，需要按客戶端、系統及模式查證。
這是其中一種旁路的原理圖，並非供應商測量結果。兩條路徑來自同一裝置，但地址族仍須獨立核對。地址概念可另閱 IPv4 與 IPv6 比較。
2025 年的《Smoothing Rough Edges of IPv6 in VPNs》研究 VPN 如何處理 IPv6。研究發現只屬於列明的樣本與方法，不能套用到所有現有供應商或客戶端版本，亦不能當作今天整個市場的失敗比例。［2］
IPv6 洩漏測試需要哪些前提？
選用可信網絡，以及你有權設定的裝置。先記錄系統與客戶端版本、網絡、運作中的網絡介面、預期隧道模式，還有連線前 IPv6 能否實際使用。有些網絡的 IPv6 只間歇可用，其他網絡則只有 IPv4，沒有可用 IPv6 路由。
比較未受保護的基線前，關閉敏感工作。公司管理的電腦應先向管理員查詢路由及地址族覆蓋，不自行更改系統網絡。臨時設定亦可能影響內部資源，因此須保留原值與恢復本機存取的方法。
診斷工具應能指出請求使用哪個地址族。一般 IP 網頁可能只選取優先連線並顯示一個地址，不能假設它已測試兩種。無法使用的地址族記作「不可用」，不要記作安全；分享筆記時不要公開完整地址。
如何分開比較 IPv4 與 IPv6？
- 確認基線的地址族。 斷開 VPN 後，記錄目前公網出口，再用診斷內針對各地址族的請求，分別確認 IPv4 與 IPv6 是否可用。註明時間、網絡及不可用項，不能從單一優先結果推論兩種都已覆蓋。
- 建立已連線的參考。 以 AethoVPN 作比較時，選擇目前可用位置並連線，記下網頁請求報告的出口，再獨立執行兩個地址族的檢查。出口改變不構成 IPv6 支援或防洩漏承諾。Mac、iPhone 及 iPad 的設定需要 Pro 或 Premium。［3］你可開始 3 天 Pro 試用，每人一次，在付款前完成對照。［3］
- 重做兩種專用請求。 裝置、工具與網絡保持相同，分開記錄連線後 IPv4、IPv6 的結果及連線錯誤。每個可用地址族與自己的基線比較，不將 IPv6 地址拿來與 IPv4 地址直接比較。
- 查明仍屬原網絡的 IPv6。 若 IPv4 已改變，但 IPv6 看似仍與原網絡相關，檢查有效 IPv6 路由與文件中的隧道政策。獲授權的路由檢視或封包擷取能加強診斷；地址定位本身不能證明裝置端封包走過的路徑。
- 採用文件支持的修正。 向供應商或管理員核實客戶端支援、模式、路由及可用封鎖行為。一次只改一個有文件依據的設定，保留原值。沒有受支援的修正便停止，不從另一個 IPv4 結果臆測 IPv6 覆蓋。
- 重測並按需要還原。 改動後再測兩個地址族及所需應用程式。若功能失常，恢復已記錄設定。一般重新連線或轉換網絡後也要重測，保留不確定結果，不宣稱整部裝置已受保護。
整體連線診斷可使用 VPN 測試流程。若隧道在依賴 IPv6 的網絡根本無法建立，參考 IPv6-only 網絡連線排解；建連失敗與已連線後的旁路是兩個任務。
每種觀察實際證明甚麼？
一般比較最有用的起點，是基線 IPv6 可用，然後在連線後重做同一地址族請求。結論仍只涵蓋所觀察的請求與設定，不能證明所有應用程式、重新連線狀態或未來網絡均有相同行為。
| 基線及連線後結果 | 解讀 | 後續處理 |
|---|---|---|
| 前後 IPv6 都不可用 | 缺少可測試覆蓋的基線 | 在獲授權且 IPv6 可用的網絡重測 |
| 基線可用，連線後不可用 | 可能是封鎖、路徑故障或工具問題 | 先查政策及錯誤證據 |
| 基線可用，連線後地址改變 | 與該請求出口改變相容 | 確認預期路由及所需應用行為 |
| IPv4 改變，原網絡 IPv6 仍在 | 疑似未覆蓋路徑或刻意例外 | 比較文件政策與有效 IPv6 路由 |
| 轉換網絡後結果改變 | 網絡能力或路由背景不同 | 重做完整基線與連線後比較 |
IPv6 私隱地址可以在同一網絡隨時間改變，所以地址文字不同並非隧道證據。地點標籤也可能出錯，或只反映基建而非接入路徑。需要結合地址族結果、目前文件，及有必要且獲授權的路由證據。
DNS 與瀏覽器媒體流量應另作判斷。解析器觀察不符預期時，用 DNS 路徑檢查；瀏覽器顯示公網候選時，用 WebRTC 分類。某處出現 IPv6 地址，不代表每項私隱症狀都由 IPv6 洩漏引起。
VPN IPv6 支援：停用前應優先核對甚麼？
先檢查受支援的客戶端設定。版本及平台是否支援所需地址族，所選模式是否符合預期政策，另一個活動介面或 VPN 是否正在改變路由？更新與設定修正應跟隨目前文件，並先記錄原狀。
如果設計是封鎖 IPv6 而非承載它，應核對封鎖是否有效，以及應用程式是否仍可用。這可能滿足「不准直接 IPv6 流量」的明確要求，但與經隧道保留 IPv6 連線不同。要問清楚供應商實際支援哪一種，不能混為一談。
不要任意加入預設路由、移除網絡介面或停用防火牆。某個測試看似成功，可能同時破壞其他目的地或建立新的未保護路徑。若工作需要可靠 IPv6，而受支援設定無法達成，應在購買前記為失敗或未確定。
只有在你控制的裝置及容許改動的網絡，才考慮臨時停用 IPv6 作診斷。保留原設定、關閉重要工作、限制測試，完成後還原。依賴 IPv6 的服務與 IPv6-only 網絡可能中斷，不能把它當成沒有說明後果的永久方案。RFC 7359 討論的運作緩解措施也不能取代正確客戶端政策。［1］
何時應停止並尋求支援？
基線不可用、改動會影響受管網絡，或你無法說明如何還原原設定時，應停止。提供系統及客戶端版本、網絡能力、連線模式、分開的地址族觀察，以及已測試改動。完整地址只在必要時經獲授權的私人渠道提供。
有文件支持的修正完成後，重跑原本對照，不改用看似較令人放心的測試。除地址族外，也要驗證一般瀏覽及所需內部資源。連線損壞而沒有顯示地址，並不自動代表私隱測試成功。
把結果加入 付款前試用驗收表。一般覆蓋概念及限制見 VPN 基礎完整指南。描述結果時註明觀察設定與日期。
總結
- 先確認基線 IPv6 可用，再作覆蓋判斷。
- 在相同條件下，分開比較 IPv4 與 IPv6。
- 區分承載、封鎖及未能量度 IPv6。
- 優先依文件修正，還原臨時診斷改動。
常見問題
IPv6 天生比 IPv4 缺乏私隱嗎？
不是。關鍵在於預期隧道政策是否覆蓋可用路徑，而非哪個地址族天生安全。
新 IPv4 地址證明 IPv6 已受保護嗎？
不能。這只描述 IPv4 觀察；IPv6 路由可以不同，須有獨立基線與連線後檢查。
沒有 IPv6 地址便算通過嗎？
不能單憑這點判定。沒有可用基線時結論不明；有基線時，要辨別是受支援封鎖還是故障。
IPv6 地址改變證明用了 VPN 嗎？
不能。同一網絡的私隱地址亦可改變，應看預期政策和路由證據，而非文字差異。
應該永久停用 IPv6 嗎？
不能當作通用修正。它可能破壞依賴 IPv6 的存取；臨時診斷須有權限、原值記錄與可靠復原方法。
IPv6-only 連線失敗等於 IPv6 洩漏嗎？
未必。無法建立隧道與隧道連上後流量旁路不同，應採用不同診斷流程。
應向支援提供哪些資料？
提供版本、網絡能力、隧道模式、各地址族觀察與改動紀錄。地址及帳戶資料保持私密，只提供必要部分。
免責聲明： 本流程只用於獲授權裝置及網絡。單一請求不能確定所有應用程式或未來網絡的覆蓋行為。
來源
- RFC 7359 — Layer 3 Virtual Private Network Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
- USC/ISI — Smoothing Rough Edges of IPv6 in VPNs
- AethoVPN — Official website
Sources checked 2026年10月5日。
