開啟代理後瀏覽器能用、終端機卻不行？系統代理未生效的分情境排查指南

先釐清故障發生在哪一層

Clash、Clash Meta（mihomo）以及基於這些核心製作的桌面客戶端，通常會在本機監聽 HTTP、SOCKS5 或 mixed 代理連接埠。客戶端中的「系統代理」開關，只負責將作業系統的代理位址改為類似 127.0.0.1:7890 的本機監聽位址。應用程式是否讀取這項設定、請求是否進入核心，以及規則最後選擇哪個策略，是三個彼此獨立的環節。

因此，「系統代理已開啟」不代表所有程式都會自動經過 Clash。Chrome、Edge 等瀏覽器通常會遵循系統代理；Firefox 可以使用自己的代理設定；curl、Git、npm、Python 套件管理器與遠端終端機則常會讀取環境變數或各自的設定檔。遊戲、UDP 程式及部分商店應用程式也可能繞過傳統 HTTP 系統代理，需要以 TUN 模式接管。

用四種結果快速判斷問題範圍

測試結果	較可能的問題	優先檢查
瀏覽器可用，終端機不可用	終端機未讀取系統代理	環境變數、Git/npm 個別設定
瀏覽器與終端機都不可用	連接埠、核心、設定或節點異常	監聽連接埠、執行記錄、策略群組
明確指定代理可用，系統代理不可用	系統代理寫入失敗或遭到覆寫	作業系統設定、瀏覽器原則、擴充功能
網頁可用，遊戲或 UDP 不可用	系統代理涵蓋範圍不足	TUN、DNS、路由與防火牆

第一步：確認 Clash 實際監聽的連接埠

不同客戶端的預設連接埠不完全相同。常見設定為 HTTP 或 mixed 連接埠 7890、SOCKS5 連接埠 7891，以及外部控制連接埠 9090。其中 9090 用於控制面板呼叫 API，不是網頁代理連接埠；將系統代理指向它會直接失敗。最終仍應以客戶端目前的設定與設定檔為準，不能只根據常見數字猜測。

在具有圖形介面的客戶端中，先進入「設定」→「參數設定」或「設定」→「網路設定」，查看 HTTP、SOCKS 與 Mixed Port。若設定只有 mixed-port: 7890，HTTP 與 SOCKS5 都可連線至 7890；若分別設定了 port 與 socks-port，呼叫時就必須配合相應的協定。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

直接測試本機 HTTP 代理

在終端機中明確指定代理，可以繞過系統代理設定，單獨確認 Clash 連接埠是否正常。以下指令會存取標準測試頁面，正常情況下會回傳 HTTP 回應標頭；加入 -v 後，還能確認是否連線至 127.0.0.1:7890。

curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

curl -v -x http://127.0.0.1:7890 https://example.com/

如果明確指定代理時成功，而不帶 -x 的指令失敗，表示核心、節點與連接埠基本正常，問題集中在系統代理或終端機設定。若明確指定代理也出現 Connection refused，通常是連接埠填寫錯誤、核心尚未啟動，或本機安全軟體阻止監聽。若能連線至本機連接埠，後續卻看到 timeout，則繼續檢查節點、規則與 DNS。

檢查連接埠是否正在監聽

# Windows
netstat -ano | findstr :7890

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

# Linux
ss -lntp | grep 7890

輸出中應出現本機監聽位址。僅供本機使用時，監聽 127.0.0.1:7890 屬於正常情況；只有需要讓區域網路中的其他裝置連線時，才需啟用 allow-lan 並檢查防火牆。不要為了修復本機瀏覽器問題而任意開放區域網路監聽。

瀏覽器未經代理：檢查覆寫設定與代理來源

Chrome 與 Edge 在 Windows、macOS 上通常會讀取系統代理，但擴充功能、企業原則、啟動參數與安全軟體都可能覆寫設定。Firefox 則有獨立的網路設定，可選擇「不使用代理伺服器」、「使用系統代理設定」或「手動代理設定」。不同瀏覽器的結果不一致，往往正是因為代理設定來源不同。

Chrome 與 Edge 的檢查順序

完全結束瀏覽器後再重新開啟，避免舊的連線池持續重用直連連線。
進入瀏覽器「設定」→「系統和效能」→「開啟電腦的代理設定」，確認位址為 127.0.0.1，連接埠與 Clash 一致。
暫時停用會管理代理的擴充功能，尤其是能切換 PAC、固定代理或情境模式的擴充功能。
檢查捷徑或啟動指令碼中是否存在 --proxy-server、--no-proxy-server 等參數。
開啟 Clash 連線清單或即時記錄，再重新整理網頁，確認是否出現目標網域。

