故障排查 預計閱讀 12 分鐘

系統代理無法生效排查：瀏覽器可走代理、終端機卻不行的原因與驗證

系統代理只是環境變數與設定項目，瀏覽器會遵循，終端機指令卻不一定會讀取。本文分兩條路徑提供驗證指令與修復方法，並說明何時應改用 TUN 模式接管全域流量。

先區分系統代理與實際流量路徑

Clash 用戶端中的「系統代理」通常不是一條涵蓋所有程式的全域通道。它的作用是將作業系統的 HTTP 與 HTTPS 代理位址設為 127.0.0.1，連接埠指向 Clash 正在監聽的本機連接埠。瀏覽器讀取這項設定後，會將請求交給 Clash；終端機程式是否讀取，則取決於程式本身、啟動環境與代理協定。

常見預設值為 HTTP 連接埠 7890、SOCKS5 連接埠 7891，也可能由 mixed-port: 7890 同時接收 HTTP 與 SOCKS5。連接埠並非固定規範，設定檔、用戶端版本或使用者覆寫都可能修改它。排查前應以用戶端「設定」→「連接埠設定」或目前設定中的欄位為準。

mixed-port: 7890
allow-lan: false
mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip

當網頁可以開啟，而 curl、git、npm 或某個命令列下載工具仍然直接連線時，通常不是節點整體失效。更準確的判斷是：瀏覽器路徑已進入 Clash，但終端機路徑沒有進入，或終端機進入後採用了不同的 DNS、協定與規則。

第一條路徑：瀏覽器如何讀取系統代理

確認 Clash 本機連接埠正在監聽

系統代理指向未監聽的連接埠時，瀏覽器通常會顯示連線被拒絕。Windows PowerShell 可檢查 7890，macOS 與 Linux 則可查看對應程序。若實際連接埠不是 7890，應替換指令中的數字。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

預期結果應包含本機監聽位址，例如 127.0.0.1:7890 或 0.0.0.0:7890。沒有結果時，返回用戶端檢查設定是否已啟動、代理開關是否開啟，以及連接埠是否被其他程式佔用。若發生連接埠衝突，可暫時改為 7897，再同步更新系統代理與終端機變數。

檢查作業系統代理位址

  • Windows 11：進入「設定」→「網路和網際網路」→「代理」→「手動設定代理」。位址應為 127.0.0.1，連接埠應與 Clash 的 HTTP 或 mixed 連接埠一致。
  • macOS：進入「系統設定」→「網路」→目前的網路介面→「詳細資訊」→「代理伺服器」。檢查網頁代理 HTTP 與安全網頁代理 HTTPS。
  • Firefox：進入「設定」→「一般」→「網路設定」。若選用「手動代理伺服器設定」，它會覆蓋系統代理；希望跟隨作業系統時，應選擇「使用系統代理設定」。
  • Chrome 與 Edge 通常會讀取作業系統代理，但擴充功能、企業原則與瀏覽器啟動參數仍可能改寫這條路徑。

瀏覽器驗證應同時查看頁面結果與 Clash 連線紀錄。開啟一個先前未造訪的網站，然後在用戶端的連線頁面依網域篩選。若能看到目標網域、命中的規則與出口節點，表示請求已進入核心。只看網頁能否開啟，無法區分代理存取、快取命中與直接連線。

檢查規則是否讓瀏覽器直接連線

開啟系統代理只代表流量進入 Clash，不代表一定會使用代理節點。在 mode: rule 下，請求還要經過規則比對。若連線紀錄顯示 DIRECT，應檢查網域規則、規則集與最終規則。暫時切換至全域模式可用於對照，但驗證完成後應恢復規則模式。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

如果全域模式可用、規則模式不可用，問題集中在規則順序、策略群組選擇或訂閱產生的內容，而不是系統代理開關。Clash 會由上至下比對規則，命中第一條後便停止。寬泛的 DIRECT 規則若放在前面，可能會提前攔截後續網域規則。

第二條路徑：終端機程式為何沒有跟隨

終端機視窗本身不會自動轉送網路。真正發起請求的是 curl、Git、Node.js、Python 套件管理器或其他指令。每個程式都有自己的代理讀取邏輯。部分程式讀取 HTTP_PROXY 與 HTTPS_PROXY，部分讀取小寫變數，部分只接受指令參數，另有一些使用獨立設定檔。

使用 curl 明確指定代理進行基準測試

先繞過環境變數，直接讓 curl 連線至 Clash 的 HTTP 連接埠。這一步可以區分「終端機未讀取系統設定」與「Clash 本機代理無法使用」。

