VPN 連線安全不能只看用戶端顯示「已連線」。加密通道可以降低本地網路直接讀取傳輸內容的風險，但服務商仍可能處理連線中繼資料；裝置上的 DNS、瀏覽器 WebRTC、分流規則和斷線處理，也可能讓部分請求走到預期之外的路徑。檢查時應把「服務商如何處理資料」和「自己的流量是否確實經過 VPN」分開看，逐項確認，才不會把單一測試結果當成完整的隱私保證。
本文整理無日誌政策的判讀方式，以及 DNS、WebRTC、公共 Wi-Fi 和 Kill Switch 的檢查重點。測試結果會受作業系統、瀏覽器、用戶端模式和網路環境影響；若發現不一致，先記下當時使用的裝置、瀏覽器、線路與設定，再逐一排查。VPN 不能讓使用者免於釣魚、惡意軟體或帳號遭盜等風險，也不代表任何服務都能保證絕對匿名。
先釐清 VPN 能保護什麼
VPN 通常會在裝置與 VPN 伺服器之間建立加密通道。使用公共 Wi-Fi 時，這能減少同一網路上的其他使用者或網路管理者直接讀取通道內流量的機會；網站仍可能透過帳號登入、Cookie、瀏覽器指紋或使用者自行提供的資料辨識你。若連線通道之外的 DNS 查詢、應用程式流量或裝置請求沒有被妥善接管，保護範圍也可能與用戶端畫面顯示不同。
VPN 也會把部分信任從本地網路轉移到 VPN 服務商。服務商可能處理連線時間、流量用量、連線來源、使用的伺服器或故障診斷資訊；具體能看到和保存哪些資料，取決於服務架構、加密方式、記錄設定與適用政策。HTTPS 仍是重要的另一層保護：它通常會加密裝置與網站之間的內容，但不代表網站看不到你主動提交的資料，也不會自動阻止追蹤器。
無日誌政策要看範圍與證據
「無日誌」不是所有服務都採用相同定義的技術術語。閱讀政策時，先確認服務商所說的不記錄具體涵蓋哪些資料，例如瀏覽活動、DNS 請求、連線來源 IP、連線時間、使用的伺服器、工作階段識別資訊和流量統計。也要分辨「不記錄瀏覽內容」與「不保存任何連線資料」的差異；服務商可能不記錄網站瀏覽歷程，但仍保留營運、帳務、客服或安全防護所需的部分資訊。
接著查看資料保存時間、刪除方式、例外情況，以及政策適用的服務範圍。某些說明會提到為維持服務所需的暫存處理，這不必然等於長期保存；但若用詞含糊、沒有說明保存期限，或把關鍵細節放在另一份文件，就應保留判斷並進一步查證。隱私政策、服務條款與技術說明可能分別描述不同事項，建議一併閱讀並留意更新日期。
第三方稽覈或司法文件可作為參考，但要看清楚稽覈對象、範圍、執行時間和結論。一次稽覈只能說明特定範圍在特定時間的檢視結果，不能直接推論所有產品、所有伺服器或未來的設定都相同。若服務商提供透明度報告，也可確認報告說明瞭哪些請求、如何處理，以及是否有可核對的範圍。行銷頁面上的簡短標語，不應取代完整政策與可驗證資料。
- ✅ 確認「無日誌」涵蓋哪些資料類型，尤其是 DNS、來源 IP 與連線時間。
- ✅ 查閱資料保存期限、刪除規則、例外條件及政策更新資訊。
- ✅ 評估稽覈或透明度報告的範圍與日期，不把有限結論擴大解讀。
- ❌ 不要把「不記錄瀏覽內容」直接理解為「服務商完全不處理任何資料」。
DNS 與 WebRTC 外洩怎麼檢查
DNS 負責將網域名稱解析為 IP 位址。連上 VPN 後，如果網頁流量經由 VPN 傳送，但 DNS 查詢仍交給本地網路或其他未預期的解析器處理，就可能出現 DNS 路徑不一致。這不等於網站內容必然被看見，但可能讓不同網路參與 DNS 解析，並造成地區判斷或連線問題。DNS over HTTPS（DoH）或 DNS over TLS（DoT）能加密裝置與解析器之間的查詢，但「查詢有加密」不等於「查詢一定經過 VPN」，也不等於解析器不會處理查詢資料。
檢查時先記錄 VPN 斷開時的公開 IP 與 DNS 測試結果，再連上 VPN，以相同瀏覽器重新測試。查看測試頁所列的解析器或網路提供者是否符合預期；不要只看一個「安全」或「無外洩」標籤，應確認頁面實際顯示的內容。若 DNS 結果仍指向本地網路，可檢查用戶端是否啟用 DNS 接管、目前採用全域或規則模式，以及瀏覽器是否另行設定 DoH。修改一項設定後重新測試，避免同時改動多個選項而無法判斷原因。
WebRTC 是瀏覽器支援即時通訊的技術，可能在建立連線時取得網路位址資訊。不同瀏覽器、版本與網路設定呈現的資料不一；有些情況只會顯示內部位址或經過遮蔽的資訊，不應把任何內部位址都直接當成公開 IP 外洩。可在 VPN 連線期間使用可信任的 WebRTC 測試頁，檢查是否出現 VPN 之外的公開 IP；再對照斷開 VPN 時的結果。若測試頁沒有報告外洩，也只代表當下瀏覽器與設定下未觀察到，不是所有應用程式都已完成檢查。
| 檢查項目 | 操作方式 | 需要留意 |
|---|---|---|
| 公開 IP | 連線前後各查一次，確認連線後顯示的出口符合預期。 | 分流模式可能只接管部分流量；測試瀏覽器也須納入代理路徑。 |
| DNS | 在相同瀏覽器與網路環境下比對連線前後的解析器資訊。 | DoH／DoT 會影響查詢方式，不能只憑解析器所在地推斷全部路徑。 |
| WebRTC | 連線 VPN 後檢查測試頁列出的位址，再與斷線結果比較。 | 區分內部位址與公開 IP，並確認測試頁與瀏覽器設定可信。 |
若結果不符合預期，可依序檢查用戶端 DNS 設定、瀏覽器 DoH、分流規則與作業系統網路設定。部分瀏覽器提供限制或停用 WebRTC 的選項，調整前先確認視訊會議等功能是否依賴它。不同系統的選項名稱和效果可能不同，應參考瀏覽器與用戶端的官方說明，調整後再用相同測試流程驗證。
公共 Wi-Fi 與 Kill Switch 設定
在咖啡店、旅館或機場使用公共 Wi-Fi 時，先確認連線到的是正確網路，避免選到名稱相似的熱點。完成必要的入口頁面驗證後，再啟用 VPN，並確認用戶端狀態已連線。即使如此，仍應優先使用 HTTPS 網站、避免在不可信裝置輸入敏感資料，並關閉不需要的檔案分享或自動加入網路功能。VPN 無法阻止假登入頁、釣魚連結或已感染惡意軟體的裝置竊取資料。
Kill Switch（網路鎖定或斷線保護）通常會在 VPN 通道中斷時，阻擋部分或全部網路流量，避免流量意外改走一般網路。不同用戶端與作業系統的實作可能不同：有的只在應用程式執行期間生效，有的提供系統層級的常駐保護；也可能允許區域網路或特定應用程式例外。因此，不能只依選項名稱判斷涵蓋範圍，請查看用戶端說明並確認目前模式。
可在自己有權管理的裝置上做基本驗證：先啟用 Kill Switch 並連上 VPN，再透過用戶端提供的安全測試方式確認斷線時網路行為是否符合說明。不要在重要工作或正在傳輸資料時刻意中斷連線。完成測試後，重新連線 VPN，再檢查公開 IP 和 DNS 狀態；若裝置重新啟動、切換 Wi-Fi 或從行動網路轉回 Wi-Fi，也應確認用戶端是否自動恢復保護。
- ✅ 開啟用戶端的自動連線或不可信網路保護選項，並確認適用的網路範圍。
- ✅ 確認 Kill Switch 在應用程式退出、裝置休眠或網路切換時如何運作。
- ✅ 使用 HTTPS、更新作業系統與瀏覽器，並避免在陌生入口頁重複輸入帳密。
- ❌ 不要把 Kill Switch 當成防毒、帳號保護或阻止釣魚的替代方案。
建立可重複的檢查流程
一次測試只能反映當時的裝置、網路與設定。建議在初次設定、更新用戶端、切換網路或修改分流規則後，重做同一套檢查：記錄連線前後的出口 IP、DNS 測試結果與 WebRTC 測試結果；確認 Kill Switch 的狀態；再檢查常用瀏覽器和應用程式是否採用預期的路徑。若使用多個用戶端，避免同時開啟，以免系統代理、虛擬網路介面或 DNS 設定互相影響。
檢查結果若有異常，先關閉不必要的代理擴充功能或第二個用戶端，再依序測試 DNS 接管、分流模式和瀏覽器設定。每次只改一項，記下變更前後結果；若問題只在特定應用程式出現，還要確認它是否使用獨立的網路堆疊或自行指定 DNS。不要把訂閱連結、帳號密碼或包含個人資訊的測試截圖公開貼出；向服務商詢問時，提供必要的錯誤訊息與設定概況即可。
首次設定或匯入相容用戶端時，可參考快速上手中的操作說明；若政策用詞或連線功能不清楚，則應查閱服務商的正式文件。對安全要求較高的使用情境，還應搭配裝置更新、密碼管理、多重要素驗證和定期檢視應用程式權限。不同防護措施各自處理不同風險，不能因為某一項檢查通過就省略其他基本安全習慣。