Clash 系統代理無效？瀏覽器與終端機分開排查

先分清系統代理、應用程式代理與 TUN

Clash 用戶端中的「系統代理」開關，通常只是將本機代理位址寫入作業系統的代理設定，並不代表會強制接管所有網路連線。瀏覽器、命令列工具與背景服務可能各自讀取不同設定，因此「網頁能開啟，終端機連線逾時」並不矛盾。

排查時先確認兩件事：請求是否進入 Clash 核心，以及進入後符合哪條規則。前者是代理入口問題，後者才涉及訂閱節點、策略群組與分流設定。出口 IP 沒有變化，不代表系統代理開關一定失效。

第一步：確認本機代理入口可用

確認混合連接埠，不要用外部控制連接埠

在用戶端的設定或設定檢視頁面尋找 mixed-port。混合連接埠可同時接收 HTTP 與 SOCKS 代理請求；external-controller 是管理 API 的監聽位址，不能用來代理網頁。常見的 9090 只是控制連接埠範例，不要因為該連接埠正在監聽，就把它填入瀏覽器代理欄位。

mixed-port: 7890
external-controller: 127.0.0.1:9090

先確認核心正在執行且已選取訂閱設定，再使用明確指定代理的命令測試。Windows PowerShell 請使用 curl.exe，避免舊版 Windows PowerShell 將 curl 解讀為另一個命令。

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy "" 會清除本次請求的代理略過清單，避免既有的 NO_PROXY 設定造成干擾。此處的 10 秒是連線逾時上限，20 秒是整個請求的逾時上限，並非節點延遲的參考值。測試網址也可換成目前無法連線的網站，但請勿在公開記錄中保留含有登入權杖的完整網址。

• 若連線至 127.0.0.1:7890 時遭拒，請先確認核心是否已啟動、連接埠是否填錯，以及是否有其他程序占用該連接埠。
• 若看到 HTTP 代理通道回應 200 Connection established，表示本機代理已接受 CONNECT 請求；接著仍須查看後續 TLS 與 HTTP 結果。
• 本機連線成功後仍逾時或出現 TLS 錯誤：接著檢查節點連線、目標網站、DNS 或憑證，不要再只盯著系統代理開關。

同時開啟用戶端的「連線」或「記錄」頁面，再送出一個新請求。記錄層級可暫時調為 info；確有需要時再改用 debug，測試結束後請還原。若明確指定代理的命令成功、瀏覽器卻失敗，問題通常出在瀏覽器自己的代理入口設定。

第二步：檢查系統代理實際設定的位置

Windows 11：確認手動代理與指令碼設定

開啟「設定」→「網路和網際網路」→「Proxy」，查看「手動設定 Proxy」下的「使用 Proxy 伺服器」。使用本文範例時，位址應為 127.0.0.1，連接埠應為 7890。啟用用戶端系統代理後，返回此頁確認數值確實改變，不要只看用戶端按鈕的顏色。

接著確認「使用設定指令碼」是否已啟用，以及代理例外清單是否包含目標網域。自動設定指令碼、組織原則或其他網路工具都可能影響實際結果。受管理的裝置請先聯絡管理員，不要直接刪除組織部署的設定。

netsh winhttp show proxy 顯示的是 WinHTTP 代理設定，並不代表此設定頁面的完整狀態。部分服務使用 WinHTTP，瀏覽器則可能採用系統代理解析機制或自己的設定。不要為了讓輸出一致就直接執行全域匯入命令；請先確認出問題的程式實際使用哪一套網路介面。

macOS：檢查目前使用的網路服務

在 macOS 13 或更新版本中，開啟「系統設定」→「網路」→目前使用的 Wi-Fi 或乙太網路→「詳細資訊」→「代理伺服器」。檢查網頁 Proxy（HTTP）、安全網頁 Proxy（HTTPS）及自動代理設定。從 Wi-Fi 切換到有線網路後，請檢查新連線對應的服務，不要繼續查看原本的 Wi-Fi 設定。

HTTPS 網頁透過 HTTP 代理時，通常會以 CONNECT 建立通道。本機代理位址使用 http://127.0.0.1:7890，不代表網頁失去 HTTPS 加密，也不需要把本機位址改成 https://。代理伺服器本身是否支援 TLS，是另一項獨立功能。

Linux：桌面設定不代表所有程式