如果瀏覽器記錄中完全沒有新的連線，表示請求尚未進入 Clash，應繼續排查系統代理或瀏覽器覆寫設定。如果能看到連線，但策略顯示 DIRECT，表示系統代理已生效，只是目前規則讓該網域直接連線。此時應檢查規則命中結果，而不是反覆切換系統代理。

Firefox 使用自己的代理設定

Firefox 可進入「設定」→「一般」→「網路設定」→「設定」。若希望遵循 Clash 的系統代理，請選擇「使用系統代理設定」；若選擇「手動代理設定」，可將 HTTP 代理設為 127.0.0.1、連接埠設為 7890，並依實際連接埠填寫 SOCKS 主機。使用 SOCKS5 時，若希望網域解析也透過代理端處理，還要確認「使用 SOCKS v5 時代理 DNS 查詢」選項。

終端機未經代理：設定環境變數，而不是只開啟系統代理

macOS 與 Linux 的終端機程式普遍不會統一繼承桌面系統代理。Windows 下也要區分 PowerShell 指令、curl.exe、WSL 與各類開發工具。最穩定的驗證方式，是先為目前的終端機工作階段設定代理環境變數，再執行請求指令。

macOS 與 Linux 目前工作階段

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl -I https://example.com/

https_proxy 的值寫成 http:// 並不矛盾，這表示透過本機 HTTP 代理使用 CONNECT 通道存取 HTTPS 網站。socks5h 中的字母 h 表示將網域交由 SOCKS 代理端解析，可減少本機 DNS 與代理出口不一致的問題。

只想影響單一指令時，可以將變數寫在指令前面。確認結果後，再決定是否加入 ~/.zshrc、~/.bashrc 或專案指令碼。長期寫入啟動檔會讓終端機在 Clash 未執行時仍嘗試連線至本機連接埠，因此最好同時準備清除指令。

https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

unset http_proxy
unset https_proxy
unset all_proxy

Windows PowerShell 目前工作階段

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

curl.exe -I https://example.com/

在舊版 Windows PowerShell 中，curl 可能是 Invoke-WebRequest 的別名，參數行為與標準 curl 不同。排查時請明確執行 curl.exe，並使用 curl.exe --version 查看實際程式。關閉目前的 PowerShell 視窗後，上述環境變數就會失效。

WSL 必須使用可連線的 Windows 主機位址

WSL2 執行於獨立的虛擬網路中，WSL 內的 127.0.0.1 不一定對應 Windows 上 Clash 的監聽位址。應先確認客戶端允許區域網路連線，再從 WSL 查詢預設閘道，並將該位址作為代理主機。不同 WSL 網路模式的表現可能不同，不能固定照抄某個私有網路 IP。

ip route | awk '/default/ {print $3}'

export https_proxy=http://Windows主機位址:7890
curl -I https://example.com/

若 WSL 能連線至 Windows 主機，但連接埠遭拒絕，應檢查 Clash 是否只監聽 127.0.0.1、是否啟用區域網路存取，以及 Windows 防火牆是否允許對應的私人網路。測試完成後，可恢復為僅本機監聽，減少不必要的區域網路暴露。

Git、npm 與開發工具需要個別確認

環境變數生效後，部分工具仍可能優先讀取自己的設定。也可能出現相反情況：系統代理已關閉，但 Git 或 npm 中儲存的舊代理仍指向 7890，導致 Clash 結束後所有請求都報錯。排查時既要檢查「缺少設定」，也要檢查「殘留設定」。

Git 代理的查看、設定與清除

git config --global --get http.proxy
git config --global --get https.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

還應執行 git config --show-origin --get-regexp proxy 查看設定來源。專案層級的 .git/config、使用者層級設定與系統層級設定可能同時存在，優先順序較高的專案設定會覆寫全域設定。SSH 形式的遠端位址不會讀取 Git 的 HTTP 代理，必須設定 SSH 的 ProxyCommand，或改用 HTTPS 位址測試。

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

pnpm、Yarn、pip、Maven 與 Docker 可能讀取環境變數，也可能維護各自的設定。若瀏覽器正常而安裝相依套件逾時，先查看工具的詳細記錄，確認它連線的是目標網域、映像站位址還是舊代理連接埠。容器中的 127.0.0.1 指向容器本身，不能直接代表主機上的 Clash。

