v2rayN 系統代理無效：瀏覽器略過代理與終端機代理設定排查

一、系統代理只是連線入口，不代表所有流量都會經過代理

v2rayN 的「設定系統代理」會將代理設定寫入作業系統，但應用程式是否讀取這些設定，取決於應用程式本身。瀏覽器可能依循系統設定，也可能受到擴充功能、啟動參數或企業政策影響；命令列工具通常有各自的代理參數與環境變數。瀏覽器能開啟某個網站，不代表終端機也已使用代理。

還要分清兩個決策：應用程式先決定是否連線至本機代理，核心再決定這條連線要走代理出站或直連出站。即使應用程式已連上 v2rayN，流量仍可能因路由分流規則而直接連線。VMess、VLESS 是遠端連線使用的協定設定，不會讓瀏覽器或終端機自動讀取系統代理。

• 應用程式略過代理：應用程式沒有連上本機監聽，請檢查系統設定、擴充功能、環境變數與略過清單。
• 路由直連：本機代理已收到請求，但規則選擇直連，請檢查目前的路由模式與規則順序。
• 出站連線失敗：請求已進入核心，但連不上遠端節點或目標服務，請改查節點、DNS、驗證與傳輸設定。

二、先用明確指定代理的請求確認本機入口

先記下 v2rayN 顯示的本機監聽位址、連接埠與協定。可在「設定」→「參數設定」中確認本機監聽相關設定，並以目前核心實際使用的設定為準；不同介面版面可能會讓欄位位置有所不同。下文以 127.0.0.1:10808 作為支援 HTTP 的本機入口範例，不代表所有安裝環境都使用這個預設值。若實際上只有 SOCKS 監聽，請改用對應的 SOCKS 測試指令。

在 Windows PowerShell 中使用 curl.exe，避免舊版 Windows PowerShell 將 curl 別名解讀為其他指令。macOS 與 Linux 則使用 curl。測試網址僅供示範，可換成需要診斷的實際 HTTPS 網站；不要用本機網址判斷對外代理是否正常。

# Windows PowerShell：HTTP 或混合監聽
curl.exe -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

# macOS / Linux：HTTP 或混合監聽
curl -v --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

# 僅在此連接埠支援 SOCKS5 時使用；由代理端解析目標網域
curl -v --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

--noproxy "" 會在這次測試中清空略過清單。詳細輸出應先顯示已連線至 127.0.0.1；透過 HTTP 代理存取 HTTPS 時，還會出現 CONNECT 通道協商。若收到目標網站的 HTTP 回應，表示請求至少已抵達服務回應階段；即使狀態碼不是 200，也不能直接判定為「系統代理無效」。

三、瀏覽器略過代理：逐項檢查是否有設定覆蓋

排查時請維持相同的目標網址與節點，不要同時切換節點、DNS 與路由。只憑「網頁能不能開」判斷過於粗略：頁面快取、既有連線，以及網站本身可直接連線，都可能掩蓋實際流量路徑。可比對請求發生時的核心連線紀錄，確認流量是否進入本機代理；若未啟用存取記錄，沒有紀錄並不能直接證明沒有發出請求。

1. 重新設定系統代理

   先在 v2rayN 系統匣選單的「系統代理」中選擇「清除系統代理」，再選「自動設定系統代理」。若目前版本將選單放在主視窗底部，請使用名稱相同的選項；接著確認系統儲存的位址與連接埠。

2. 暫停代理擴充功能

   在 Chrome 或 Edge 開啟「擴充功能」→「管理擴充功能」，暫時停用會修改代理設定的擴充功能。一般無痕視窗不一定會隔離所有代理設定，建議關閉所有瀏覽器程序，重新開啟後再測試。

3. 確認瀏覽器的代理來源

   在 Chrome 開啟「設定」→「系統」→「開啟電腦的代理設定」。在 Firefox 開啟「設定」→「一般」→「網路設定」→「設定」，確認使用系統代理，而非「不使用代理」或已過期的手動代理設定。

4. 檢查略過清單

   檢查系統代理例外、自動設定指令碼與瀏覽器規則。若清單包含目標網域、範圍過大的網域後綴或萬用字元，請先記錄原設定，再縮小範圍。內部網路與迴圈位址通常會被排除，不適合當作唯一測試目標。

5. 檢查政策覆寫

   在 Chrome 查看 chrome://policy，在 Edge 查看 edge://policy，確認是否有代理政策。受管理裝置上的強制設定應交由管理員處理，不要反覆修改已被政策覆寫的系統設定。

若只有某個瀏覽器異常，也請檢查其啟動捷徑是否帶有代理相關參數。瀏覽器的安全 DNS 設定並不是「啟用代理」的開關：它會影響部分網域解析方式，不能取代 HTTP 或 SOCKS 入口設定。先確認代理來源，再單獨排查 DNS 問題，避免同時變更兩種設定。

四、各平台如何查看目前的系統代理

