VPN 是否正常運作，不能只看用戶端的連線圖示。查 IP、查 DNS、逐一檢查應用程式，分別確認出口位置、網域由誰解析，以及目標軟體是否採用預期的連線路徑。比對連線前後的結果，再搭配分流規則，才能判斷設定是否符合用途。
先確認驗證範圍：已連線不代表所有流量都經過代理
「已連線」通常表示通道或代理連線已建立，不代表裝置上的所有請求都會經過代理。瀏覽器擴充功能可能只影響瀏覽器；系統代理通常需要應用程式主動遵循；TUN 或系統 VPN 介面能接管更多流量，但仍可能受路由、應用程式排除設定及協定支援範圍影響。
代理用戶端中的「全域」也要看上下文：它可能只是將已進入代理核心的請求全部交由所選節點處理，不代表所有應用程式都會自動使用代理。規則模式則會依網域、目標位址或處理程序等條件，選擇代理、直連或拒絕。因此，中國大陸網站顯示本地出口，不一定代表設定有問題。
查出口 IP：保留連線前後的對照
出口 IP 是目標網站看到的請求來源。開啟本站的IP 查詢頁面，先在中斷代理時記錄公網位址、位址類型及電信業者資訊；連線後再查一次。測試期間請維持相同網路，不要同時切換 Wi-Fi 與其他網路，以免出口變化其實是來自網路連線本身。
- 關閉其他代理擴充功能或重複執行的用戶端，記錄尚未連線時的查詢結果。
- 連線至目標節點，確認用戶端模式符合測試用途，再重新整理查詢頁面。
- 查看用戶端的連線記錄，確認查詢請求符合代理規則，並使用預期的出口。
- 中斷連線後再次查詢，觀察結果是否恢復為原本的網路出口；必要時關閉頁面後重新開啟。
出口改變表示這次查詢請求採用了不同的網路路徑，不能直接證明其他軟體也已由代理接管。位址沒有變化時，也別馬上認定節點失效：查詢網站可能被分流為直連、瀏覽器可能繞過系統代理，也可能正在使用另一種位址類型。
IP 地理位置資料庫的更新狀況不一。查詢頁面顯示的城市與節點名稱不同，不能單獨作為故障證據。更值得比對的是公網位址、網路業者、用戶端的出口記錄，以及目標服務能否正常運作。
| 觀察結果 | 可以說明什麼 | 還需要檢查什麼 |
|---|---|---|
| 查詢頁面的出口已改變 | 此頁面的請求使用了不同出口 | 目標應用程式與 DNS 是否也符合規則 |
| 查詢頁面的出口未改變 | 這次請求未呈現預期出口 | 直連規則、代理入口、快取與位址類型 |
| DNS 顯示不同地區 | 解析服務與網頁出口不一定位於同一地點 | 解析服務是否符合預期設定 |
| 瀏覽器正常，其他應用程式異常 | 不同應用程式可能採用不同的代理路徑 | 獨立代理設定、應用程式排除項目與路由 |
查 DNS：區分解析位置與洩漏
DNS 會將網域名稱轉換為可連線的位址。網頁請求經過代理，不代表網域解析也一定經過代理。如果預期讓解析留在通道內，實際上卻交由本地網路的解析服務處理，就需要檢查是否有非預期的解析請求外送。反過來說，如果規則明確設定本地域名使用本地解析，就不應直接將這種結果視為洩漏。
使用能觸發新網域查詢的 DNS 檢測頁面，比對連線前後的解析服務清單。重點是確認服務提供者是否符合用戶端設定，而不是要求解析服務所在國家與節點完全一致。公共 DNS 的分散式部署、上游轉送方式及檢測網站的辨識方法，都可能影響顯示結果。
瀏覽器安全 DNS 與系統 DNS 要分開檢查
瀏覽器的安全 DNS 可能透過 DoH 獨立發出解析請求，繞過系統解析設定；這些請求本身也可能經由代理或直接連線。排查時先記下瀏覽器設定，再確認用戶端是否接管這些請求，不要把「啟用加密 DNS」直接等同於「DNS 已進入通道」。
以下指令可協助查看系統解析工具回傳的伺服器與結果，但不能單獨證明瀏覽器採用的解析路徑。不同系統可能顯示本機轉送位址，也可能由工具直接連線至指定的解析服務。
nslookup example.com如果最近才調整設定，既有 DNS 快取可能讓檢測沒有觸發新請求。建議先使用檢測頁面提供的新查詢功能，再重新啟動目標應用程式測試。清除快取只能排除舊結果干擾，不能取代對解析路徑的確認。
逐一檢查應用程式：瀏覽器結果不代表所有軟體
先完全關閉目標軟體，再連線代理並重新開啟。既有的長時間連線可能繼續沿用原本路徑，背景處理程序也可能保留連線。接著在用戶端的連線面板查看目標網域、符合的規則、出口節點與流量變化；只看到總流量增加，還不足以證明該軟體已由代理接管。
- ✅ 瀏覽器：檢查擴充功能代理與系統代理是否重疊，並比對查詢請求的出口記錄。
- ✅ 桌面應用程式：確認軟體是否提供獨立代理選項，再檢查是否遭用戶端排除。
- ✅ 命令列工具：檢查代理環境變數及工具本身的設定，不要把終端機結果直接套用到瀏覽器。
- ✅ 遊戲、會議與即時通訊：分別觀察登入、內容載入與媒體連線，確認目前模式是否支援 UDP 等相關流量。
- ✅ 行動裝置應用程式：檢查系統 VPN 狀態、應用程式分流與背景限制，切換網路後重新驗證。
在 Windows 與 macOS 上，系統代理和虛擬網路介面是不同的流量接管方式。Linux 的終端機、桌面環境與應用程式可能各自使用不同的代理設定。iOS 與 Android 的 VPN 介面也不能取代對應用程式分流及用戶端功能的檢查。遇到差異時，應依據目前系統與用戶端的實際選項排查。
目標網站能開啟，只能表示目前可以存取；它原本就可能支援直連。反過來說，某個網站拒絕存取，也可能與帳戶地區、網站風險控管、服務範圍或應用程式快取有關，不能因此直接認定代理完全失效。
常見差異：IPv6、WebRTC 與分流規則
不同位址類型採用不同路徑
裝置可能同時具備 IPv4 與 IPv6 連線。如果代理只涵蓋其中一種，另一條路徑仍可能使用網路連線的出口。請使用能分別檢測位址類型的工具，並比對用戶端的 IPv6 支援與路由設定；若未檢測到某類位址，也可能只是目前網路未提供該連線，不能據此推論所有環境都不會有流量外送。
檢視 WebRTC 結果時，要留意位址類型
瀏覽器的即時通訊功能可能透過候選位址探測網路路徑。檢測結果中的區域網路位址、經過隱藏處理的本地主機名稱，與網路連線的公網位址並不相同。如果出現非預期的公網位址，應進一步檢查 UDP 路由及瀏覽器設定，而不是看到多出一個位址就直接判定所有流量都已洩漏。
規則、訂閱與連線狀態不在同一層
匯入訂閱只是將服務提供的節點或設定交給用戶端，不代表系統代理已啟用。訂閱更新後，還要確認目前選取的節點、模式及規則是否符合預期。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 等名稱代表不同的協定方案，不能只憑協定名稱判斷應用程式是否已由代理接管。
依據證據排查，避免反覆更換設定
保留原有設定，每次只調整一個相關選項。例如先處理應用程式未使用代理的問題，再檢查 DNS；否則同時更換節點、規則與解析服務，即使問題排除，也很難找出原因。測試結束後，請恢復成適合日常用途的設定。
向支援人員回報時，請說明作業系統、用戶端版本、連線模式、發生問題的應用程式與網域，並附上已去識別化的規則命中資訊及出口變化。清楚描述「瀏覽器出口已改變，但目標應用程式的連線仍是直連」，比籠統地說「VPN 沒用」更有助於找出問題。
判斷結果：出口 IP 符合預期、DNS 路徑符合設定，且目標應用程式使用了正確出口，這些證據彼此吻合，才足以說明受測情境已正常運作。單次檢測不能取代長期設定檢查；切換網路、更新用戶端或修改規則後，都應重新驗證。
VPN97 提供用戶端使用教學與線路資訊，可用來確認設定入口。無日誌政策是服務的隱私立場，不代表裝置端不會意外直連；本機路由、解析與應用程式設定仍須個別確認。