VPN 真的安全嗎？答案不能只用「安全」或「不安全」二分法回答。VPN 通常可以把裝置與 VPN 伺服器之間的流量加密，並讓目標網站看到 VPN 出口的 IP 位址，但它不會自動消除所有網路識別資訊，也不能保證瀏覽器、作業系統或個別應用程式沒有額外的連線路徑。DNS 查詢、WebRTC、瀏覽器指紋、帳號登入狀態，以及用戶端本身的分流規則，都可能影響實際私隱效果。

因此，檢查 VPN 時不應只開啟一個 IP 查詢網站，確認顯示了其他地區就結束。比較可靠的做法，是在連線前後分別記錄公開 IP、DNS 解析服務與 WebRTC 暴露的位址，再檢查斷線時流量是否會被阻擋。本文會按照這個順序說明常見洩漏原因、檢查方式與修正步驟，並補充在公共 WiFi、手機與桌面用戶端中容易忽略的設定。

VPN 能保護什麼，不能保護什麼

啟用 VPN 後，裝置通常會先把流量送往 VPN 伺服器，再由伺服器連接目標網站或應用程式。對外部網站而言，連線來源通常會變成 VPN 出口，而不是家庭寬頻或行動網路直接分配給你的公開 IP。裝置與 VPN 伺服器之間的通道也會使用加密協定，降低同一個區域網路內的其他人直接讀取傳輸內容的機會。

不過，VPN 並不等於匿名工具。當你登入電子郵件、社羣平台或購物帳號時，服務仍然可以依照帳號、Cookie 和瀏覽器儲存資訊辨識你。網站也可能透過瀏覽器指紋、裝置語言、時區、螢幕特徵與使用行為建立關聯。VPN 主要改變的是網路路徑與 IP 暴露方式，不會替你清除已經交給網站的身分資料。

DNS 也需要單獨檢查。瀏覽器要連接網域時，通常先把網域名稱交給 DNS 服務解析成 IP。若 VPN 只接管一般流量，卻讓 DNS 查詢繼續送往本地電信商或作業系統預設解析器，外部觀察者仍可能從查詢內容推斷你正在存取哪些服務。這種情況不一定會暴露你的公開 IP，卻仍然屬於私隱路徑沒有完全一致的問題。

90+

覆蓋國家

200+

可用線路

14 天

退款承諾

不限

同時在線裝置

一句話結論：VPN 能改善網路路徑與傳輸私隱，但 IP、DNS、WebRTC、帳號與瀏覽器指紋必須分開檢查，不能用單一測試取代完整判斷。

如何檢查 DNS 洩漏

開始檢查前，先關閉其他代理工具，記下目前連線的網路名稱，並確認 VPN 用戶端已經顯示連線成功。Windows、macOS、Linux、Android 和 iOS 的系統 DNS 設定位置不同，而 Clash Verge、sing-box、Shadowrocket 等第三方用戶端也可能自行接管 DNS。測試時最好固定同一個用戶端與同一條線路，否則前後結果可能是不同路由造成，而不是設定真的修好了。

  1. 先在未連接 VPN 的狀態下開啟公開 IP 查詢頁與 DNS 洩漏測試頁，記錄顯示的網路供應商或解析服務名稱。
  2. 連接 VPN 後重新整理測試頁，不要只看頁面上的國家或城市，還要查看解析器所屬的網路與服務商。
  3. 切換到另一個瀏覽器或使用無痕視窗再次測試，避免舊頁面、快取或瀏覽器擴充功能影響結果。
  4. 在桌面系統清除 DNS 快取後重新查詢，確認結果不是連線前留下的快取記錄。
  5. 暫時斷開 VPN，再查詢同一個網域，對照解析器是否回到本地網路提供者。

桌面使用者也可以透過系統工具觀察解析結果。Windows 可在命令提示字元執行 nslookup example.com，macOS 或 Linux 可使用 dig example.com。這些指令主要用於查看目前使用的解析器與回應內容，不應把某一個網域的結果當成完整證明。不同應用程式可能使用自己的 DNS over HTTPS、DNS over TLS 或內建解析機制，瀏覽器看到的結果與命令列結果不一定完全相同。

