系統代理只是提供代理入口給應用程式，並不會接管所有連線。本文適用於 Windows 上「v2rayN 已啟動，但瀏覽器或終端機仍直接連線」的情況：先確認本機監聽，再檢查瀏覽器使用的代理來源，最後為終端機另行指定代理。比對相同網址、入口與核心記錄，可分辨應用程式未使用代理、路由選擇直連，或節點連線失敗。
先釐清：系統代理、應用程式代理與路由分流
開啟系統代理，不代表所有程式都會經過 v2rayN。Windows 的代理設定需要應用程式主動讀取；瀏覽器通常會使用系統設定，許多命令列工具則依賴自身參數或環境變數。瀏覽器可以連線、終端機卻失敗，不能直接判定是節點出了問題。
| 層級 | 負責事項 | 檢查重點 |
|---|---|---|
| 系統代理 | 提供代理位址給遵循系統設定的應用程式 | Windows 代理位址、連接埠與略過清單 |
| 應用程式代理 | 透過瀏覽器擴充功能、命令列參數等指定入口 | 是否覆寫系統設定、是否還留有舊連接埠 |
| 核心路由 | 決定送進核心的請求要直連或透過代理出站 | 規則順序、符合的規則與出站標籤 |
| TUN 模式 | 透過虛擬網路介面接收符合接管條件的流量 | 權限、路由、DNS 與排除項目 |
排查時先固定變數。暫時關閉 TUN，只保留一個正在執行的代理用戶端，並選定一個節點與測試網址。以下使用 https://example.com 示範請求方式；它不是專門測試特定地區連線能力的網站。檢查實際故障時，請再以原本無法連線的網址重測。
第一步：本機代理連接埠確實在監聽嗎？
先確認本機入口，再調整瀏覽器。以下以已確認支援 HTTP 代理的 127.0.0.1:10808 為例；這不代表所有版本都預設使用此連接埠。若用戶端顯示其他連接埠，所有命令都要一併替換；不可混用舊教學中的 HTTP 與 SOCKS 連接埠。
-
確認入口
在 v2rayN 開啟「設定」→「參數設定」，於基本設定中確認本機監聽相關項目的連接埠與入口協定。不同版本的介面可能調整分類名稱；也請查看主畫面狀態與核心啟動記錄，不要只憑連接埠數字猜測協定。
-
確認監聽狀態
在 PowerShell 執行下方的
Test-NetConnection。若TcpTestSucceeded顯示False，先確認核心是否已結束、連接埠是否輸入錯誤，再檢查啟動記錄。 -
確認處理程序
使用
netstat找出監聽記錄與 PID，再到工作管理員的「詳細資料」確認處理程序。連接埠可連線只代表有程式接收連線，不代表接收連線的一定是目前由 v2rayN 啟動的核心。 -
明確指定代理發送請求
使用後文的
curl.exe --proxy直接指定入口。若這一步成功，再檢查系統代理；若失敗，優先確認入口協定、節點參數與核心錯誤。
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"核心記錄出現 address already in use 時，應先排除連接埠衝突。不要直接結束不熟悉的處理程序；確認所屬程式後，關閉重複執行的執行個體，或變更本機連接埠，並重新套用系統代理設定。
瀏覽器未走代理：檢查系統設定、擴充功能與 PAC
排查瀏覽器時，關鍵是找出目前實際生效的代理來源。以 Edge 或 Chrome 為例，系統設定、代理擴充功能、啟動參數與組織原則都可能影響連線；只看到 v2rayN 的系統匣圖示，不能證明瀏覽器正在使用它。
-
套用系統代理
在 v2rayN 系統匣選單中選擇「系統代理」→「自動設定系統代理」。接著開啟 Windows「設定」→「網路和網際網路」→「Proxy」，確認手動代理的位址與連接埠符合目前的本機入口。
-
停用代理擴充功能
在瀏覽器選擇「擴充功能」→「管理擴充功能」，暫時停用管理代理的擴充功能，再重新啟動瀏覽器。不要只靠無痕視窗測試，因為部分擴充功能允許在無痕視窗中執行，瀏覽器原則也仍會生效。
-
檢查自動設定指令碼
在 Windows 同一個「Proxy」頁面檢查「使用設定指令碼」。若已啟用，請確認指令碼網址與規則；排查時記下原設定，暫時改用單一手動代理入口，避免 PAC 回傳
DIRECT影響判斷。 -
重新測試並查看記錄
關閉並重新開啟瀏覽器，連線至相同的測試網址，同時查看核心存取記錄。請求進入核心後，還要確認出站標籤；符合直連規則屬於路由選擇，並非系統代理失效。
PAC 決定「應用程式要把請求交給誰」，核心路由則決定「收到請求後要往哪裡送」。這兩層都可能造成流量直連，但修正方式不同。若只想讓單一網站走代理，不要同時重寫 PAC、DNS 與所有路由規則。
判斷方式：明確指定代理後成功，優先檢查瀏覽器入口
若透過指定代理的 curl 請求能連上同一網址，但瀏覽器請求未出現在已啟用的存取記錄中，下一步應檢查擴充功能、PAC 與瀏覽器原則；暫時不要更換 VMess、VLESS 或傳輸參數。
終端機未走代理：先用 curl 參數測試，再設定環境變數
命令列程式通常不會因為 Windows 已啟用系統代理就自動改走代理。先用明確指定的參數驗證，再考慮設定環境變數。在 PowerShell 中建議完整輸入 curl.exe，避免 Windows PowerShell 的 curl 別名呼叫其他命令，造成參數意義不同。
用一個請求驗證 HTTP 代理入口
以下命令不依賴系統代理。--noproxy 會在本次請求中，將略過代理的目標限定為保留測試網域 unused.invalid，避免既有的 NO_PROXY 設定讓 example.com 意外直連。此命令不會變更持久設定。
curl.exe --proxy http://127.0.0.1:10808 --noproxy unused.invalid --connect-timeout 10 --verbose --head https://example.com詳細輸出中，連線至 127.0.0.1 的資訊，以及 HTTPS 請求的 CONNECT 過程，可用來確認代理入口；HTTP 回應碼則反映後續請求結果。收到回應不代表流量一定經過遠端代理節點，還要比對核心的出站記錄。分享記錄前，請移除認證資訊與敏感位址。
為目前的 PowerShell 工作階段設定代理
$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe --connect-timeout 10 --head https://example.com在 HTTPS_PROXY 中保留 http:// 是合理的：它表示終端機連到本機 HTTP 代理入口時使用的連線方式，HTTPS 目標通常透過 CONNECT 通道存取。不要只因目標網址使用 HTTPS，就擅自把代理入口改成 https://。
- 生效範圍：這些 PowerShell 指派只會影響目前工作階段與之後啟動的子處理程序。已在執行的其他終端機不會同步取得這些變數。
- 工具差異：環境變數並非通用的強制規則。不同工具可能需要小寫變數、專用設定或命令列參數，請查閱該工具的文件。
- 終端環境差異：WSL 與容器可能使用獨立的網路環境，其中的
127.0.0.1不一定指向 Windows 主機的入口，不能直接照抄位址。 - SOCKS 入口：只有確認該連接埠支援 SOCKS5，才使用相應參數；curl 的
socks5h://代表將目標網域交由代理端解析，不要用來連接僅支援 HTTP 的連接埠。
測試完成後清除工作階段變數
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue清除前請先記下原值；已設定代理環境的電腦應還原原本設定。尤其不要急著把測試變數寫入系統層級環境變數：結束 v2rayN 後，本機連接埠會關閉，繼承這些變數的程式可能持續回報連線失敗。
看到錯誤訊息後，該檢查哪一層？
解讀錯誤訊息時，還要留意錯誤發生的位置。同樣是「逾時」，可能是終端機連不上本機入口、核心連不上遠端伺服器，或遠端無法連線至目標網站。以下列出實際錯誤訊息，不同版本可能會在前後附上位址、連接埠與耗時。
錯誤：curl: (7) Failed to connect
原因：無法建立連線；在明確指定代理的測試中，若後續訊息指向本機位址，通常表示入口未監聽或連接埠錯誤。解法：確認 curl 輸出中的位址，透過監聽狀態檢查確認連接埠與處理程序，再重新啟動核心。
錯誤：curl: (5) Could not resolve proxy
原因：無法解析代理主機名稱，常見原因是代理變數拼寫錯誤。解法：使用 Get-ChildItem Env:*proxy* 檢查變數，改成已確認的本機入口後再測試。
錯誤：curl: (28) Connection timed out
原因：連線階段超過時間限制，不能只憑這項訊息判定節點失效。解法：先用詳細輸出確認卡在哪一步，再比對同一時間的核心記錄，檢查遠端連線與路由結果。
錯誤：ERR_PROXY_CONNECTION_FAILED
原因：瀏覽器無法連上所設定的代理。解法：檢查 Windows 代理設定與擴充功能中是否留有舊連接埠；確認核心已成功啟動後，重新開啟瀏覽器。不要先修改網站 DNS。
什麼時候使用 TUN 模式比較省事？
多個應用程式都不讀取系統代理，又不方便逐一設定時，才值得考慮 TUN。它透過虛擬介面與路由接管流量，但仍會受到所用核心、DNS 策略與排除規則影響；這不代表任何流量都會無條件經過遠端節點。
- 先建立基準：確認明確指定 HTTP 代理的測試能成功，記下目前的節點與路由設定，再啟用 TUN。否則入口問題與虛擬網卡問題會混在一起。
- 依提示授予權限：在 v2rayN 主畫面啟用 TUN；若提示需要管理員權限，請依照提示重新啟動。接著查看虛擬介面、路由與 DNS 初始化記錄。
- 避免重複指定代理：首次比對測試時，先清除終端機代理變數，並將「系統代理」切換為「清除系統代理」，單獨驗證 TUN 路徑；不要同時變更多個入口。
- 保留工作網路：測試區域網路裝置與公司內部網域是否能正常連線。若與其他虛擬網卡或工作網路衝突，先關閉 TUN 還原，再調整排除項目。
如何選擇：單一工具用參數，多個應用程式再考慮 TUN
只有一個命令失敗時，優先設定該工具的代理；多個應用程式都需要接管時，再評估 TUN。TUN 能減少逐一設定入口的工作，但無法修正錯誤的節點參數或無法連線的伺服器。
常見問題：已啟用代理，為什麼結果還是不一樣？
瀏覽器可以連線，PowerShell 還是連不上？
先執行帶有 --proxy 的 curl.exe 命令。若成功，再設定目前終端機的代理變數；若只有某個工具失敗，請檢查該工具自己的代理選項，不要因此更換節點。
記錄中有請求，為什麼出口沒有改變？
檢查該請求對應的出站標籤。若符合 direct 或其他直連出站，表示入口已生效；應調整目標網域的路由規則與順序，而不是反覆切換系統代理。
關閉 v2rayN 後，瀏覽器也無法連線？
結束前，請在系統匣的「系統代理」選擇「清除系統代理」。若程式已關閉，請前往 Windows「設定」→「網路和網際網路」→「Proxy」還原原本設定，並檢查是否還留有自動設定指令碼。
需要執行 netsh 代理匯入命令嗎？
不應將它當成通用修復方式。WinHTTP 代理與瀏覽器常用的系統代理設定並不相同；只有確認目標服務使用 WinHTTP 後，才檢查其代理狀態，以免影響其他系統服務。
最後應以三項可觀察結果作出判斷：應用程式是否連上本機入口、核心是否收到請求，以及該請求選用了哪個出站。依照這個順序蒐集線索，比反覆重新安裝用戶端或隨意修改 DNS 更容易找出問題。若要重新了解首次匯入與代理設定，請接著閱讀快速入門教學。