先明確指定代理，確認本機連接埠與節點正常，再分別檢查瀏覽器的代理來源和終端機的環境變數，最後判斷是否需要 TUN。本文以 Windows 版 v2rayN 為操作範例，適合「瀏覽器能用、終端機不能用」或「開啟系統代理後仍直接連線」的情況；請先確認範例連接埠與本機設定一致。
先釐清系統代理、本機連接埠與路由分流
v2rayN 的「自動設定系統代理」主要是將代理位址寫入作業系統設定，不代表所有程式的流量都會被攔截。應用程式必須主動讀取這項設定，才會連線至本機代理。瀏覽器通常會讀取系統代理，命令列工具則各有設定方式，因此同一台電腦出現兩種結果並不矛盾。
請求進入本機代理後，核心會依路由規則選擇直連、代理或封鎖。開啟系統代理只代表應用程式有機會連上核心，不保證所有連線都會透過遠端節點。訂閱更新成功或節點延遲測試有結果，也不能取代實際網頁請求的驗證。
| 檢查層級 | 負責項目 | 主要依據 |
|---|---|---|
| 應用程式代理設定 | 決定是否將請求交給本機代理 | 瀏覽器設定、啟動參數、終端機參數 |
| 本機入站連接埠 | 接收 HTTP 或 SOCKS 請求 | 監聽位址、監聽連接埠、核心啟動記錄 |
| 路由與 DNS | 決定網域名稱如何解析，以及連線從哪裡送出 | 存取記錄中的目標與出站標籤 |
| 遠端節點 | 建立代理連線並轉送流量 | 實際請求結果、交握錯誤、逾時記錄 |
排查時先關閉 TUN，只保留一個代理用戶端執行。這樣可避免 TUN 替錯誤的系統代理設定「補位」，也能減少兩種流量接管方式同時啟用造成的干擾。若裝置由公司或組織管理，請勿繞過組織設定的網路政策。
步驟一：確認連接埠，再測試明確指定代理
先開啟 v2rayN 的「設定」→「參數設定」，確認本機監聽連接埠與入站協定，並查看核心啟動記錄。不同版本可能使用獨立的 HTTP、SOCKS 連接埠，也可能採用混合連接埠；請勿將舊教學中的連接埠視為固定預設值。以下以一組獨立連接埠示範，不代表目前版本的預設設定。
-
記下連接埠
記下本機 HTTP 或混合連接埠，以及 SOCKS 連接埠。若只有一個混合連接埠，兩項測試都使用同一連接埠；請勿填入訂閱節點的遠端伺服器連接埠。
-
啟動核心
在主畫面選取要測試的伺服器並設為目前使用的伺服器，確認記錄中沒有啟動失敗訊息。測試期間只使用一個節點與同一套路由規則。
-
確認監聽狀態
在 PowerShell 執行下方的監聽查詢。若查不到結果，先檢查核心是否成功啟動；若連接埠由其他程序占用，先處理占用問題，再檢查瀏覽器。
-
指定代理
使用
curl.exe明確指定代理，查看 HTTP 回應與錯誤訊息。在 Windows PowerShell 中直接輸入curl可能會呼叫別名，因此此處使用完整的程式名稱。
# 將連接埠替換為本機實際監聽的連接埠
Get-NetTCPConnection -State Listen -LocalPort 10809 |
Select-Object LocalAddress, LocalPort, OwningProcess
# HTTP 代理：HTTPS 請求會透過 CONNECT 通道傳輸
curl.exe --proxy http://127.0.0.1:10809 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/
# SOCKS5：由代理端解析目標網域名稱
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com/--noproxy "" 用來在這次明確指定代理的測試中清空略過代理清單。範例網址僅用於檢查連線流程，不代表特定地區一定能連線；進一步診斷時，請改用實際連線失敗的目標。若收到目標網站的 HTTP 狀態碼，代表已取得 HTTP 回應；即使狀態碼是 403 或 405，也不同於「無法連上本機代理」，但仍須搭配記錄確認流量是否經由遠端節點送出。
瀏覽器未走代理：檢查系統設定與擴充功能覆寫
若明確指定代理的測試成功，但瀏覽器仍不如預期，先確認瀏覽器使用系統代理，再檢查瀏覽器的代理擴充功能。Edge 和 Chrome 通常會採用 Windows 代理設定，但擴充功能、啟動參數與組織政策都可能改變行為。無痕視窗也不一定能排除擴充功能，因為部分擴充功能可在無痕模式中執行。
-
設定系統代理
在 v2rayN 系統匣圖示上按右鍵，選擇「系統代理」→「自動設定系統代理」。請勿選取「清除系統代理」，也不要將「不變更系統代理」誤認為會自動啟用代理。
-
確認系統代理位址
在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」，檢查「使用 Proxy 伺服器」中的位址與連接埠，確認對應 v2rayN 的 HTTP 或混合入站。記下原有的自動設定指令碼，避免兩套設定互相干擾。
-
暫停代理擴充功能
前往瀏覽器的擴充功能管理頁面，暫時停用代理切換擴充功能。檢查啟動捷徑是否附帶代理參數，關閉所有瀏覽器視窗後重新開啟，再前往相同的測試網址。
-
檢查瀏覽器獨立設定
在 Firefox 中前往「設定」→「一般」→「網路設定」→「設定」，選取「使用系統代理設定」。若選擇手動設定，則須分別確認 HTTP、SOCKS 與不使用代理的位址清單。
若只有特定網站直接連線，請檢查代理例外清單與 v2rayN 路由。例如瀏覽器將區域網路位址排除在代理之外，或規則將某個網域導向直連出站，都不代表系統代理開關失效。可暫時切換至全域代理路由模式進行比對，測試後再還原原有規則；請勿直接刪除整套路由設定。
- 所有瀏覽器都無法連線：優先確認系統代理連接埠、自動設定指令碼，以及是否有其他軟體反覆改寫設定。
- 只有一個瀏覽器無法連線：優先檢查該瀏覽器的擴充功能、獨立設定、啟動參數與管理政策。
- 網頁能開啟，但出口判定不同：比對目標網域的出站記錄；出口查詢網站只會反映連線至該網站的請求。
終端機未走代理：優先明確指定參數，再檢查環境變數
命令列工具不一定會讀取 Windows 系統代理。終端機本身也不是統一的網路用戶端：在同一個 PowerShell 中，curl.exe、指令碼執行環境和套件管理工具可能採用不同的代理來源。先測試實際使用的程式，再決定是否設定環境變數；不要因為瀏覽器能用，就認定終端機也已透過代理連線。
對 curl 而言，https_proxy 表示「連線至 HTTPS 目標時要使用哪個代理」，其值仍可設定為 http://127.0.0.1:10809。這裡的 http:// 描述本機代理協定，不代表目標網頁改用未加密連線。若誤寫成 https://127.0.0.1:10809，程式可能會對一般 HTTP 代理連接埠發起 TLS 交握，導致連線失敗。
# 先記下原本的值；以下設定只會影響目前的 PowerShell 與之後啟動的子程序
$oldHttpsProxy = $env:https_proxy
$oldNoProxy = $env:no_proxy
$env:https_proxy = "http://127.0.0.1:10809"
$env:no_proxy = "localhost,127.0.0.1"
# 不加 --proxy，確認該程式是否會讀取環境變數
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
# 測試完成後還原原本的值
if ($null -eq $oldHttpsProxy) {
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue
} else {
$env:https_proxy = $oldHttpsProxy
}
if ($null -eq $oldNoProxy) {
Remove-Item Env:no_proxy -ErrorAction SilentlyContinue
} else {
$env:no_proxy = $oldNoProxy
}請依序執行設定、測試與還原，不要一次執行整個程式碼區塊後才檢查變數。若還要代理 HTTP 目標，請依該工具文件檢查 http_proxy；curl 對此變數的大小寫有特定規則，跨平台指令碼建議使用小寫。ALL_PROXY 可作為 curl 的通用備援代理，但並非所有程式都支援，也不是所有工具都接受 SOCKS 位址。
| 設定方式 | 生效範圍 | 排查時留意 |
|---|---|---|
--proxy | 目前這次 curl 請求 | 適合建立可重複的診斷基準 |
$env:https_proxy | 目前的 PowerShell 與之後啟動的子程序 | 其他已執行中的終端機不會同步取得新值 |
NO_PROXY | 支援該變數的工具 | 目標網域或萬用字元規則可能使連線略過代理 |
| 工具本身的設定 | 個別程式或專案 | 可能覆蓋環境變數，須逐一檢查 |
若環境變數沒有作用，請回到程式本身的代理選項。PowerShell 的 Invoke-WebRequest 可使用 -Proxy http://127.0.0.1:10809 明確測試；不能只因 curl 成功，就認定它也會讀取相同的變數。WSL 和容器有各自獨立的網路環境，其中的 127.0.0.1 不一定指向 Windows 主機，請依網路模式確認主機位址與監聽範圍。
從實際錯誤判斷連接埠、TLS 或遠端逾時
保留失敗請求的完整錯誤訊息與發生時間，再比對 v2rayN 記錄。下方連接埠是本文的範例值，實際錯誤訊息會顯示你的連接埠與等待時間。請勿只截取「連線失敗」幾個字，也不要公開完整記錄，以免洩露訂閱連結或驗證資訊。
curl: (7) Failed to connect to 127.0.0.1 port 10809
原因：本機無法連上代理監聽連接埠，常見原因是核心未執行或連接埠填錯。解法：先檢查監聽記錄與所屬程序，再確認 HTTP 或混合入站設定；此時更換遠端節點通常無法解決本機連線問題。
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
原因：TLS 交握失敗，可能與代理協定設定錯誤、目標服務或本機安全軟體有關，不能只憑這項訊息判定節點失效。解法：先確認代理 URL 是否誤設為 HTTPS，再檢查系統時間並改用另一個目標比對；請勿關閉憑證驗證來掩蓋問題。
curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received
原因：請求在設定的時限內未收到資料，可能卡在遠端連線、DNS 或目標回應階段。解法：加上 -v 重試，確認代理連線與 CONNECT 是否已完成，再搭配核心記錄檢查目標網域與出站狀況。
使用 socks5h:// 測試成功，但需要在本機解析網域名稱的方式失敗，表示應優先檢查名稱解析路徑；這並不能直接證明某個公共 DNS 一定有問題。也請確認路由規則是否依賴網域解析，以及 DNS 請求是否送往預期的出站。
何時改用 TUN，何時繼續修復系統代理
若多個應用程式沒有代理設定、各自的環境變數難以管理，或確實需要接管更多 IP 流量，可以考慮使用 TUN。TUN 透過虛擬網路介面與路由接管流量，涵蓋範圍通常比系統代理廣；但能否正確接管，仍取決於核心、權限、路由、DNS 與應用程式行為，並非解決所有網路問題的萬用開關。
- 先修復系統代理：瀏覽器連接埠填錯、擴充功能強制直連、curl 參數設定錯誤。這些問題都有明確原因，不必改用其他流量接管方式。
- 考慮使用 TUN：多個應用程式不讀取系統代理，逐一設定代理的成本又太高。請先確認一般代理連線正常。
- 暫緩啟用：明確指定代理的請求仍失敗、遠端節點交握錯誤，或公司網路有強制政策。TUN 不會自動修復節點或驗證設定。
啟用前記下目前的系統代理與路由狀態，依 v2rayN 提示授予必要權限，再開啟介面中的 TUN 開關。測試期間先清除系統代理並還原終端機的暫存變數，避免應用程式同時經過明確指定的代理與 TUN，讓排查結果難以判讀。接著確認虛擬介面、預設路由與 DNS 是否已建立，再測試區域網路服務能否正常存取。
常見問題與最後檢查
瀏覽器能開啟網頁，為什麼終端機仍然逾時？
先執行本文的 curl.exe --proxy 測試。明確指定參數後成功、一般指令卻失敗時，優先檢查該工具是否會讀取環境變數，以及 NO_PROXY 是否包含目標位址。請勿先重新安裝用戶端。
結束 v2rayN 後網頁也無法開啟，該如何復原？
開啟 Windows「設定」→「網路和網際網路」→「Proxy」，確認設定是否仍指向已停止的本機連接埠。個人裝置可關閉這項手動代理；若原本使用公司代理或自動設定指令碼，請還原原有設定。
HTTP 和 SOCKS 應該填哪個連接埠？
依本機入站協定填寫，不要憑名稱猜測。瀏覽器的 HTTP 代理欄位填入 HTTP 或相容的混合連接埠；SOCKS 設定則填入 SOCKS 或相容的混合連接埠。遠端節點的 443 並非本機代理連接埠。
系統代理已開啟，但出口 IP 沒變，是不是沒有生效？
不一定。先確認出口查詢網站的網域是否符合直連規則，再比對核心的存取記錄；若尚未啟用存取記錄，請依目前核心支援的設定暫時開啟，診斷完成後再還原。只查看一個查詢網站的結果，無法推斷所有應用程式的連線路徑。
最後只需確認一條清楚的證據鏈：本機連接埠確實在監聽、明確指定代理後能收到回應、瀏覽器使用正確的代理來源、終端機程式讀取自己的代理參數，且路由記錄顯示預期的出站結果。依此順序逐層檢查，比反覆開關系統代理或接連更換節點更容易找出原因。若要重新整理訂閱、節點與啟動順序，可從站內的快速入門教學重新建立基準。