curl -v -x http://127.0.0.1:7890 https://api.ipify.org

curl -v --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://www.example.com/

輸出中應先出現連線至 127.0.0.1:7890，接著出現 HTTPS 的 CONNECT 過程。若明確指定代理時成功，而不帶 -x 時失敗，節點、連接埠與 Clash 核心基本正常，後續只需處理終端機設定。

SOCKS5 測試可使用 socks5h。結尾的 h 表示將網域解析交由代理端處理，適合用來排除本機 DNS 解析異常。若使用 socks5，網域通常會先在本機解析，再將 IP 交給代理。

curl -v --proxy socks5h://127.0.0.1:7891 \
  https://api.ipify.org

為目前終端機設定環境變數

macOS、Linux、Git Bash 與多數類 Unix shell 可在目前工作階段匯出變數。建議同時設定大寫與小寫形式，以相容於讀取規則不同的工具。關閉終端機視窗後，這組暫時變數就會失效。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

curl -v https://api.ipify.org

PowerShell 可寫入目前程序的環境。執行後只會影響該 PowerShell 視窗及由它啟動的子程序，不會自動修改已開啟的編輯器或其他終端機。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:NO_PROXY="localhost,127.0.0.1,::1"

curl.exe -v https://api.ipify.org

驗證完成後應清除測試變數，避免 Clash 結束後程式仍繼續存取失效的本機連接埠。

# bash / zsh
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY

# PowerShell
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:NO_PROXY

Git、npm 與 Python 的獨立設定

環境變數適合用於一次性排查。長期使用時，還要確認工具是否儲存過舊連接埠。Git 可分別讀取全域設定與儲存庫設定；儲存庫內的局部設定優先順序較高。

git config --global --get http.proxy
git config --global --get https.proxy
git config --local --get http.proxy

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

# 刪除全域代理
git config --global --unset http.proxy
git config --global --unset https.proxy

npm 可使用 npm config get proxy 與 npm config get https-proxy 進行檢查。值顯示為 null 時，npm 才可能繼續參考環境變數。若舊設定仍指向 127.0.0.1:7897，即使系統代理已改為 7890，npm 仍會連線至舊連接埠。

npm config get proxy
npm config get https-proxy

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm config delete proxy
npm config delete https-proxy

Python 的 pip 可讀取環境變數，也可透過指令參數進行測試。僅為單次安裝加入代理時，使用參數比永久寫入設定更容易還原。

python -m pip install --proxy http://127.0.0.1:7890 package-name

python -m pip config list
python -m pip config debug

DNS、IPv6 與 UDP：進入代理後仍可能失敗

區分解析失敗與連線失敗

終端機錯誤中的關鍵字可以縮小範圍。Could not resolve host 指向網域解析階段；Connection refused 通常表示本機代理連接埠未監聽；Operation timed out 可能是節點鏈路、規則出口、防火牆或目標網站回應逾時；TLS 憑證錯誤則需要檢查系統時間、憑證儲存區與程式使用的 TLS 後端。

使用 HTTP 代理存取 HTTPS 網站時，客戶端通常會先向代理傳送 CONNECT。使用 SOCKS5 時，socks5h 與 socks5 的解析位置不同。若一般 socks5 失敗而 socks5h 成功，應優先檢查本機 DNS，不要直接更換訂閱。

檢查 IPv4 與 IPv6 結果

部分終端機程式會優先連線 IPv6，但目前網路的 IPv6 路由並不完整。可分別執行 curl -4 與 curl -6 進行比較。若 IPv4 在 2 秒內回應、IPv6 卻在 10 秒後逾時，問題位於 IPv6 路徑，而不是 HTTP 代理變數。

curl -4 -I --connect-timeout 10 https://www.example.com/
curl -6 -I --connect-timeout 10 https://www.example.com/

curl -4 -I -x http://127.0.0.1:7890 https://www.example.com/
curl -6 -I -x http://127.0.0.1:7890 https://www.example.com/

還要注意，傳統 HTTP 系統代理主要處理 TCP 上的 HTTP 與 HTTPS。基於 UDP 的 QUIC、遊戲流量、語音應用程式與自訂協定不一定會經過這個入口。瀏覽器可能在代理環境下退回 TCP，但其他應用程式未必採用相同的退回方式，因此會出現網頁正常、特定應用程式逾時的差異。

何時改用 TUN 模式

TUN 模式透過虛擬網路介面與系統路由接管更多 IP 流量。它不要求每個應用程式理解 HTTP 代理，也不依賴程式讀取 HTTP_PROXY。當需要涵蓋多個終端機工具、UDP 應用程式、無法設定代理的軟體，或希望減少逐項維護代理變數時，TUN 通常比系統代理更合適。

