VPN 是否安全，不能只用「有沒有加密」一句話回答。加密可以降低本地網路攔截內容的風險，但不代表 VPN 業者看不到任何資訊，也不代表所有應用程式都會自動經過 VPN。實際安全性取決於協定、客戶端權限、DNS 設定、瀏覽器 WebRTC 行為、分流規則，以及服務方如何保存與處理連線資料。

因此，閱讀「無日誌」宣稱時，應把它當作需要核對的政策，而不是安全保證。使用者需要知道：哪些資料會被暫存、保存多久、是否記錄來源 IP、是否記錄頻寬用量、是否有第三方分析工具，以及收到法律要求時能提供什麼資料。本文將從加密與信任邊界開始，逐步說明 DNS 外洩與 WebRTC 外洩的檢查方式，再整理 Kill Switch 和公共 Wi-Fi 使用時的設定原則。

VPN真的安⁠全嗎？隱⁠私、加密與DNS外洩檢查攻略

加密與信任邊界：VPN 到底保護了什麼

未啟用 VPN 時，裝置通常會先連到本地網路，再由網路服務供應商轉送請求。啟用 VPN 後，客戶端會先與 VPN 伺服器建立通道，裝置到 VPN 伺服器之間的資料會依照協定進行封裝與加密。對公共 Wi-Fi 來說，這能降低同一網路中的其他使用者直接讀取傳輸內容或辨識造訪目標的機會。

不過，加密通道的終點是 VPN 伺服器，而不是目標網站。VPN 服務方通常可以看到連線建立時間、流量方向、伺服器選擇等部分網路資訊；目標網站則可能看到 VPN 出口的 IP 位址，而不是家庭網路或行動網路的原始位址。這代表 VPN 改變了信任對象，並不是讓所有一切都變得匿名。

常見協定各有取捨。WireGuard 結構較精簡，通常容易部署，適合希望維持簡單設定的使用者；OpenVPN 生態成熟，可在不少路由器與第三方客戶端中使用；IKEv2 在行動裝置切換 Wi-Fi 與行動網路時通常較方便。部分服務也提供 Shadowsocks、VMess、Trojan 或 Hysteria2 等相容方案，但這些名稱本身不等於安全等級。真正需要查看的是客戶端是否正確驗證伺服器、是否使用可靠加密套件，以及設定檔是否來自可信任來源。

選擇服務時，應把「加密」與「資料政策」分開評估。即使協定本身設計良好，若客戶端會把訂閱連結、診斷記錄或連線歷史送往不明服務，整體風險仍然存在。相反地，清楚的隱私政策、可取得的客戶端、明確的權限說明，以及可追蹤的客服管道，才是較有實際參考價值的訊號。

• ✅ 確認客戶端顯示的協定與匯入設定一致，不要只看節點名稱。
• ✅ 閱讀隱私政策對連線記錄、診斷資料與付款資訊的說明。
• ✅ 將訂閱連結視為敏感憑證，不要貼到公開羣組或線上解析網站。
• ❌ 不要因為頁面寫著「軍用級加密」就跳過權限與日誌政策檢查。

DNS 與 WebRTC 外洩：連線成功不代表沒有暴露

DNS 的作用是把網域名稱轉換成 IP 位址。若 VPN 已連線，但系統仍把 DNS 查詢送往本地電信商、公司網路或公共 Wi-Fi 提供的 DNS 伺服器，第三方可能從查詢紀錄推測你正在存取哪些服務。這就是常說的 DNS 外洩。它不一定代表頁面內容已被讀取，但會暴露造訪目標與使用習慣的一部分資訊。

DNS 外洩常見於「只有瀏覽器走代理、系統其他流量保持直連」的模式，也可能是客戶端沒有接管 DNS、作業系統保留舊有解析器，或自訂 DNS 與分流規則互相衝突。Windows、macOS、Android、iOS 和 Linux 的處理方式不同，不能只依照另一個平台的教學照搬。部分官方客戶端會在連線時自動處理 DNS；使用 Clash Verge、sing-box 或 Shadowrocket 時，則要另外查看 DNS 模式與路由規則。

WebRTC 是瀏覽器用於即時通訊、語音、視訊與資料傳輸的技術。為了建立點對點連線，瀏覽器可能透過 ICE 機製取得候選網路位址。若瀏覽器或擴充功能允許直接連線，某些網站可能看到不符合預期的本地或實際網路位址。這與 DNS 外洩不同：DNS 關註名稱解析去了哪裡，WebRTC 則關注瀏覽器在建立即時連線時透露了哪些候選位址。

檢查時不要只測一個網站或只看瀏覽器右上角的 VPN 圖示。先在未連線狀態記錄出口 IP 與 DNS 結果，再連線後重新測試；切換線路、重新啟動客戶端或更換網路環境後，也應再次檢查。若不同測試頁的結果互相矛盾，可能是瀏覽器快取、IPv6、分流或測試頁本身的判斷方式不同，應回到客戶端與系統設定逐項排查。

動手檢查與修復：從瀏覽器到客戶端逐項確認

