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

1. 先確認連接埠，再分辨系統代理與 VPN 接管

開啟用戶端的「設定」，尋找「連接埠」、「入站」或「混合連接埠」。記下實際連接埠號碼，再確認核心是否正在執行。不同用戶端的選單名稱可能不同，請勿直接將教學中的連接埠號碼套用到系統設定。本文以 127.0.0.1:7890 為例；只有在你的 HTTP 或混合連接埠確實是 7890 時，才能照此設定。

系統代理是一組供應用程式讀取的代理位址，不是強制接管所有網路連線的開關。瀏覽器通常會讀取系統代理，命令列工具則各有設定方式。摘要所說的「終端只認環境變數」指的是常見的排查入口；嚴格來說，實際發出請求的是 curl、Git、套件管理器等程式，它們也可能讀取命令列參數或自己的設定檔。

入口	用途	常見誤判
系統 HTTP 代理	提供代理位址給遵循系統設定的應用程式	以為開啟開關就代表所有應用程式都會走代理
HTTP／混合連接埠	接收應用程式主動送出的代理請求；混合連接埠支援 HTTP 與 SOCKS	把 SOCKS 專用連接埠填入 HTTP 代理欄位
TUN 模式	透過虛擬網路介面與路由，接管符合條件的流量	以為開啟後就不必檢查路由、DNS 與分流規則
Android VPN 服務	透過 Android 的 VpnService 接收裝置流量	誤以為它和桌面系統代理開關相同

2. 使用一次明確指定代理的請求，判斷故障所在層級

先別反覆切換節點。開啟終端，使用 curl 的明確代理參數，排除「應用程式是否讀取系統代理」這個變因。以下網址僅供測試，不是測速節點；請留意請求是否進入用戶端，以及在哪個步驟失敗。

macOS 或 Linux

curl -v --connect-timeout 10 --max-time 20 \
  --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  https://example.com/

Windows PowerShell

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

Windows 請使用 curl.exe，避免 Windows PowerShell 5.1 中的 curl 別名轉而呼叫其他命令。此處將連線逾時設為 10 秒、總時限設為 20 秒，只為避免測試一直等待，並非節點效能標準。--noproxy "" 用來清空本次請求的略過清單。

本機連線遭拒：優先確認核心是否已啟動、連接埠是否正確，以及該連接埠是否只支援另一種代理協定。
出現 HTTP 407：本機代理要求驗證。請依實際設定提供憑證，勿將密碼貼到公開紀錄中。
收到 CONNECT 成功回應：表示 HTTP 代理已接受通道請求，但後續 TLS 交握或目標回應仍可能失敗。
收到目標網站的回應：表示這次請求使用的本機代理路徑可運作；但不能據此認定所有節點、網域與規則都正常。

同時開啟用戶端的「連線」或「紀錄」頁面，查看請求網域、符合的規則、策略群組與最終出站。若請求顯示 DIRECT，流量可能已進入核心，只是依規則設為直連；這和「系統代理沒有生效」是兩回事。

3. 瀏覽器無法連線：依序檢查系統設定、擴充功能與獨立設定

Chrome 與 Edge：先檢查系統代理，再停用代理擴充功能

在 Windows 11 開啟「設定」→「網路和網際網路」→「代理伺服器」，確認「手動設定代理伺服器」中的位址與連接埠。若用戶端管理的是自動設定指令碼，也要確認指令碼來源。
在 macOS 開啟「系統設定」→「網路」→目前使用的連線→「詳細資訊」→「代理伺服器」，確認網頁代理、安全網頁代理或自動代理設定是否符合用戶端的設定方式。
在 Chrome 的「設定」→「系統」中開啟電腦的代理設定；Edge 的對應選項通常位於「系統與效能」。也可以直接依照上述作業系統路徑操作。
開啟擴充功能管理頁面，暫時停用所有可修改代理設定的擴充功能，再重新造訪同一個測試網址。先記下原本的擴充功能模式，測試後視需要還原。

代理擴充功能可能固定使用其他連接埠，也可能透過 PAC 指定某些網域直連。PAC 是依網址選擇代理的自動設定指令碼。若瀏覽器提示設定由組織管理，請檢查瀏覽器政策或聯絡管理員；不要反覆切換用戶端開關，試圖覆蓋組織設定。

Firefox：明確選擇代理來源

開啟「設定」→「一般」→「網路設定」→「設定」。若要沿用作業系統設定，請選擇「使用系統代理設定」；若要單獨測試，則選擇「手動設定代理」，填入實際的 HTTP 代理位址與連接埠，並確認是否將代理用於 HTTPS。不要選擇「不使用代理」，卻只修改系統代理。

若使用 SOCKS v5，代理欄位與連接埠必須對應 SOCKS 或混合入站。若要由代理端解析網域，請檢查 Firefox 中 SOCKS v5 的代理 DNS 選項。安全 DNS、快取與代理類型都會影響解析路徑；不能只因瀏覽器啟用了安全 DNS，就判定 Clash 的 DNS 一定失效。

