故障排除 預計閱讀 12 分鐘

Clash 系統代理無效怎麼辦？排查瀏覽器未走代理與終端機代理設定

依序排查瀏覽器與終端機的系統代理問題：檢查代理擴充功能、PAC 與例外清單，並了解各系統的終端機環境變數設定。

先區分系統代理、規則模式與 TUN

在用戶端開啟「系統代理」，通常只是將作業系統的 HTTP、HTTPS 代理位址設為本機監聽連接埠。應用程式是否會讀取這項設定，取決於應用程式本身。瀏覽器可能會遵循系統設定；終端機中的 curl、Git 和套件管理工具則可能使用環境變數或個別設定。因此，「網頁可以開啟，終端機連線逾時」不代表節點一定失效。

Clash 或 mihomo 核心的「規則模式」會決定進入核心的連線如何分流；「全域模式」通常會將這些連線交由全域代理群組處理。兩者都不會自動讓所有程序進入核心。TUN 則透過虛擬網卡與路由接管流量，是另一種流量入口，仍會受到路由、DNS、程序排除設定與規則影響。

狀況優先檢查項目判斷依據
瀏覽器和終端機都無法連線核心、監聽連接埠及設定是否已啟用明確指定代理的 curl 是否能連上本機連接埠
瀏覽器正常，終端機失敗環境變數與工具設定在同一個終端機明確指定代理後是否成功
終端機正常，瀏覽器失敗代理擴充功能、PAC、例外清單瀏覽器請求是否出現在連線面板
請求已進入核心，但仍採直連符合的規則與代理群組選擇連線記錄是否顯示 DIRECT

建立基準：確認本機連接埠與明確指定代理的請求

先查看用戶端實際的監聽設定

前往用戶端設定中的連接埠或入站設定頁面，記下 HTTP、SOCKS、Mixed 連接埠及目前運行的核心。不同用戶端的選單名稱可能不同，請以實際介面和運行設定為準。以下統一以 127.0.0.1:7890 作為 Mixed 連接埠範例；並非所有用戶端都固定使用 7890。請勿將控制介面連接埠當成代理連接埠，external-controller 提供的是管理 API。

# 說明連接埠用途，請勿直接覆蓋完整訂閱設定
mixed-port: 7890
allow-lan: false
mode: rule

Mixed 連接埠可接受 HTTP 和 SOCKS 代理連線。如果設定只有 port: 7890，應以 HTTP 代理使用；如果只有 socks-port: 7891，則須使用對應的 SOCKS 位址。若只供本機存取，排查時不必開啟區域網路存取，也請勿將代理監聽連接埠暴露於公用網路。

透過一次請求區分「入口故障」與「出口故障」

請在 macOS、Linux 終端機執行下方的 curl 指令；在 Windows PowerShell 中，請將 curl 改為 curl.exe，避免舊版 PowerShell 的同名別名影響參數解析。測試時暫時關閉 TUN，只保留一個用戶端運行，減少多個入口混用造成的干擾。

curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
  • Connection refused：常見原因包括連接埠填錯、核心未啟動，或未監聽該位址。
  • 成功連上本機連接埠，但 CONNECT 失敗或回傳 502：請檢查用戶端記錄、節點是否可連線，以及符合的代理群組。
  • 出現 200 Connection established：這只代表 HTTP 通道已建立，還需確認 TLS 交握及目標網站的回應。
  • 收到目標網站的 HTTP 回應：代表這次明確指定代理的請求成功，不代表其他應用程式的設定也正確。

瀏覽器未走代理：依序檢查系統設定、擴充功能與 PAC

確認系統設定是否確實套用

在 Windows 11 中，前往「設定」→「網路和網際網路」→「Proxy」。若用戶端使用手動代理，應看到本機位址與實際連接埠；若使用自動設定指令碼，則請確認指令碼網址仍然有效。PAC 網址與手動代理的伺服器位址屬於不同設定，請勿混為一談。

在 macOS 14 中，前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」。確認修改的是目前使用中的網路，例如 Wi-Fi，而非未連線的乙太網路服務。HTTP 與 HTTPS 代理項目通常都使用用戶端的 HTTP 或 Mixed 監聽連接埠；目標網址是 HTTPS，不代表本機代理位址也必須使用 HTTPS。

