VPN 連線後，網站通常只會看到 VPN 出口的 IP 位址，但這不代表裝置上的所有網絡資訊都已經完全隱藏。DNS 查詢、IPv6、瀏覽器 WebRTC、作業系統的分流規則，以及應用程式自行建立的連線，都可能讓部分請求繞過 VPN 通道。這類情況一般稱為 DNS 洩漏或代理洩漏，未必代表 VPN 加密已經失效，卻可能暴露你正在查詢的網域、原本的網絡供應商，甚至大致的連線位置。
因此，判斷 VPN 是否安全，不能只看連線圖示是否顯示「已連線」，也不能只用一次 IP 查詢作結論。較完整的做法，是分別檢查出口 IP、DNS 解析來源、IPv6、WebRTC，以及切換網絡後的故障保護行為。本文會先解釋各類洩漏的成因，再整理 Windows、macOS、Android、iOS 與 Linux 使用者可以執行的檢查步驟，最後說明無日誌政策與日常帳戶防護應該如何理解。
VPN 安全性取決於哪些環節
VPN 的基本作用，是在裝置與 VPN 伺服器之間建立加密通道，再由伺服器代為連接外部網絡。這能降低公共 Wi-Fi 上其他使用者直接觀察傳輸內容的風險，也能讓網站看到 VPN 出口而非本地網絡出口。不過，VPN 並不會自動替所有應用程式改寫網絡設定。只要某個請求沒有進入 VPN 通道，相關資訊就可能按照原本的路徑傳送。
常見的連線協定各有不同設計。WireGuard 著重簡潔的現代密碼學與較低的設定複雜度；Shadowsocks 是加密代理，常由相容用戶端處理；VMess、Trojan 與 Hysteria2 則需要相應核心及完整參數才能正常建立連線。協定本身不是防止 DNS 洩漏的唯一因素，真正重要的是用戶端是否正確接管 DNS、是否啟用全域或規則代理，以及系統在 VPN 中斷時會否繼續放行直連流量。
另外，「全域模式」與「規則模式」也會影響檢查結果。全域模式通常會把更多應用程式流量送入代理，較容易判斷是否存在繞行；規則模式則可能讓本地網站、區域服務或未列入規則的程式維持直連。直連本身不一定是錯誤，但必須知道哪些流量被排除，以及 DNS 請求是否也採用相同策略。
| 檢查項目 | 可能暴露的資訊 | 常見原因 | 改善方向 |
|---|---|---|---|
| 出口 IP | 原本網絡出口或地理位置 | VPN 未接管全部流量、連線中斷後自動直連 | 確認隧道狀態、啟用阻斷失效流量功能 |
| DNS | 查詢過的網域名稱與 DNS 服務來源 | 系統保留原有 DNS、IPv6 DNS 未被處理 | 檢查 DNS 設定與用戶端的 DNS 保護選項 |
| IPv6 | 未經 VPN 處理的 IPv6 出口 | VPN 只支援 IPv4 或未攔截 IPv6 | 使用支援 IPv6 的配置，或按系統及用戶端說明停用 IPv6 |
| WebRTC | 瀏覽器可取得的候選網絡位址 | 瀏覽器允許即時通訊功能暴露本地介面資訊 | 調整瀏覽器權限，並以瀏覽器測試確認結果 |
| 應用程式分流 | 特定程式的真實連線來源 | 規則代理未涵蓋該程式或程式使用獨立 DNS | 檢查分流規則、系統代理與應用程式網絡選項 |
VPN 安全不是單一開關，而是「加密通道、DNS 路徑、IPv6、瀏覽器權限與失效保護」共同形成的結果。任何一項沒有納入檢查，都可能留下盲點。
DNS 洩漏應該怎樣檢查
檢查前先關閉不必要的代理擴充功能，並記下目前是否連接 VPN。接著在 VPN 關閉狀態與連線狀態各做一次 DNS 檢查，觀察 DNS 服務商、所在國家或地區，以及測試結果是否出現本地網絡供應商。一次測試只能反映當下的解析路徑，換用另一個 Wi-Fi、手機流動網絡或重新連線後，最好再複查一次。
- 先完全退出 VPN 用戶端，等待系統網絡恢復，再開啟瀏覽器中的 IP 與 DNS 檢查頁面，記錄未連線時的結果。
- 重新開啟 VPN，確認已選定一條可用線路，等待連線狀態穩定後清除瀏覽器 DNS 快取或重新開啟測試頁面。
- 比較連線前後的出口 IP。連線後應顯示 VPN 伺服器的出口，而不是原本寬頻或流動網絡的出口。
- 檢查 DNS 伺服器清單。如果結果仍出現原本網絡供應商，或顯示未預期的本地 DNS，便要進一步檢查用戶端和作業系統設定。
- 關閉 VPN 後再重新連線，重複一次測試，確認不是瀏覽器快取、私人 DNS 或企業網絡代理造成的暫時結果。
- 在另一個瀏覽器或私人瀏覽視窗中覆核。若只有一個瀏覽器出現異常，問題可能來自 DoH、擴充功能或瀏覽器專屬代理設定。
- ✅ 先分別記錄 VPN 關閉與開啟時的出口 IP 和 DNS 服務來源。
- ✅ 重新連線、切換網絡後再次檢查，不要只相信一次測試。
- ✅ 確認作業系統的 DNS、私人 DNS、DoH 與 VPN 用戶端設定沒有互相衝突。
- ❌ 不要把顯示「DNS 安全」的測試結果直接等同於所有應用程式都走 VPN。
- ❌ 不要把完整訂閱連結、帳戶資料或裝置識別資訊提交給陌生的線上診斷工具。
如果測試頁顯示多個 DNS 服務商，不一定每一個都是洩漏。部分 VPN 服務會採用多個遞迴 DNS、備援解析器或不同地區的解析入口。判斷重點是：結果是否出現本地網絡供應商、是否與 VPN 連線前完全相同，以及用戶端文件是否說明這些 DNS 屬於服務本身。若無法確認，應保留測試時間、網絡環境和用戶端設定，再向服務支援提交必要資訊，而不是公開完整結果與帳戶憑證。
WebRTC 與 IPv6為何要另外檢查
WebRTC 是瀏覽器用於語音、視像及即時資料傳輸的技術。為了建立連線，瀏覽器可能收集本地網絡介面、區域網絡位址或候選連線資訊。現代瀏覽器通常會透過 mDNS 或其他機制降低本地位址直接暴露的機會，但實際行為取決於瀏覽器版本、權限、網站腳本及作業系統，因此不能單靠 VPN 連線狀態推斷 WebRTC 沒有風險。
檢查時，可使用瀏覽器的 WebRTC 洩漏測試頁，並在 VPN 開啟及關閉時比較候選位址。若頁面顯示原本網絡的公開 IPv4 或 IPv6 出口，應先檢查瀏覽器是否安裝了代理擴充功能，再查看 VPN 用戶端有沒有「封鎖 WebRTC」或相近選項。若沒有相關功能，可在瀏覽器隱私設定中限制 WebRTC 的本地介面暴露；但調整後可能影響瀏覽器通話、會議或點對點功能，使用前應確認自己的需求。
IPv6 則是另一條容易被忽略的路徑。有些 VPN 配置只處理 IPv4，裝置仍可能透過本地 IPv6 網絡直接連往網站，造成出口 IP 不一致。當測試頁同時顯示 VPN 的 IPv4 與本地 IPv6，或 VPN 開啟前後 IPv6 沒有任何變化，就要查看服務是否支援 IPv6。若服務沒有清楚說明，暫時停用作業系統的 IPv6 可能降低洩漏機會，但這不是所有網絡環境的最佳長期方案；企業、校園或部分家用網絡可能依賴 IPv6，應先記錄原設定，並按照支援文件處理。
瀏覽器擴充功能通常隻影響瀏覽器內的 HTTP 或 HTTPS 請求，未必會接管 DNS、其他應用程式或 IPv6。即使 WebRTC 測試看似正常，也不能因此推論網上銀行程式、郵件軟件或遊戲流量同樣經過 VPN。
用戶端與系統設定如何降低洩漏
Windows 和 macOS 使用者應先確認 VPN 用戶端是否啟用「VPN 中斷時封鎖網絡」或 kill switch 類似功能。這項功能的目的不是讓連線更快，而是在隧道中斷、切換線路或睡眠喚醒期間暫停外部流量，避免系統短暫恢復直連。啟用後，本地網絡印表機、區域網站或公司內部服務可能暫時無法使用，這屬於設計取捨，不能在未理解規則的情況下直接判定功能失效。
Android 的 VPN 設定通常可看到「一律使用 VPN」或「封鎖未使用 VPN 的連線」等系統選項；不同品牌的名稱可能不同。這些選項有助於限制未經 VPN 的應用程式流量，但分流、電池最佳化和私人 DNS 仍可能影響結果。iOS 對系統網絡管理較封閉，應優先使用官方客戶端提供的連線及 DNS 選項，不要同時開啟多個 VPN、代理或內容過濾工具。Linux 使用者則要特別檢查 NetworkManager、systemd-resolved、桌面代理與 VPN 用戶端是否各自管理 DNS，避免多個服務互相覆寫。
如果使用 Clash Verge、sing-box 或 Shadowrocket 等相容客戶端匯入訂閱，請先確認它們支援訂閱中的協定及 DNS 模式。系統代理、透明代理、TUN 模式與規則模式的接管範圍不同：系統代理可能隻影響遵守代理設定的程式；TUN 模式通常能接管更多系統流量，但仍須依客戶端權限、路由和 DNS 設定判斷。Shadowsocks、VMess、Trojan、Hysteria2 與 WireGuard 的欄位與運作方式不同，不能把一個協定的參數手動套用到另一個協定。
| 使用情境 | 建議檢查 | 常見誤區 |
|---|---|---|
| Windows / macOS | kill switch、DNS、IPv6、系統代理 | 只看桌面圖示，沒有測試中斷後是否直連 |
| Android | 一律使用 VPN、私人 DNS、電池限制 | 省電設定讓用戶端在背景中斷 |
| iOS | 官方客戶端、VPN 設定檔、其他過濾工具 | 同時啟用多個網絡工具造成路由衝突 |
| Linux | resolved、NetworkManager、TUN 或系統代理 | 以為終端機設定的 DNS 會自動套用全部程式 |
只保留一個主要 VPN 接管者，明確選擇 DNS 處理方式，並測試斷線時是否阻止直連；多個工具同時管理同一條路由，往往比單一設定更難排錯。
無日誌政策應該怎樣理解
「無日誌」不是一個所有服務都採用相同定義的技術標準。它可能表示不保存瀏覽內容，也可能只是不保存完整的目的地記錄；某些服務仍需要保留帳戶狀態、付款結果、流量用量、故障診斷資訊或濫用處理資料。閱讀政策時，應分開看連線日誌、DNS 查詢、IP 位址、頻寬用量、裝置識別、付款資料與支援工單，而不是隻尋找一個醒目的口號。
可信的政策通常會說明收集哪些資料、保存多久、哪些資料由第三方處理，以及在法律要求下如何回應。若文字只說「保護私隱」卻沒有列出資料類別，便很難據此評估。還要注意 VPN 只改變傳輸路徑，不能阻止網站透過登入帳戶、Cookie、瀏覽器指紋或裝置設定辨認你。使用 VPN 後登入原有帳戶，服務端仍然可以依帳戶本身知道該次活動屬於誰。
選擇服務時，可把政策透明度與技術功能放在一起考量。NrVPN 支援 Windows、macOS、iOS、Android 及 Linux，並可透過官方客戶端或相容用戶端處理連線；實際使用時，仍應依所用裝置和客戶端的 DNS、分流及失效保護設定自行核驗。註冊不需要電子郵件地址，但這不代表訂閱連結可以任意分享，也不代表帳戶密碼不需要妥善保管。
- ✅ 閱讀服務的資料收集、保存期限與第三方處理說明。
- ✅ 將帳戶密碼、訂閱連結與付款資訊分開保管，避免放在公開筆記或聊天羣組。
- ✅ 對網上銀行、工作帳戶及重要電郵啟用多因素驗證。
- ✅ 在公共 Wi-Fi 使用 VPN 時，仍確認網站採用 HTTPS，並核對網域名稱。
- ❌ 不要因為 VPN 已連線，就在陌生裝置上輸入高敏感度帳戶資料。
- ❌ 不要把「無日誌」理解成服務、網站和付款平台都完全不知道任何活動。
公共 Wi-Fi 與帳戶登入的實用做法
在咖啡店、機場、酒店或共享辦公室使用公共 Wi-Fi 時，先確認網絡名稱與登入頁面，避免連接名稱相近的冒充熱點。連線後再開啟 VPN，並觀察用戶端是否真正建立隧道。若 VPN 尚未連線，不要急著開啟網上銀行、管理後台或處理敏感文件；若 kill switch 已啟用，連線切換期間無法上網是預期現象，不應為了恢復網絡而隨意關閉保護。
網上銀行及重要帳戶的安全，仍然依賴正確網址、HTTPS、裝置更新、密碼管理和多因素驗證。VPN 可以降低本地網絡觀察傳輸的風險，但不能替你辨認釣魚網站，也不能阻止已登入瀏覽器中的 Cookie 被濫用。登入前應手動確認網域，避免透過陌生短網址進入；完成操作後，在共用裝置上登出並清除帳戶狀態。
如果 DNS 檢查顯示異常，先不要急於更換所有設定。記錄裝置、作業系統、VPN 客戶端、線路、網絡類型及測試結果，然後逐項停用瀏覽器擴充功能、私人 DNS、其他代理和自訂路由。每次只改一項，重新連線後再測試，才知道哪個設定真正造成差異。需要匯入訂閱時，可參考使用教程，並以客戶端支援的格式為準。
VPN 是網絡私隱的其中一層，不是帳戶安全的全部。先確認 DNS、IPv6 和 WebRTC 沒有暴露預期外的資訊，再配合 HTTPS、多因素驗證與安全的裝置習慣，防護才比較完整。
DNS 洩漏常見問題
DNS 測試顯示多個伺服器，是否一定代表洩漏？
不一定。VPN 服務可能使用多個 DNS 解析器或備援入口。重點是查看這些伺服器是否屬於本地網絡供應商、是否在 VPN 開啟前後維持完全相同，以及服務文件有沒有說明其來源。若無法判斷，應向官方支援核實。
VPN 已顯示連線，為何網站仍看到原本位置？
可能是瀏覽器快取、規則分流、IPv6 未被接管、WebRTC 候選位址，或網站根據登入帳戶與 Cookie 判斷位置。請分別檢查出口 IP、DNS、IPv6 和 WebRTC，不要只重開 VPN 一次便下結論。
應否自行更改系統 DNS？
如果 VPN 用戶端已提供 DNS 保護，優先使用其設定，避免系統 DNS、DoH 和用戶端互相覆寫。自行更改 DNS 只能改變解析服務，不能取代 VPN 加密，也不會自動處理 IPv6、WebRTC 或應用程式分流。
使用相容用戶端匯入訂閱，安全性會比較低嗎？
安全性取決於客戶端來源、權限、核心支援與實際設定，不是單純由「官方」或「相容」四個字決定。請使用可信來源取得軟件，確認協定與訂閱格式相容，並檢查 DNS、TUN、分流及斷線阻擋功能是否符合需要。