4. 終端未走代理：為實際執行的程式設定環境變數

如果明確指定代理的測試成功，但一般終端請求失敗，請確認程式是否有讀取代理設定。環境變數只會傳遞給目前的程序及之後啟動的子程序；在一個視窗中設定，不會自動同步到另一個已開啟的視窗。先測試僅限目前工作階段的設定，暫時不要寫入啟動檔案。

Bash 或 Zsh：先設定 HTTP 代理環境變數

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

https_proxy 的值使用 http:// 並沒有寫錯：這裡表示連線到本機代理時使用的協定，HTTPS 目標通常透過 HTTP CONNECT 通道連線。不要只因目標是 HTTPS，就把本機代理位址改成 https://127.0.0.1:7890。

curl 使用小寫 http_proxy 設定 HTTP 代理；其他工具對大小寫的處理方式可能不同。no_proxy 是略過清單，若其中包含測試網域，程式可能會直接連線。檢查時請留意大小寫不同的兩組變數是否互相衝突，也不要公開輸出含有驗證資訊的變數。

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

並非所有 PowerShell 命令或應用程式執行環境都會像 curl 一樣讀取變數。若 curl 正常、另一個工具卻失敗，請查閱該工具的代理設定文件，不要因此修改整個系統的網路設定。使用 sudo 後，變數也可能遭到清除；請確認提權後的程式實際取得哪些設定。

SOCKS 與應用程式專屬設定

若本機確實有開啟 SOCKS 或混合入站，可以用以下單次請求比較網域解析路徑。socks5h 表示將網域交由代理端解析；一般的 socks5 通常會先由本機解析。此處的 7890 仍須替換成實際連接埠號碼。

curl -v --noproxy "" --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 https://example.com/

部分工具會將 ALL_PROXY 用作通用代理變數，但支援範圍與優先順序並非全系統一致。Git 也可能另有 http.proxy 設定，npm 同樣有專屬的代理選項。請先確認設定來源，避免環境變數與舊設定同時生效。

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

5. 何時改用 TUN 模式

若需要接管多個不讀取系統代理的應用程式，或應用程式沒有代理設定選項，可以考慮使用 TUN。TUN 是虛擬網路介面，mihomo 等核心可透過它接收 IP 流量。它解決的是流量入口問題，不會自動修復失效的訂閱、錯誤節點、憑證問題或不適用的分流規則。

先用明確指定的 HTTP 或 SOCKS 請求確認節點路徑可用，再啟用用戶端的「TUN 模式」或「虛擬網卡」選項。
依照用戶端提示安裝或啟動系統服務，並授予必要權限。Windows、macOS 與 Linux 的權限機制各不相同，請勿照搬其他平台的步驟。
暫時停用其他 VPN 或虛擬網路接管工具，避免預設路由互相競爭。企業裝置請先遵循管理規範。
測試期間移除瀏覽器的手動代理設定與終端代理變數，避免明確代理與 TUN 同時介入，增加判斷難度。
重新送出請求，查看用戶端的連線紀錄與規則命中情況，再確認本機網路、印表機與公司內網是否仍可存取。

Android 通常透過 VPN 服務接管這類流量，不應照搬桌面平台安裝虛擬網卡驅動程式的流程。也請確認應用程式分流沒有排除目標應用程式；同一個 Android 使用者或工作資料中的其他 VPN 也可能影響連線。

6. 依測試結果完成排查，保留可重現的設定

測試結果	優先檢查	下一步
明確指定代理仍無法連上本機連接埠	核心、監聽位址、連接埠與入站協定	先修復本機連線，不必急著更新訂閱
明確指定代理可用，瀏覽器卻失敗	系統代理、代理擴充功能、Firefox 獨立設定	保留一個明確的代理來源後再試一次
瀏覽器正常，終端卻失敗	環境變數、程式設定、容器網路	為實際發出請求的程式單獨設定代理
請求已進入核心，但走 DIRECT	規則、模式、策略群組	確認目標網域符合哪條規則
啟用 TUN 後，部分應用程式仍失敗	路由、DNS、應用程式排除設定與 UDP 支援	用該應用程式實際送出的請求檢查紀錄

排查完成後，清除暫時設定的變數；若測試前已有代理設定，請還原原值，而非直接刪除。以下命令適用於測試前未設定這些變數的情況。若要永久設定，請另行編輯 shell 啟動檔案，或使用系統環境變數設定介面。

# Bash / Zsh：清除本次工作階段的暫時代理
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

# PowerShell：清除本次工作階段的暫時代理
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

最後記下四項資訊：實際入站連接埠、瀏覽器的代理來源、終端程式的代理設定，以及請求命中的出站。只要這四項資訊明確，下次遇到「系統代理已開啟卻無效」時，就能從對應層級繼續排查，不必把瀏覽器、終端與節點問題混為一談。對外分享紀錄前，請遮蔽訂閱連結、驗證資訊與個人瀏覽紀錄。