Linux 桌面的代理設定會依桌面環境而異。GNOME 可從「設定」→「網路」→「網路 Proxy」檢查。桌面代理設定不保證會被所有沙箱應用程式、背景服務或命令列工具讀取，後續仍須為終端機個別驗證。

讓瀏覽器只使用一種代理設定來源

  1. 在 Chrome 開啟 chrome://extensions/，在 Edge 開啟 edge://extensions/，暫時停用管理代理的擴充功能，再完全結束並重新開啟瀏覽器。
  2. 在 Firefox 前往「設定」→「一般」→「網路設定」→「設定」，確認目前選擇的是「不使用代理伺服器」、「使用系統 Proxy 設定」還是手動設定。排查時請先讓 Firefox 與系統設定一致。
  3. 由組織管理的瀏覽器也應檢查 chrome://policy/ 或 edge://policy/。若代理由政策強制設定，切換用戶端的系統設定未必能改變瀏覽器行為。
  4. 重新造訪同一個測試網址，同時開啟用戶端的連線面板，查看目標網域、符合的規則、代理鏈與流量是否出現。

無痕視窗並非可靠的代理隔離環境：部分擴充功能仍可在無痕模式執行，且系統代理設定依然會沿用。必要時請使用暫時建立的瀏覽器設定檔進行比對，不要直接清除日常使用的設定。

檢查 PAC 與代理例外設定

PAC 指令碼可依不同網域回傳代理位址或 DIRECT。如果指令碼讓某個網域直連，請求便不會經過核心，修改 Clash 分流規則也不會影響這次請求。可先保存原有設定，再暫時改用明確指定的手動代理進行比對；不要同時疊加多個來源不明的 PAC 指令碼與代理擴充功能。

系統與瀏覽器中的例外清單也會略過代理。請特別檢查測試網域、萬用字元網域、區域網路位址，以及「本機位址不使用代理」等選項。造訪 localhost 無法用來證明公網代理是否生效，因為迴送位址通常有專門的略過機制。

Windows 終端機：分別設定 PowerShell 與 CMD

PowerShell、CMD 和應用程式內建的終端機未必使用相同的代理設定。以下環境變數只會影響目前程序及其後啟動的子程序；已在執行的終端機、編輯器或背景工作不會自動更新。請先用暫時設定進行驗證，確認有效後再考慮永久保存。

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 -I --connect-timeout 10 --max-time 20 https://example.com/

# 查看目前與代理相關的環境變數
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# 測試完成後清除本次設定
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

CMD 目前視窗

set "http_proxy=http://127.0.0.1:7890"
set "https_proxy=http://127.0.0.1:7890"
set "no_proxy=localhost,127.0.0.1,::1"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

rem 測試完成後清除設定
set "http_proxy="
set "https_proxy="
set "no_proxy="

https_proxy 表示 HTTPS 請求應使用哪個代理，不是要求代理連線本身使用 TLS。本例透過本機 HTTP 代理的 CONNECT 方法建立通道，因此值仍為 http://127.0.0.1:7890。

macOS 與 Linux：環境變數、SOCKS 與永久設定

先在目前的 shell 中測試

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 -I --connect-timeout 10 --max-time 20 https://example.com/

# 查看大小寫兩種形式，排除先前設定造成的干擾
env | grep -i proxy

# 清除本次設定
unset http_proxy https_proxy no_proxy

不同程式對變數大小寫的支援各有不同。curl 對 HTTP 代理特別使用小寫 http_proxy；不要只設定大寫 HTTP_PROXY 就判定代理無效。如果先前環境中還有 ALL_PROXY、HTTPS_PROXY 或其他大小寫形式的變數，請先記錄原值，再清除衝突項目。no_proxy 的網域比對語法也因工具而異，不宜將複雜清單直接套用到所有工具。

需要由代理端解析網域時，測試 SOCKS

# 只有在 7890 確認是 Mixed 或 SOCKS 連接埠時才使用
curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

對 curl 而言，socks5h:// 會將目標主機名稱交由代理端解析；socks5:// 則預設在本機解析。這項差異有助於找出本機 DNS 問題，但不能據此認定所有程式都支援相同的 URL 格式。若工具不支援 SOCKS 環境變數，請使用該工具明確支援的 HTTP 代理設定。