適合切換至 TUN 的情境

  • 瀏覽器穩定進入 Clash，但多個命令列工具都忽略系統代理。
  • 應用程式使用自訂 TCP 或 UDP 協定，沒有 HTTP、HTTPS 或 SOCKS5 代理設定。
  • 開發環境包含容器、套件管理器與背景程序，逐一設定環境變數的成本較高。
  • 需要讓 DNS 查詢與連線流量遵循同一套規則，減少本機解析路徑差異。
  • 關閉系統代理後，仍希望由規則決定 DIRECT、代理群組與最終出口。

mihomo 核心的常見設定包含 tun.enable、stack、自動路由與 DNS 劫持。實際可用值取決於用戶端封裝的核心版本與作業系統權限。修改前應保留目前可正常運作的 Profile，並透過用戶端提供的設定入口啟用，不要同時手動建立第二套路由。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

tun.enable: true · stack: mixed · auto-route: true

啟用後先關閉系統代理進行一次對照測試，避免同一個請求先進入系統代理，再被 TUN 路由重複接管。多數核心會處理這種組合，但在排障階段保留單一路徑更容易判斷。接著分別測試瀏覽器、curl、Git 與目標應用程式，並在連線紀錄中確認命中的規則。

Android 上的系統代理與 VPN 路徑

Android 用戶端通常會透過系統 VpnService 建立本機 VPN 介面，而不是依賴桌面系統常見的 HTTP 代理設定。首次啟動時出現的連線請求屬於 Android 系統授權。確認後，應用程式才能建立 VPN 介面，並接收被路由至該介面的流量。

如果 Android 瀏覽器可以使用，但 Termux 中的指令無法使用，先檢查用戶端是否啟用了按應用程式代理、繞過應用程式或僅代理選取的應用程式。實際選單名稱會因用戶端而異，常見入口為「設定」→「網路」→「存取控制」或「設定」→「參數設定」→「按應用程式代理」。若 Termux 未包含在代理應用程式清單中，其流量可能直接經由實體網路傳送。

  • 在連線紀錄中搜尋 Termux 請求的目標網域。
  • 檢查存取控制目前採用的是「僅代理選取的應用程式」還是「繞過選取的應用程式」。
  • 暫時關閉私人 DNS 進行短時間對照，再恢復原設定並記錄結果。
  • 確認省電策略沒有在螢幕熄滅後終止 VPN 服務。
  • 檢查目前 Profile 的 DNS、TUN 與規則群組是否實際生效。

Termux 仍可使用 export HTTPS_PROXY=http://127.0.0.1:連接埠，但此處的回送位址與連接埠必須確實由 Android 用戶端開放給本機應用程式。若用戶端主要透過 VPN 介面運作，並未開放本機 HTTP 監聽，設定這個變數不會產生有效連線。此時應優先修正 VPN 的應用程式範圍，而不是照搬桌面端連接埠。

依序執行的最終檢查清單

  1. 在 Clash 用戶端確認 Profile 已啟動，策略群組已選取可用節點。
  2. 讀取目前的 mixed-port、port 或 socks-port，不要假定一定是 7890。
  3. 使用監聽指令確認本機連接埠存在，並排除連接埠衝突。
  4. 在瀏覽器開啟新頁面，同時查看 Clash 連線紀錄與命中的規則。
  5. 執行帶有 -x 的 curl，建立明確代理基準。
  6. 明確代理成功後，再設定目前終端機的代理環境變數。
  7. 檢查 Git、npm、pip 等工具儲存的獨立代理設定與舊連接埠。
  8. 使用 socks5h、-4 與 -6 區分 DNS 與 IP 路徑。
  9. 需要接管非 HTTP、UDP 或大量背景程式時，切換至 TUN 進行單一路徑驗證。
  10. 驗證完成後清除暫時變數，恢復規則模式與原有 DNS 設定。

最關鍵的判斷不是「代理開關是否亮起」，而是請求實際經過哪一條路徑。瀏覽器路徑要看系統代理與規則，終端機路徑要看程式參數、環境變數與獨立設定，複雜應用程式的路徑則要看 TUN、路由與 DNS。依照監聽連接埠、明確代理、環境變數、工具設定、TUN 的順序檢查，通常可以在不變更訂閱的前提下找出問題。

用戶端與排查入口

選擇對應平台的 Clash 用戶端，或繼續查看首次設定、系統授權與連線步驟。

前往下載頁 查看教學
下載Clash