GNOME 桌面可在「設定」→「網路」→「網路 Proxy」查看手動或自動模式；其他桌面環境的選項名稱可能不同。桌面代理通常只影響會讀取該設定的應用程式，不會自動將環境變數注入所有 shell、容器與 systemd 服務。Linux 終端機無法連線時，請接著檢查下一節的環境變數與程式設定。

第三步：分開檢查瀏覽器擴充功能、例外清單與舊連線

先在同一個瀏覽器的新視窗中開啟相同的測試網址，並在 Clash 連線頁面查看新請求。既有的 HTTP/2 或 HTTP/3 長連線可能會繼續沿用；切換開關後只重新整理頁面，未必能完整反映新的連線路徑。必要時請完全關閉瀏覽器後重新啟動。

1. Chrome 與 Edge：進入瀏覽器「設定」，搜尋「Proxy」，再開啟電腦的代理設定。桌面版通常會採用系統代理，但代理擴充功能、啟動參數與企業原則都可能覆蓋此設定。
2. 檢查代理擴充功能：暫時停用管理代理的擴充功能，或將其切換為「系統代理」。不要同時讓擴充功能固定代理、PAC 指令碼與用戶端系統代理互相覆蓋。
3. Firefox：開啟「設定」→「一般」→「網路設定」→「設定」。明確選擇「使用系統 Proxy 設定」，或改用手動代理進行單獨測試，避免誤選「無 Proxy」。
4. 檢查略過清單：查看瀏覽器與系統中的「不使用 Proxy」或例外項目。若目標網域列在其中，連線可能會直接連線。

在 Firefox 手動設定時，HTTP 代理可填入 127.0.0.1 和實際的混合連接埠，並依介面選項讓 HTTPS 使用相同的 HTTP 代理；若改用 SOCKS v5，請留意「使用 SOCKS v5 時代理 DNS」選項。HTTP 代理與 SOCKS 的 DNS 行為並不相同。

如果請求已進入 Clash，但規則結果是 DIRECT，請檢查規則模式、符合的規則與策略群組選擇。系統代理完成轉送，不代表所有網站都會經由遠端節點連線。查看一次出口 IP，只能說明該次檢測請求的路徑，無法代表瀏覽器的所有連線。

第四步：檢查終端機環境變數與工具專用設定

終端機通常不會因為系統代理已啟用就自動使用代理。先執行前面的明確指定代理命令：若該命令成功，但一般的 curl 請求失敗，請優先檢查目前 shell 的環境變數。不同工具對變數名稱大小寫的支援不一，例如 curl 基於安全考量，不接受大寫 HTTP_PROXY 作為 HTTP 代理變數。

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:7890'
$env:https_proxy = 'http://127.0.0.1:7890'

# 以新請求進行驗證
curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

這些指派只會變更目前的 PowerShell 程序及其後續啟動的子程序，不會同步修改已開啟的 IDE、其他終端機或系統服務。Windows 的環境變數名稱通常不區分大小寫；在 macOS 與 Linux 上則須留意大小寫差異。

macOS / Linux：檢查目前的 shell

# 查看代理相關變數
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 為目前的 shell 設定 HTTP 代理
export http_proxy='http://127.0.0.1:7890'
export https_proxy='http://127.0.0.1:7890'

# 發出新請求
curl -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

https_proxy 的值使用 http:// 是正常寫法，表示透過 HTTP 代理連線至 HTTPS 目標。若 NO_PROXY 或 no_proxy 包含目標網域，請求仍可能略過代理；設為 * 甚至可能讓該工具的所有請求直接連線。請保留實際需要的本機位址例外，只調整與目前問題相關的項目。

環境變數正確，程式仍未使用代理

並非所有命令列程式都支援這些變數。以 Git 為例，可檢查專用設定及其來源：

git config --show-origin --get-regexp '.*proxy.*'

如果輸出中有舊連接埠或指向另一台電腦的代理，請先記錄設定所在的檔案與範圍，再修改對應項目。專案設定、全域設定與 URL 專用設定可能同時存在，不要只修改一處就判定設定無效。IDE 內建終端機會繼承 IDE 啟動時的環境；修改系統環境後，可能需要完全關閉 IDE 再重新開啟。

WSL、Docker 容器、虛擬機器與 SSH 遠端工作階段還有網路邊界：其中的 127.0.0.1 通常指向各自的環境，不一定是執行 Clash 的主機。WSL 的實際行為也取決於網路模式與系統設定。請先確認主機可連線的位址與監聽範圍；若確實需要開放區域網路存取，請限制防火牆允許的來源，切勿將代理連接埠直接暴露至公網。

