本文適合遇到「瀏覽器能開啟但終端機失敗」、「系統代理已開啟但部分程式仍直接連線」，或看到「代理錯誤提示連線遭拒」的 Windows 使用者。先確認 v2rayN 與代理核心是否建立本機監聽，再分別驗證瀏覽器和命令列工具的接入方式，最後依應用程式涵蓋範圍判斷是否需要 TUN。
先將「無法使用」拆成三個範圍
v2rayN 是管理設定與核心的桌面用戶端，Xray 等代理核心負責處理實際連線，Windows 系統代理則只是向部分應用程式提供本機代理位址。開啟系統代理不等於強制所有網路連線都送入核心，更不代表路由規則一定會選擇代理出口。
第一層是本機監聽。用戶端啟動核心後，通常會在迴環位址上監聽 HTTP、SOCKS 或混合代理連接埠。只有監聽確實存在，瀏覽器和終端機才有可連線的入口。第二層是應用程式接入：應用程式是否讀取 Windows 系統代理，或是否使用自行儲存的獨立代理設定。第三層才是路由與出站：連線進入核心後，由設定中的網域、IP、協定及規則決定直連、代理或阻擋。
因此，「瀏覽器能用，PowerShell 不能用」通常不是節點突然失效，而是兩者的接入方式不同；「瀏覽器顯示代理連線失敗」則應先檢查本機連接埠，而不是先修改 VLESS、VMess 或 TLS 參數。依層次排查可避免將入口問題誤判為伺服器問題。
| 現象 | 優先檢查 | 暫不優先處理 |
|---|---|---|
| 所有瀏覽器都顯示代理連線失敗 | 核心程序、本機監聽位址、連接埠佔用情況 | 瀏覽器快取與網站帳戶 |
| 瀏覽器正常，終端機直接連線或逾時 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與工具參數 | 重新匯入訂閱 |
| 只有一個瀏覽器異常 | 瀏覽器獨立代理、擴充功能接管、啟動參數 | Windows 全域網路重設 |
| 代理測試成功，但特定網域仍直接連線 | 路由規則、網域比對、DNS 解析位置 | 更換本機監聽連接埠 |
第一步：確認核心與本機監聽
先在 v2rayN 中選取一個設定並啟動核心，再查看主介面或記錄區是否出現啟動失敗、連接埠佔用或設定解析錯誤。訂閱只是設定來源；成功更新訂閱不代表核心已經執行，也不代表系統代理已指向正確的連接埠。
接著開啟「設定」→「參數設定」，記下目前 HTTP 與 SOCKS 的監聽連接埠。若版本介面採用統一的混合連接埠，也應記下介面顯示的實際數值。監聽位址通常應為 127.0.0.1，只接受本機連線；除非明確需要區域網路接入，否則不要為了排錯隨意改成面向所有網路介面的位址。
記錄連接埠
進入 v2rayN「設定」→「參數設定」，抄下 HTTP、SOCKS 或混合監聽連接埠，不要根據舊教學猜測數值。
檢查程序
啟動選取的設定，確認用戶端沒有連續跳出核心退出提示，並在記錄中找出第一筆錯誤，而不是只看最後一行。
查詢監聽狀態
在 PowerShell 中執行
Get-NetTCPConnection，確認目標連接埠處於 Listen 狀態，並記下對應的程序識別碼。測試入口
使用
Test-NetConnection測試迴環位址與 HTTP 連接埠；若 TCP 測試失敗，先處理監聽問題。
Get-NetTCPConnection -State Listen |
Where-Object { $_.LocalPort -in 10808, 10809 } |
Select-Object LocalAddress, LocalPort, OwningProcess
Test-NetConnection 127.0.0.1 -Port 10809TcpTestSucceeded 顯示 True 只能證明連接埠接受 TCP 連線，不能單獨證明節點協定、伺服器位址或路由規則正確。下一步仍需透過明確指定代理的請求來驗證完整鏈路。若查詢結果中沒有目標連接埠，請回到 v2rayN 記錄處理核心啟動問題；若連接埠被其他程序佔用，可用 Get-Process -Id 程序識別碼 確認程式來源。
錯誤：ERR_PROXY_CONNECTION_FAILED
原因與解法：瀏覽器無法連線至已設定的本機代理——確認 v2rayN 是否正在執行、系統代理中的連接埠是否與「參數設定」一致，並檢查連接埠是否被其他程序佔用。
錯誤：TcpTestSucceeded : False
原因與解法：指定位址與連接埠沒有可用的監聽——先啟動核心並檢查記錄；若剛修改連接埠，應重新啟動核心後再測試，不要繼續排查遠端節點。
錯誤：Only one usage of each socket address is normally permitted
原因與解法：目標連接埠已被另一個程序佔用——找出 OwningProcess，關閉重複啟動的執行個體，或在 v2rayN 中改用未佔用的連接埠，並同步更新其他應用程式設定。
瀏覽器分開檢查「跟隨系統」與「獨立設定」
多數依賴系統網路設定運作的桌面瀏覽器會讀取 Windows 代理，但瀏覽器擴充功能、企業原則、啟動參數或瀏覽器自身的網路設定可能會覆蓋這項行為。排查時先只保留一個控制來源：要麼跟隨 Windows 系統代理，要麼在瀏覽器中明確指定本機代理，不要讓擴充功能與系統設定同時改寫出口。
在 v2rayN 系統匣選單中選擇系統代理相關選項時，應確認採用的模式符合目前需求，例如自動設定系統代理。接著開啟 Windows「設定」→「網路和 Internet」→「代理」，查看手動代理或自動設定指令碼是否反映目前用戶端設定。不同 v2rayN 模式可能以不同方式寫入系統設定，因此不要再手動覆寫位址。
若只有一個瀏覽器異常，可先建立暫時的瀏覽器設定檔，或停用負責代理切換的擴充功能，再重新測試。隱私視窗通常不會繞過系統代理，因此適合用來排除快取與登入狀態，不適合用來證明代理入口已恢復。瀏覽器中的安全 DNS 負責網域解析，並不等同於 HTTP 或 SOCKS 代理。
統一來源
暫時停用瀏覽器內負責代理切換的擴充功能，刪除測試用啟動參數，只保留 Windows 系統代理這一條控制路徑。
核對系統
開啟 Windows「設定」→「網路和 Internet」→「代理」，檢查位址、連接埠或自動設定狀態是否與 v2rayN 目前模式相符。
重新啟動瀏覽器
完全退出所有瀏覽器程序後重新開啟，避免舊程序繼續使用啟動時讀取的代理設定。
逐一比對
先測試一個一般 HTTPS 頁面，再測試原先失敗的網域；若只有後者失敗，改查路由、DNS、SNI 與伺服器設定。
瀏覽器擴充功能顯示直接連線怎麼辦？
擴充功能可能優先於系統設定。先停用擴充功能並重新啟動瀏覽器；若恢復正常，再在擴充功能中將 HTTP 或 SOCKS 位址改為 v2rayN 目前的監聽值。
一個瀏覽器能用，另一個不能用？
比較兩者是否都跟隨系統代理，檢查異常瀏覽器的原則頁面、代理擴充功能與啟動捷徑中是否存在獨立的代理參數。
關閉安全 DNS 就能修好嗎？
安全 DNS 與代理入口不在同一層。只有記錄明確指向網域解析問題時才調整 DNS；連線本機代理連接埠失敗時，關閉安全 DNS 沒有作用。
終端機程式需要明確設定代理環境
PowerShell、命令列下載工具、套件管理器和開發工具不一定會讀取 Windows 系統代理。有些程式只辨識大寫環境變數，有些同時辨識大小寫變數，另一些則要求在自己的設定檔中指定代理。系統代理已開啟但終端機仍直接連線，是這類程式常見的情況。
先使用 curl.exe 的 --proxy 參數進行一次明確測試。這樣可以排除「工具是否讀取系統設定」的不確定性，直接驗證從本機入口到目標網站的完整請求。HTTP 連接埠範例為 10809；SOCKS 連接埠範例為 10808，實際測試前仍須替換成 v2rayN 目前的數值。
curl.exe --proxy http://127.0.0.1:10809 https://example.com/ --max-time 10
curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --max-time 10socks5h 中的字母 h 表示由代理端處理目標主機名稱，適合用來比對本機 DNS 與代理端解析的差異。如果 HTTP 與 SOCKS 測試都成功，而不帶 --proxy 的命令失敗或直接連線，問題就在終端機的接入方式，不應繼續更換訂閱設定。
若要讓目前 PowerShell 工作階段中的多個工具嘗試使用代理，可以暫時設定環境變數。工作階段關閉後，這些變數就會消失，適合用於排查；在寫入使用者層級或系統層級環境前，應先確認相關工具支援該變數，以及它對內部網路位址的影響。
$env:HTTP_PROXY = "http://127.0.0.1:10809"
$env:HTTPS_PROXY = "http://127.0.0.1:10809"
$env:ALL_PROXY = "socks5h://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1"
Get-ChildItem Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY錯誤：curl: (7) Failed to connect to 127.0.0.1 port 10809
原因與解法：curl 無法存取指定的本機連接埠——確認連接埠類型與數值，檢查核心監聽狀態；如果 v2rayN 使用混合連接埠，應改填該連接埠。
錯誤：curl: (28) Operation timed out after 10000 milliseconds
原因與解法：請求已超過 10 秒限制——若本機 TCP 連線成功，繼續查看核心記錄中的 DNS、遠端連線、TLS 或路由錯誤；若完全沒有入站記錄，請檢查命令中的代理位址。
錯誤：The underlying connection was closed
原因與解法：連線建立後在協定或 TLS 階段被關閉——先用 curl 進行對照測試，再核對節點網域、系統時間、SNI 與憑證設定，不要將關閉憑證驗證當作長期處理方式。
接入成功後再檢查路由與 DNS
當明確指定代理的請求能到達核心，但特定網站仍然失敗時，排查重點才從「應用程式是否接入」轉向「核心如何處理」。v2rayN 管理的路由規則可能依網域、IP 或協定選擇直連與代理。VLESS、VMess 是節點協定設定的一部分，不會決定終端機是否讀取 Windows 系統代理。
查看記錄時應對應同一次測試請求：先清楚記下測試時間，再發出單一請求，觀察是否出現目標網域、比對規則和出站錯誤。如果記錄完全沒有這次請求，表示流量尚未進入核心；如果記錄中有請求且明確選擇直連，請檢查路由規則；如果選擇代理後出現解析或握手錯誤，再處理節點參數與 DNS。
| 記錄現象 | 判斷 | 下一步 |
|---|---|---|
| 測試期間沒有對應請求 | 應用程式未接入本機代理 | 檢查瀏覽器設定、命令參數或環境變數 |
| 請求進入後比對到直連 | 路由規則選擇直連出口 | 核對網域規則、IP 規則及規則順序 |
| 出現網域解析失敗 | DNS 設定或解析路徑異常 | 比對本機解析與代理端解析，檢查網域拼寫 |
| 連線至遠端後握手失敗 | 節點協定或 TLS 階段異常 | 核對伺服器名稱、系統時間、傳輸參數 |
- 訂閱更新只負責取得設定清單，不能證明其中每個設定目前都能建立連線。
- 系統代理決定部分應用程式如何找到本機入口，路由分流則決定進入核心後的流量走向。
- 本機 DNS 先解析與代理端解析可能得到不同結果，使用 SOCKS 測試時可比對
socks5與socks5h。 - 修改規則後應重新發出單一請求，並用新記錄驗證，不要同時修改連接埠、DNS、節點和路由。
何時才需要考慮 TUN
TUN 適合需要涵蓋不支援 HTTP 或 SOCKS 代理設定的應用程式，或希望統一接管更多網路流量的情境。它透過虛擬網路介面改變流量接入方式，因此涵蓋範圍通常比系統代理更廣，但同時涉及路由表、DNS、管理員權限，以及與其他 VPN 類連線之間的協調。
如果問題只出現在一個支援代理參數的終端機工具，優先設定該工具或使用環境變數，通常更容易觀察和還原。如果多個應用程式完全不讀取系統代理，而且逐一設定的成本較高，再評估 TUN。不要把 TUN 當成本機連接埠未監聽、節點握手失敗或路由規則錯誤的替代修復方案。
瀏覽器正常，遊戲或專用程式不走代理？
先確認該程式是否提供 HTTP、SOCKS 或網路代理設定。沒有代理入口且確實需要納入涵蓋範圍時，再評估 TUN，並檢查其服務條款與網路需求。
啟用 TUN 後還需要開啟系統代理嗎？
取決於目前用戶端設定與接管方案，不應機械式地同時開啟。先明確由哪種方式負責接入，避免重複代理或讓排錯路徑變得不清楚。
啟用 TUN 後完全斷網怎麼辦？
先關閉 TUN 以恢復基本網路，再檢查管理員權限、虛擬介面、DNS 與路由衝突。若其他 VPN 連線正在執行，應先避免同時接管同一流量。
終端機設定環境變數後還需要 TUN 嗎？
若目標工具已穩定透過 HTTP_PROXY 或明確的代理參數運作，就沒有必要僅為該工具啟用 TUN。繼續採用範圍最小、行為可驗證的接入方式。
依最小變更順序完成複查
一次只改變一個條件，才能知道是哪一步恢復了連線。最穩妥的順序是本機監聽、明確代理測試、應用程式接入設定、路由與 DNS，最後才是 TUN。每一步都保留對應的連接埠、命令結果和記錄時間，避免只憑介面開關狀態判斷。
- 在 v2rayN「設定」→「參數設定」記錄目前的監聽位址與連接埠，確認核心已啟動。
- 使用
Get-NetTCPConnection與Test-NetConnection驗證連接埠確實處於監聽狀態。 - 使用
curl.exe --proxy分別測試 HTTP 或 SOCKS 入口，逾時限制設為 10 秒。 - 瀏覽器只保留一種代理控制來源，完全退出後重新啟動，再與其他瀏覽器比對。
- 終端機透過命令參數或暫時環境變數接入，不要假設它會自動讀取 Windows 系統代理。
- 確認請求已進入核心後，再依記錄檢查路由分流、DNS、節點協定與 TLS。
- 只有在多個應用程式無法個別設定代理，且確實需要擴大涵蓋範圍時，才設定並驗證 TUN。