請交叉比對系統設定介面與指令輸出。以下指令主要用於讀取設定，不會替你修改系統代理。重點確認伺服器位址、連接埠、啟用狀態、自動設定指令碼與例外清單，是否與 v2rayN 目前的入口一致。

Windows：分別查看目前使用者設定與 WinHTTP

# PowerShell：讀取目前使用者的代理設定
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# 查看另一組 WinHTTP 代理設定
netsh winhttp show proxy

ProxyEnable 為 1 代表已啟用靜態代理，仍須確認 ProxyServer 的實際內容。自動設定指令碼則是另一種設定方式。netsh winhttp show proxy 顯示直接連線，不代表瀏覽器沒有使用代理；WinHTTP 與目前使用者的 Internet 設定並非同一組設定，不要為了讓兩者輸出一致而盲目匯入設定。

macOS：讀取目前生效的代理設定

scutil --proxy

請檢查 HTTPEnable、HTTPSEnable 及其伺服器、連接埠欄位，也要留意 ProxyAutoConfigEnable 與例外清單。切換 Wi-Fi、有線網路或其他網路服務後，請重新讀取設定；舊網路服務上的代理設定不代表目前連線正在使用。

Linux GNOME：讀取桌面代理設定

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy.http host
gsettings get org.gnome.system.proxy.http port
gsettings get org.gnome.system.proxy.https host
gsettings get org.gnome.system.proxy.https port
gsettings get org.gnome.system.proxy ignore-hosts

這些指令適用於具備相應設定架構的 GNOME 工作階段，並非所有 Linux 環境都能通用。SSH 工作階段、容器與背景服務通常不會直接繼承桌面代理設定；即使桌面設定正確，仍須檢查命令列程式本身的環境設定。

五、個別設定終端機的 http_proxy 與 https_proxy

終端機視窗不會統一管理代理，真正讀取設定的是在其中執行的程式。curl、套件管理工具與開發工具支援的設定方式可能不同。先用 curl 進行可控測試，再查看特定工具的代理選項；不能因為某個工具成功，就認定整個終端機都已使用代理。

macOS / Linux：查看與暫時設定

# 查看大小寫兩種變數與略過清單
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 僅設定目前 shell 及其後續子程序
export http_proxy=http://127.0.0.1:10808
export https_proxy=http://127.0.0.1:10808

# 清空這次測試的略過清單，測試完成後還原原設定
curl -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o /dev/null

https_proxy 中的 https 指的是目標 URL 使用的協定，不代表變數值也必須以 https:// 開頭。常見的本機 HTTP 代理使用 http://127.0.0.1:10808，並透過 CONNECT 存取 HTTPS 目標。只有代理入口本身支援 TLS 時，才使用 HTTPS 代理位址。

• http_proxy：為 HTTP 目標提供代理。curl 的這個變數只接受小寫形式，不應只設定大寫的 HTTP_PROXY。
• https_proxy：為 HTTPS 目標提供代理。其他程式對大小寫的處理方式可能不同，請查閱相應工具的文件。
• all_proxy：部分工具會將它作為通用的備用代理，也可設定 SOCKS 位址。通常協定專用變數的優先度較高，請勿同時保留互相衝突的值。
• no_proxy：指定略過代理的目標清單。對 curl 而言，值為 * 會讓所有目標都略過代理，是「已設定變數卻仍直接連線」時的重要檢查項目。

Windows PowerShell：設定目前程序的環境變數

# 查看目前程序中的代理環境變數
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# 設定目前 PowerShell 與之後啟動的子程序
$env:http_proxy = 'http://127.0.0.1:10808'
$env:https_proxy = 'http://127.0.0.1:10808'

curl.exe -v --noproxy "" --connect-timeout 5 --max-time 15 https://example.com/ -o NUL

上述設定不會回頭修改已啟動的程式，也不會自動套用到新開啟的其他終端機。若要長期使用，再考慮設定使用者環境變數或 shell 設定檔；透過 setx 寫入的值主要供之後啟動的程序讀取，不會立即變更目前的 PowerShell。尚未完成驗證前，請勿將錯誤的連接埠永久存入設定。

六、常見錯誤訊息對應的排查層級

以下列出 curl 常見錯誤訊息範例；實際位址與輸出文字會因系統和版本而異。請優先處理最先失敗的環節：本機連接埠尚未連上時，調整遠端協定沒有幫助；若已收到目標端的 TLS 錯誤，也不能再將問題歸因於「未設定系統代理」。

若出現憑證驗證錯誤，請勿長期關閉驗證來取代排查。請檢查系統時間、憑證信任鏈，以及網路中的 HTTPS 檢查設備；若代理通道已建立但 TLS 失敗，問題層級就與「終端機完全沒有讀取代理變數」不同。

七、依據比對結果決定下一步，不要直接啟用 TUN

TUN 會透過虛擬網路介面接管流量，適合處理不遵循系統代理設定的應用程式，但也會增加權限、路由與 DNS 等排查項目。它不是驗證系統代理的必要條件。明確指定代理尚未連通前就啟用 TUN，往往只會增加變數；應先確認本機入口與遠端出站都能正常連線。