第五步：用 SOCKS 與記錄區分 DNS、規則和節點問題

若本機 HTTP 代理可連線，但特定網域仍無法使用，可在相同的混合連接埠上再進行 SOCKS 測試。以下命令使用 socks5h，讓 curl 將網域交由 SOCKS 代理端解析，而不是先由 curl 在本機解析目標網域。

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o /dev/null

對 curl 而言，socks5:// 與 socks5h:// 的網域解析位置不同。代理端收到網域後，還會依照核心的 DNS 與規則設定繼續處理，因此 SOCKS 測試成功，不代表整台電腦的 DNS 都正常。請搭配用戶端記錄中的目標網域、符合的規則與策略鏈一起判斷。

瀏覽器的安全 DNS 可能改變網域解析路徑，但不代表略過 HTTP 代理。不要直接把「已啟用安全 DNS」當成系統代理失效的證據。只有比對同一個網域啟用前後的結果，並搭配實際連線記錄，才能判斷是否需要調整解析方式。

第六步：需要接管不使用代理的應用程式時，再檢查 TUN

TUN 模式透過虛擬網路介面與路由接收流量，適合處理不讀取系統代理的應用程式，但不能用來補救錯誤的連接埠設定。建議先確認明確指定代理的命令正常運作，再單獨測試 TUN。如此可區分代理出口故障與虛擬網卡接管故障。

1. 確認目前使用的用戶端與核心支援 TUN。使用 mihomo 的用戶端與舊版 Clash 用戶端可能提供不同選項，不要將網路上任意找到的設定區塊直接貼到所有版本。
2. 依照用戶端說明安裝服務或授予必要權限，再啟用 TUN。Windows 用戶端可能需要服務模式或系統管理員權限，macOS 可能會提示授權，Linux 通常需要網路管理權限。
3. 檢查記錄是否顯示虛擬網卡建立失敗、權限不足或新增路由失敗。介面上的開關已開啟，不代表相關操作都已成功。
4. 排查時暫時只保留一種接管方式：先記錄原設定，再關閉系統代理，透過新請求觀察 TUN 是否接管；測試完成後還原原本的設定組合。
5. 若同時執行其他 VPN、虛擬網卡或網路過濾工具，請逐一暫停並比較結果。不要直接刪除路由或網卡，也不要在依賴遠端連線的電腦上貿然變更預設路由。

在 mihomo 中，tun.enable、auto-route、auto-detect-interface 與 DNS 接管相關設定各有用途。用戶端可能會在啟動時產生或合併設定，修改訂閱原始檔不一定會改變最終生效值。請查看執行中的設定或用戶端提供的覆寫選項，並在重新啟動核心後確認記錄。

TUN 同樣會受到路由排除、程序規則、DNS 設定及其他網路元件影響，不能簡單理解為「開啟後所有流量一定會走代理」。如果請求進入核心後被規則判定為直連，仍可能使用本機出口。

還原設定與複核順序

完成排查後，只保留實際需要的入口。暫時修改的環境變數應還原為原值；以下命令僅適用於測試前未設定這些變數的情況。若原本已有企業代理或開發環境代理，請還原記錄下來的值，不要直接刪除。

# PowerShell：清除本次暫時新增的變數
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

# macOS / Linux：清除本次暫時新增的變數
unset http_proxy https_proxy

• 先確認本機入口：明確指定實際的混合連接埠，確認請求能進入核心。
• 再確認瀏覽器：檢查系統代理、擴充功能、Firefox 個別設定與例外清單。
• 單獨確認終端機：檢查目前工作階段的環境變數、程式設定與主機網路邊界。
• 最後確認分流：查看規則與策略鏈，再決定是否調整 DNS 或啟用 TUN。

尋求協助時，請提供作業系統版本、用戶端與核心版本、實際連接埠、明確指定代理命令的結果，以及同一時段的相關記錄。分享前請刪除訂閱網址、節點憑證、API 金鑰與個人瀏覽記錄。相較於只說「Clash 系統代理無效」，這些資訊更有助於縮小問題範圍。

初次設定可參閱系統代理教學；若已確認請求進入核心但仍逾時，可參考連線逾時排查。修改設定前先保留副本，每次只變更一個環節，才能確認是哪項設定影響結果。