確認測試成功後，可依使用的 shell，將必要的 export 指令寫入 ~/.zshrc 或 ~/.bashrc，再開啟新的終端機驗證。登入 shell、從桌面啟動的應用程式與 systemd 服務載入環境的方式各不相同，不能假設修改一個檔案就會影響所有程序。使用 sudo 啟動指令時，環境變數也可能遭到過濾。

WSL、容器與虛擬機器中的 127.0.0.1 通常指向各自的網路環境，不一定是主機。WSL 的網路模式會影響迴送位址的存取能力；連線失敗時，請先確認主機位址與連接埠是否可連線。需要跨環境存取時，只對可信任的網路開放必要的監聽連接埠，並設定防火牆；請勿直接開放給所有網路。

指令仍然失敗：檢查工具設定、規則與 DNS

Git 等工具可能會覆蓋環境變數

Git 的全域設定、儲存庫設定，以及依 URL 套用的代理設定，都可能造成不同結果。請先查看設定來源，再以單次指令覆寫進行測試，避免修改後忘記還原。以下使用公開儲存庫測試，無須在指令中加入帳號密碼。

git config --show-origin --get-regexp '.*proxy'
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

套件管理工具、IDE 與下載工具也可能有各自的設定。瀏覽器連線成功，只能證明瀏覽器這條連線路徑可用，不能取代工具本身的連線測試。分享記錄時，請隱藏訂閱網址、存取權杖、帳號及含有認證資訊的代理位址。

確認請求進入核心後，再檢查規則

如果連線面板已顯示目標請求，請查看最終代理鏈：若顯示 DIRECT，檢查符合的規則，以及代理群組目前是否選擇直連；若顯示特定節點，再檢查該節點能否連上目標網站。成功匯入訂閱不代表設定已啟用，也不代表每個代理群組都選用了可用節點。

可暫時切換至全域模式，並選擇一個已確認可用的節點進行比對。若全域模式可用而規則模式失敗，請優先檢查規則比對與群組選擇；測試完成後恢復原模式。全域模式仍只會處理進入核心的連線，無法解決瀏覽器未讀取代理設定或終端機未設定入口的問題。

若錯誤訊息明確指出網域解析失敗，請先釐清由哪一端負責解析：應用程式、本機系統、HTTP 代理或 SOCKS 代理。瀏覽器的安全 DNS 設定可能會改變解析路徑，但並非所有瀏覽器代理問題都由此引起。請勿一開始就清除 DNS 設定或修改 Fake-IP 範圍，以免同時改變多個變數。

何時使用 TUN，以及如何完成複測

若應用程式不支援明確指定代理，可考慮在支援此功能的 mihomo 用戶端中使用 TUN。啟用前請確認用戶端版本、核心功能、權限需求，以及現有 VPN 路由。TUN 可能需要管理員權限，也可能與其他虛擬網卡、路由或 DNS 接管功能衝突；檢查連接埠之前，不應把它當成預設的修復方式。

  1. 先關閉 TUN，明確指定本機代理並成功送出一次請求，確認節點與監聽入口正常。
  2. 恢復瀏覽器的系統代理設定，單獨測試瀏覽器，並確認用戶端連線記錄中的網域與規則。
  3. 在新的終端機工作階段中驗證代理環境變數，並檢查工具的個別設定與例外清單。
  4. 只有在應用程式確實不支援代理時，才啟用 TUN，並觀察預設路由、DNS 與應用程式連線的變化。
  5. 結束用戶端後，確認網路是否恢復；若仍指向已停止監聽的本機連接埠，請關閉殘留的系統代理設定，或清除目前工作階段中的變數。

排查記錄至少應保留作業系統版本、用戶端與核心版本、監聽連接埠、測試指令、完整錯誤訊息，以及連線面板中的規則比對結果。依「應用程式入口 → 本機監聽 → 規則與代理群組 → 節點出口 → 目標網站」逐段驗證，比反覆重新安裝用戶端更容易找出問題所在。其他基本操作請參閱快速入門，欄位說明請查閱協定參考，常見問題請見說明中心。

下載用戶端