請求進入 Clash 後仍失敗：查看規則、DNS 與節點

當即時記錄已出現目標網域時，系統代理這一環其實已經完成。後續失敗應依記錄繼續拆解：規則是否命中預期的策略群組、策略群組是否選取可用節點、DNS 是否回傳正確位址，以及遠端連線是否逾時。將所有失敗都稱為「代理未生效」，容易在錯誤的位置反覆操作。

根據記錄欄位判斷排查方向

DIRECT：請求進入核心後被規則判定為直接連線，檢查規則順序、規則集更新狀態與目前模式。
REJECT：請求命中拒絕規則，檢查網域是否遭廣告或隱私規則集攔截。
dial tcp timeout：本機連接埠已接收請求，但連線至目標或節點時逾時，檢查節點延遲、出口網路與防火牆。
connection refused：目標位址主動拒絕連線，可能是節點服務連接埠、目標服務或本機連接埠不正確。
dns resolve failed：網域解析階段失敗，檢查 DNS 伺服器、Fake IP 設定、DoH 可達性與規則。

排查時可暫時將客戶端模式切換為全域代理，並選擇一個已驗證的節點進行對照。如果全域模式可用、規則模式不可用，重點檢查規則命中結果；如果兩種模式都失敗，則重點檢查節點、訂閱設定與網路連線。測試完成後再切回規則模式，避免將全域模式當成長期修復方案。

什麼時候應改用 TUN 模式

系統代理主要服務於主動支援 HTTP 或 SOCKS 代理的應用程式。遊戲啟動器、部分桌面軟體、UDP 流量與固定直連程式可能完全不讀取系統代理。此時即使瀏覽器運作正常，相關應用程式仍會直接連線。TUN 模式透過虛擬網卡在網路層接管流量，涵蓋範圍通常更完整，但需要管理員權限，也會增加 DNS、路由與排除規則的設定量。

適合優先嘗試 TUN 的情境包括：應用程式沒有代理設定、程式持續繞過系統代理、需要處理 UDP，或希望讓多個命令列工具統一遵循 Clash 規則。只處理瀏覽器和少量開發工具時，系統代理搭配環境變數通常更清楚，也更容易依應用程式控制。

啟用 TUN 前檢查四項

確認目前客戶端使用支援 TUN 的 mihomo 核心，並已授予建立虛擬網卡所需的權限。
記錄現有 DNS 設定，避免系統 DNS、瀏覽器 DoH 與 Clash DNS 多層疊加後難以定位問題。
將區域網路位址、印表機、開發伺服器與本機服務加入必要的直連規則。
關閉其他 VPN 與虛擬網卡工具進行單一變數測試，避免預設路由與 DNS 互相覆寫。

啟用 TUN 後若所有網路立即中斷，應先關閉 TUN 以恢復連線，再查看核心記錄與虛擬網卡狀態。不要同時修改訂閱、DNS、規則與系統防火牆；每次只修改一項並保留前後結果，才能確認真正的故障點。

依序完成一次完整排查

確認 Clash 核心正在執行，目前設定已成功載入，且策略群組已選擇可連線的節點。
在「設定」→「參數設定」中核對 mixed、HTTP 或 SOCKS5 連接埠，避免將控制連接埠 9090 當成代理連接埠。
使用 curl -x 明確指定 127.0.0.1:7890，判斷本機代理連接埠是否可用。
檢查作業系統代理位址與連接埠，再檢查瀏覽器擴充功能、Firefox 獨立代理設定及啟動參數。
為終端機目前工作階段設定 http_proxy、https_proxy 或 all_proxy，重新執行相同請求。
檢查 Git、npm 等工具儲存的獨立代理設定，清除已失效的舊連接埠。
觀察 Clash 即時記錄；沒有連線記錄就回頭檢查應用程式端，有記錄則繼續查看規則、DNS 與節點。
確認目標程式確實繞過系統代理後，再評估是否啟用 TUN 模式。

瀏覽器能用、終端機卻不行，最常見的原因並不是 Clash 核心故障，而是兩類應用程式讀取代理的方式不同。先用明確指定代理的指令驗證連接埠，再分別處理瀏覽器覆寫設定與終端機環境變數，就能迅速縮小範圍。只有在請求已進入核心後，規則、DNS、節點與 TUN 才是下一階段的檢查對象。