以下流程適用於大多數桌面與行動裝置，介面名稱可能因官方客戶端或相容客戶端而略有差異。測試前先關閉不必要的代理工具、瀏覽器 VPN 擴充功能與其他網路過濾器。兩個工具同時接管流量時，結果可能看似成功，實際上卻很難判斷是哪一層在處理 DNS 或 WebRTC。

1. 先記錄目前的外部 IP、DNS 伺服器與瀏覽器 WebRTC 測試結果。不要把完整訂閱連結或帳戶資料輸入第三方測試頁。
2. 開啟官方客戶端或相容客戶端，確認訂閱設定已成功更新，並選擇一條與目標服務地區相符的線路。
3. 啟用系統代理或 VPN 模式，等待客戶端顯示已連線。若使用 Clash Verge、sing-box 或 Shadowrocket，確認目前配置檔確實被選中。
4. 重新檢查外部 IP。若 IP 沒有改變，先檢查是否只開啟了瀏覽器代理、是否啟用全域或規則模式，以及目標測試頁是否被加入直連清單。
5. 檢查 DNS 結果。若仍顯示本地網路的 DNS，先在客戶端啟用 DNS 接管或安全 DNS 選項，再重新連線；不要在多個位置同時填寫互相衝突的 DNS。
6. 在瀏覽器中檢查 WebRTC 權限。若不需要視訊會議或即時通訊功能，可限制網站存取本地網路資訊；需要使用 WebRTC 時，則應確認瀏覽器與客戶端的相容設定。
7. 最後測試斷線行為。手動中斷 VPN 後，觀察瀏覽器是否仍可載入需要代理的頁面；若可以，表示可能存在直連、分流或 Kill Switch 未生效的情況。

修復後不要立即同時修改十項設定。比較穩妥的方式是一次只調整一個項目，重新連線，再記錄結果。例如先只啟用 DNS 接管，確認 DNS 改變後，再測試 IPv6；接著才處理 WebRTC 或分流。這樣即使問題再次出現，也能知道是哪一項改動造成影響。

分流與例外規則怎麼看

規則模式適合需要讓部分本地服務直連、其他目標經過 VPN 的情況，但便利性也帶來判斷難度。常見例外包括區域網路、公司內網、銀行 App、本地影音服務與系統更新服務。若某個 App 無法連線，不能直接認定 VPN 不安全，可能只是它沒有遵守系統代理，或被規則判定為直連。

查看規則時，優先尋找「直連」「代理」「全域」「排除」與「DNS」等設定。對付款、帳號登入或工作服務，應確認瀏覽器與 App 的流量路徑一致，避免登入頁經過一條路徑、驗證請求卻從另一條路徑送出。若無法理解複雜規則，先使用官方客戶端的預設模式完成測試，再逐步加入例外。

Kill Switch 與公共 Wi-Fi：避免斷線後直接連出

Kill Switch 的目的，是在 VPN 通道中斷、客戶端崩潰或網路切換期間，暫時阻止指定流量直接使用一般網路。它不是加密協定，也不是防毒功能，而是一個「通道失效時先停止傳輸」的控制機制。不同客戶端可能稱為網路鎖定、斷線保護、阻止 VPN 外流或 Always-on VPN，啟用前應閱讀它對區域網路與本地裝置的影響。

在咖啡店、機場、旅館或共享辦公室使用公共 Wi-Fi 時，建議先連上網路入口頁，再啟用 VPN。許多公共 Wi-Fi 需要先接受使用條款或輸入驗證資訊；如果一開始就啟用嚴格 Kill Switch，入口頁可能無法開啟。完成登入後再啟用 VPN，並確認客戶端顯示已連線。離開網路環境前，先中斷 VPN，再依需要忘記該 Wi-Fi，避免裝置下次自動連線到名稱相同的網路。

付款與帳號登入時，VPN 只能保護部分傳輸路徑，不能保證網站、付款平台或裝置本身沒有其他風險。應確認網址使用 HTTPS，避免在公用裝置上儲存密碼，並開啟雙重驗證。若銀行或付款服務因 IP 位置改變而觸發額外驗證，不要反覆切換多個國家線路；先回到固定、符合使用情境的線路，必要時依服務方要求完成驗證。

• ✅ 在公共 Wi-Fi 完成入口認證後，再開啟 VPN 與 Kill Switch。
• ✅ 啟用後測試 VPN 中斷時，非必要流量是否真的停止。
• ✅ 切換 Wi-Fi、行動網路與睡眠喚醒後，重新確認連線狀態。
• ✅ 付款與登入前確認瀏覽器網址、雙重驗證與裝置鎖定狀態。
• ❌ 不要把 Kill Switch 當成惡意網站、釣魚郵件或帳戶盜用的完整防護。
• ❌ 不要為了讓某個 App 正常運作，就永久關閉所有斷線保護。

最後，應定期重新檢查隱私設定。客戶端更新、作業系統升級、瀏覽器權限變更，或重新匯入訂閱後，都可能改變 DNS 接管、IPv6、分流與 Kill Switch 行為。若使用多台裝置，Windows、macOS、Android、iOS 與 Linux 應分別測試，不要假設一台裝置的結果能代表全部設備。