如果 VPN 連線後仍顯示本地 DNS，先查看用戶端是否有「防止 DNS 洩漏」、「由 VPN 接管 DNS」或類似選項。使用 Clash Verge 或 sing-box 時，還要檢查設定檔中的 DNS 模式、fake-ip 或 redir-host 行為，以及規則是否把 DNS 請求送到預期的遠端解析器。Shadowrocket 則應確認全域路由、DNS 設定和目前使用的代理組合一致。不要同時開啟多個軟體的 DNS 接管功能，否則可能出現互相覆蓋。

WebRTC 洩漏從哪裡來，應該怎麼測試

WebRTC 是瀏覽器支援即時語音、視訊和點對點連線的一組技術。為了建立更直接的媒體連線，瀏覽器可能透過 ICE、STUN 或 TURN 機制收集候選位址。某些情況下，測試頁面可以看到裝置的區域網路位址、VPN 虛擬介面位址，甚至意外顯示不應該公開的連線資訊。這不是 VPN 加密通道突然失效，而是瀏覽器的即時通訊功能另外建立了候選路徑。

測試時先記錄未連線 VPN 的 WebRTC 候選位址，再連線 VPN 並重新開啟測試頁。注意不要只看「是否出現 IP」這個單一欄位，而要分辨哪些是本地私有位址、哪些是 VPN 介面位址、哪些可能是公開出口位址。WebRTC 測試頁的呈現方式各不相同，某些瀏覽器會隱藏部分資訊，某些版本則會在獲得網站授權後才開始收集候選位址。

若測試頁顯示了未預期的公開位址，可以先檢查瀏覽器的 WebRTC 私隱設定與網站權限。桌面瀏覽器通常能透過私隱設定、企業政策或可信任的內容封鎖擴充功能限制 WebRTC 的本地位址暴露；手機瀏覽器則受作業系統和瀏覽器版本限制，並非每個平台都提供同樣細緻的控制。修改設定後，必須完全關閉瀏覽器，再重新啟動並重測，單純重新整理頁面有時不會清除既有連線。

不要為了修正 WebRTC 而盲目停用所有即時通訊功能。若你需要使用網頁電話、線上會議或瀏覽器內的語音服務，限制 WebRTC 可能影響通話建立或媒體品質。較實際的方式，是隻對不需要即時通訊的瀏覽器或使用情境採取較嚴格限制，並把重要網站列入清楚管理的例外，而不是把所有權限永久放開。

  • ✅ 連線前後使用同一個瀏覽器與同一個測試頁比較結果
  • ✅ 分辨區域網路位址、VPN 介面位址與公開出口位址
  • ✅ 修改 WebRTC 設定後完全重啟瀏覽器再測試
  • ❌ 不要只因測試頁顯示私有位址，就直接判定公開 IP 已洩漏
  • ❌ 不要同時使用多個會修改 WebRTC 或代理設定的擴充功能

Kill Switch 與分流設定如何降低斷線風險

VPN 斷線時最容易被忽略的問題，不是畫面上顯示「未連線」，而是應用程式可能立即改走一般網路。瀏覽器正在載入的頁面、郵件同步、雲端硬碟或命令列程序，未必會等待 VPN 恢復。Kill Switch 的用途，就是在 VPN 通道中斷或狀態不符合條件時，暫停指定流量或整個裝置的外連，避免連線在短時間內回到未經預期的路徑。

不同用戶端對 Kill Switch 的實作不完全相同。有些是系統防火牆規則，有些依靠虛擬網路介面狀態，也有些只在特定代理模式下有效。開啟後應進行實際驗證：先連接 VPN，開啟一個可持續連線的網頁或終端機任務，再手動中斷 VPN，觀察新連線是否停止。重新連線後，檢查應用程式是否能恢復，不要只依賴設定頁上的勾選狀態。

分流模式也會影響檢查結果。全域模式通常把較多應用程式交給 VPN，但本地服務、印表機、區域網路裝置可能因此無法使用；規則分流則可讓部分網域或應用程式直連，但規則寫得不完整時，DNS、更新服務或背景程序可能走出不同路徑。對重視私隱的工作，應先使用較容易理解的全域或嚴格模式完成測試，再按需求逐項加入分流規則。

