瀏覽器可以連線，不代表終端機也已使用代理。本文以 Windows 上的 v2rayN 為例，先確認實際監聽的連接埠，再透過指定代理的請求隔離問題，最後分別調整瀏覽器設定與終端機環境變數。適合網頁瀏覽正常、命令列逾時，或開啟系統代理仍無效的情況；排查前不必急著重新安裝用戶端或反覆更換訂閱。
一、系統代理與終端機代理是兩種不同入口
v2rayN 的系統代理功能，主要是將本機代理位址寫入作業系統設定，讓會讀取這些設定的應用程式使用。這不代表本機所有網路連線都會被接管。瀏覽器可能讀取系統設定，也可能受擴充功能或企業政策覆蓋；命令列工具則可能只讀取環境變數、自身設定檔或啟動參數。
在這條連線路徑中，系統代理只是協助應用程式找到入口。請求進入核心後，仍須依路由規則決定直連、代理或阻擋。因此，「用戶端收到請求」和「請求經由遠端節點送出」是兩回事。瀏覽器連線成功可能是因為套用了直連規則，不能單憑這點判定節點可用。
- 系統代理：提供代理位址給支援此設定的應用程式，不保證所有終端機工具都會自動採用。
- 本機入站：由核心監聽的 HTTP、SOCKS 或混合協定入口，位址與協定必須相符。
- 路由分流：決定請求進入核心後的對外連線方式，不會讓原本直連的應用程式自動改走代理。
- TUN 模式：這是另一種流量接入方式。本次先將它關閉以隔離測試，避免與系統代理疊加而難以判斷入口；測試結束後再還原原設定。
二、先確認 10808 與 10809，不要照舊教學設定
部分舊設定使用 10808 作為 SOCKS 入口、10809 作為 HTTP 入口；其他設定可能只在 10808 提供混合入口。連接埠號碼本身不代表協定，升級、遷移或手動修改後也可能有所不同。請在 v2rayN「設定」→「參數設定」中確認本機監聽項目，再查看啟動記錄確認實際生效值；不同介面的項目名稱可能略有差異。
以下 PowerShell 指令只會檢查這兩個範例連接埠，不會修改設定。若實際連接埠不同，請相應替換。輸出中的 OwningProcess 是監聽程序的識別碼，可再用 Get-Process -Id 進程編號 確認程序；實際負責監聽的通常是核心程序，不一定是介面程序。
Get-NetTCPConnection -State Listen |
Where-Object { $_.LocalPort -in 10808,10809 } |
Select-Object LocalAddress,LocalPort,OwningProcess| 檢查結果 | 可能代表 | 下一步 |
|---|---|---|
| 兩個連接埠都沒有監聽 | 核心未執行，或使用了其他連接埠 | 查看啟動記錄與實際參數，先不要修改終端機變數 |
| 只有 10808 正在監聽 | 可能是單一協定入口，也可能是混合入口 | 確認入站類型，再選擇 HTTP 或 SOCKS 進行測試 |
| 監聽程序不是目前的核心 | 連接埠被其他程式或殘留程序占用 | 確認程序用途後再處理，不要任意結束程序 |
| 只監聽 IPv6 回送位址 | 與明確指定的 IPv4 位址不相符 | 確認監聽位址，或改用相符的 IPv6 回送位址測試 |
三、透過指定代理的請求隔離終端機問題
先略過環境變數，直接在指令中指定代理位址。在 Windows PowerShell 中建議明確呼叫 curl.exe，避免某些環境中的 curl 別名實際呼叫其他指令。先執行 curl.exe --version 確認工具已安裝；以下目標位址僅用來示範測試方式，也可改成瀏覽器正在排查的同一個公開 HTTPS 位址，避免兩次測試套用不同路由。
# 僅在確認 10809 是 HTTP 入口後執行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:10809 https://example.com/ -o NUL
# 僅在確認 10808 支援 SOCKS5 後執行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy socks5h://127.0.0.1:10808 https://example.com/ -o NUL--noproxy "" 可在本次測試中清除略過代理清單，避免既有的 NO_PROXY 讓請求意外直連。若實際的 HTTP 混合入口是 10808，請將第一個指令的連接埠改為 10808，不要直接照抄 10809。socks5h 代表由 SOCKS 代理端解析目標網域；socks5 則通常由本機先行解析，兩者的解析路徑不同。
- 先確認本機連線。詳細輸出應顯示正在連線至指定的回送位址與連接埠，而非直接連到目標公網位址。
- 再確認代理交涉。透過 HTTP 代理連線至 HTTPS 網站時，通常會出現 CONNECT 通道交涉；SOCKS 則應顯示相應的連線過程。
- 最後確認回應。收到 HTTP 狀態碼表示至少已收到伺服器回應；403 等回應不能直接歸因於本機連接埠故障，也不代表目標服務可正常使用。
- 同步查看核心記錄。確認同一時間的目標網域與對外連線選擇。只有記錄明確顯示對外連線時，才能進一步判斷是否經由預期節點送出。
指定代理的測試成功、一般命令卻失敗時，優先檢查工具讀取代理設定的方式。若指定代理也失敗，應先檢查本機入口、節點連線與路由，不要繼續疊加環境變數。每次測試只變更一項條件，並記下指令、時間與結果；這比只記錄「網頁無法開啟」更容易重現問題。
四、檢查瀏覽器的系統代理、擴充功能與略過規則
在 v2rayN 系統匣選單中確認「系統代理」狀態。選擇「自動設定系統代理」通常表示由用戶端寫入目前的代理設定，不代表某個 PAC 檔案已生效；「清除系統代理」則會撤銷相關設定。「不改變系統代理」只表示不主動修改，並不代表系統原有的代理已關閉。
- 在 Windows「設定」→「網路和網際網路」→「Proxy」中，確認手動代理位址與連接埠是否符合目前的 HTTP 或混合入口，並檢查是否啟用了設定指令碼。
- 暫時停用會接管代理設定的瀏覽器擴充功能。若擴充功能仍指向舊連接埠，即使系統設定正確，也可能完全不會採用。
- 確認瀏覽器是否另行設定手動代理。在 Firefox 中，可前往「設定」→「一般」→「網路設定」→「設定」，確認是否使用系統代理；由組織管理的瀏覽器也須檢查政策限制。
- 關閉後重新開啟瀏覽器，使用相同目標位址再次測試，同時觀察核心記錄是否出現新請求。既有連線或快取頁面不能證明新設定已生效。
如果瀏覽器只有在啟用某個擴充功能時才能連線，先記下擴充功能實際使用的協定與連接埠，再與系統設定比對。這通常表示兩者使用不同入口，而不是系統代理按鈕本身失效。若瀏覽器與命令列測試的網域不同，也應先統一測試目標，再比較對外連線結果。
五、終端機環境變數須符合工具支援範圍
許多終端機工具會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，但各工具支援的變數、優先順序與設定檔規則並不完全相同。先確認目前程序能讀取哪些值，不要直接修改全域環境。以下 PowerShell 指令只會讀取設定；若輸出包含使用者名稱、密碼或內部位址，分享前請先刪除敏感資訊。
Get-ChildItem Env: |
Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }以下是目前 PowerShell 工作階段的設定範例，前提仍是已確認 10809 支援 HTTP 代理。若這些變數目前已有設定，請先記下原值，測試後再還原。Windows 環境變數名稱通常不區分大小寫；其他 shell 則須留意大小寫差異，例如 curl 使用小寫的 http_proxy 作為 HTTP 代理變數。
$env:http_proxy = 'http://127.0.0.1:10809'
$env:https_proxy = 'http://127.0.0.1:10809'
curl.exe -v --connect-timeout 10 --max-time 30 https://example.com/ -o NULhttps_proxy 的值仍可使用 http://：此處的協定指的是「工具如何連線至代理」，而非目標網頁使用的協定。連線至 HTTPS 網站時，工具可透過一般 HTTP 代理建立 CONNECT 通道，再於通道內與目標建立 TLS 連線。若照字面改成 https://127.0.0.1:10809，工具可能會嘗試與不支援 TLS 的本機代理進行交握。
- NO_PROXY：若其中包含目標網域、網域後綴或
*，請求可能會略過代理。請先保存原值，再進行針對性測試；不要永久刪除必要的內網例外。 - ALL_PROXY：部分工具會將它作為通用代理入口；若已設定舊值，可能影響判斷，實際優先順序請參考工具文件。
- 子程序繼承：從目前終端機啟動的程式通常會繼承目前環境；已開啟的編輯器整合終端機未必會取得之後修改的系統變數。
- 獨立執行環境：WSL 與容器各有自己的網路環境。其中的
127.0.0.1不一定指向 Windows 主機，請依實際網路模式驗證，不要直接套用本機位址。
如果測試前沒有設定變數，可用以下指令清除本次工作階段的設定；若原本已有值，應還原原值，而非直接刪除。關閉 PowerShell 視窗也會結束工作階段層級的修改。確認設定有效後再考慮長期套用，並分別查閱實際命令列工具的代理參數，避免全域變數影響其他工作。
Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue六、依錯誤階段定位，不要把所有逾時都歸咎於節點
以下保留 curl 常見的錯誤關鍵片段；完整訊息中的位址、耗時與 TLS 後端提示會依環境而異。先判斷錯誤發生在連線至本機入口、代理交涉，還是連線至目標的階段，再決定要修改哪項設定。
錯誤：curl: (7) Failed to connect to 127.0.0.1 port 10809
原因：本機 TCP 連線未能建立，常見原因是連接埠未監聽或位址不相符。解法：透過監聽查詢確認目前核心與實際連接埠，再重新測試指定代理的請求；先不要更換遠端節點。
錯誤：curl: (5) Could not resolve proxy
原因：無法解析代理伺服器名稱，可能是變數中的主機名稱有誤或混入多餘字元。解法：檢查環境變數完整內容，並使用已確認的回送位址進行指定代理測試，以區分代理位址解析與目標網域解析。
錯誤：curl: (28) Connection timed out
原因：某個連線階段超過時間限制，僅憑這行訊息無法判定是節點、DNS 或目標服務的問題。解法：搭配 -v 確認最後完成的步驟及同一時間的核心記錄，先確認本機連線是否建立，再檢查後續對外連線。
錯誤：curl: (35) SSL connect error
原因：TLS 連線建立失敗，可能與協定設定錯誤、中間設備或目標端交涉有關。解法：先確認本機代理 URL 使用的協定，再檢查系統時間與完整 TLS 訊息；不要將關閉憑證驗證當成一般修復方式。
暫時提高記錄詳細程度有助於區分路由與連線階段，但記錄可能包含瀏覽過的網域及節點位址。排查後請還原原記錄層級；分享時只保留必要片段，並遮蔽訂閱位址、驗證資訊與個人瀏覽記錄。
七、常見問題與還原檢查
瀏覽器正常，curl 指定代理後也正常，為什麼一般命令仍然失敗？
入口與基本連線已確認正常，接下來檢查該工具是否會讀取環境變數、是否設有自己的代理設定，以及目標是否符合 NO_PROXY。請先在同一個終端機執行測試，再從該終端機啟動實際工具，避免環境繼承方式不同。
修改連接埠後，為什麼瀏覽器恢復正常，終端機卻仍連到舊連接埠？
系統代理與終端機變數是獨立設定。請重新檢查目前終端機的代理變數，並將連接埠更新為實際值；若工具使用設定檔，也須修改對應項目。已在執行中的常駐程序可能需要重新啟動。
有 10808 就一定得再開啟 10809 嗎？
不一定。若 10808 已是混合入口，HTTP 與 SOCKS 用戶端可以依各自的協定連線至同一連接埠。先確認目前入站支援的協定再進行測試，不要為了符合舊教學而重複新增監聽項目。
用戶端退出後，網頁反而都無法開啟，該怎麼辦？
前往 Windows「設定」→「網路和網際網路」→「Proxy」，確認是否仍指向已停止的本機連接埠，並清除不再使用的代理設定。終端機也要還原測試前的變數，瀏覽器擴充功能則應恢復至預期狀態。
最後確認三項結果：指定代理的請求能連上正確的本機入口；瀏覽器與終端機分別採用預期的代理設定；核心記錄中的路由與對外連線符合預期。確認這三點，才能區分「系統代理設定成功」、「應用程式確實使用代理」與「請求選擇了預期的對外連線」，避免下次遇到問題又從重新安裝開始。
- 記下實際監聽位址、連接埠與協定，並保留一條可重複執行的測試指令。
- 還原排查期間停用的擴充功能、修改的環境變數與暫時調整的記錄層級，只保留已確認有效的設定。
- 若仍無法排除問題，請整理工具名稱、完整指令、錯誤發生階段與已遮蔽敏感資訊的記錄，再沿著同一條連線路徑繼續排查。