在第三方用戶端中，訂閱匯入只代表節點和規則資料已被讀取，不代表所有安全選項已自動符合你的需求。Clash Verge、sing-box 和 Shadowrocket 可能使用不同的核心、DNS 行為與路由語法。Windows、macOS、Android、iOS 和 Linux 官方用戶端也可能因系統權限不同而有不同表現。遇到洩漏時，應先確認目前實際運作的是哪一個用戶端，再檢查它是否取得 VPN、代理或防火牆所需權限。

設定優先順序：先確認只有一個主要用戶端接管流量，再測試 DNS 和 WebRTC，最後才為特定應用程式建立分流規則。順序混亂時，很難判斷是哪一層造成洩漏。

加密協定與公共 WiFi 的實用防護

WireGuard 通常以簡潔的設計和較少的設定選項著稱，適合希望快速建立穩定通道的使用者；OpenVPN 生態成熟，平台與網路環境的相容性較廣，遇到特殊網路時也常有較多調整空間。Trojan 主要以類似一般 TLS 流量的方式建立連線，實際效果取決於服務端配置與用戶端支援。Hysteria2 著重在特定網路條件下的傳輸表現，但需要相容核心與正確的伺服器設定。這些協定各有用途，不能只用名稱推斷一定更快或更安全。

WireGuard 和 OpenVPN 都是 VPN 通道協定，不應與單純的 HTTP 代理混為一談。Shadowsocks 常見於代理情境，VMess 也需要透過相容的代理核心使用；它們是否能妥善接管 DNS、UDP、IPv六和應用程式流量，取決於具體用戶端模式。選擇時應確認裝置平台、用戶端核心、Kill Switch、DNS 接管與分流支援，而不是隻挑一個看起來技術含量較高的協定。

公共 WiFi 的主要風險包括假冒熱點、錯誤網路設定、未加密的舊式服務，以及同一區域網路內的惡意裝置。連線到咖啡店、機場或旅館網路時，先確認熱點名稱與登入頁來源，不要在不明頁面輸入重要帳密。啟用 VPN 後仍應優先使用 HTTPS，因為 VPN 伺服器並不是目的地網站；網站端是否加密、帳號是否啟用多重驗證，仍然直接影響資料安全。

  1. 連接公共 WiFi 前關閉檔案共享、裝置探索和不需要的區域網路服務。
  2. 先完成 WiFi 的入口驗證，再開啟 VPN，避免登入頁被通道設定阻擋。
  3. 確認 VPN 狀態正常後，檢查公開 IP、DNS 和 WebRTC，而不是隻看用戶端圖示。
  4. 離開公共場所後忘記該 WiFi 網路，避免裝置下次自動連接同名或偽造熱點。
  5. 在共用電腦或他人裝置上，不要保存帳號、訂閱內容和私密金鑰。

完成檢查後的自我驗證清單

一次測試通過，不代表日後任何網路環境都會維持相同結果。更新瀏覽器、切換行動網路、安裝新的代理用戶端、修改訂閱設定，甚至作業系統重新啟動，都可能改變 DNS 或路由行為。建議在重大設定變更後重新檢查，並保留一份自己看得懂的記錄，例如使用的平台、用戶端、模式、線路與測試結果。

  • ✅ 公開 IP 已符合目前選擇的 VPN 出口，而不是本地網路的直接位址
  • ✅ DNS 查詢由預期的 VPN 或私隱解析路徑處理
  • ✅ WebRTC 沒有暴露不應公開的本地或真實連線資訊
  • ✅ VPN 中斷時，Kill Switch 能阻止重要應用程式改走直連
  • ✅ 只保留一個主要代理或 VPN 接管工具，避免規則互相衝突
  • ✅ 瀏覽器、作業系統和 VPN 用戶端都已套用可信的更新
  • ✅ 公共 WiFi 使用 HTTPS、帳號多重驗證和裝置鎖定等額外防護

如果只有某一個瀏覽器出現 WebRTC 異常，先處理瀏覽器權限和擴充功能；如果所有應用程式都出現 DNS 異常，則應優先檢查 VPN 用戶端的 DNS 接管、系統網路介面和路由模式。若問題只在睡眠喚醒、網路切換或訂閱更新後出現，應重建連線並重新測試，而不是隻更換一條線路。把問題分層定位，通常比反覆切換設定更快找到原因。

最終判斷：真正可靠的 VPN 使用方式不是盲目相信某個品牌或協定，而是定期檢查 IP、DNS、WebRTC 和斷線行為，並依照自己的裝置與應用程式需求設定合理的分流。