Clash 系統代理已開啟卻沒走代理？瀏覽器與終端機排查指南

先確認請求是否進入 Clash

系統代理開關只代表系統代理設定曾嘗試變更，不代表所有應用程式都已交由 Clash 處理。瀏覽器可能由擴充功能接管，終端機通常需要另外指定代理，而 PAC 也可能將目標網域判定為直接連線。即使請求已進入核心，規則仍可能選擇 DIRECT。先釐清是「未接管」還是「接管後直接連線」，比反覆切換節點更有效。

1. 在用戶端查看目前的設定與本機監聽埠。本文以 127.0.0.1:7890 作為 HTTP 或混合代理範例，實際設定請以目前配置為準。
2. 開啟用戶端的 Connections（連線）頁面，並在 Logs（記錄）中查看新請求；必要時可暫時將記錄層級調整為 info。
3. 記下目前時間，在瀏覽器開啟一個確定會發出網路請求的頁面，再確認目標網域、命中規則與代理鏈。
4. 接著使用下文的明確指定代理指令存取同一目標。如果指令成功、瀏覽器卻失敗，應優先檢查瀏覽器與系統設定，不要立刻修改訂閱。

檢查本機埠號：系統代理位址必須對應核心的監聽埠

用戶端介面中的控制埠不等於代理埠。設定項 external-controller 用於控制 API，不能填入瀏覽器的 HTTP 代理位址。port 通常提供 HTTP 代理，socks-port 提供 SOCKS 代理，mixed-port 則同時接受 HTTP 與 SOCKS 請求。

例如，7890 和 7891 只是常見設定值，並非固定標準。以下是用來說明埠號對應關係的 YAML 片段，不包含節點、訂閱或完整規則，不能直接當成可連線的完整設定：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows：檢查監聽狀態與系統設定

在 PowerShell 執行以下指令。第一個指令會檢查埠號是否正在監聽；Windows 目前使用者的代理設定則需手動開啟設定頁查看：

Get-NetTCPConnection -State Listen -LocalPort 7890
Start-Process "ms-settings:network-proxy"

前往「設定」→「網路和網際網路」→「Proxy」，確認手動代理位址是否為 127.0.0.1、埠號是否與用戶端一致，並記下「使用設定指令碼」是否已開啟。若第一個指令沒有任何結果，請先確認用戶端核心是否正在執行；若該埠號由其他程序占用，應確認程序所屬來源，不能直接認定是 Clash。

macOS 與 Linux：先確認監聽狀態，不要猜預設值

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

# Linux
ss -lntp 'sport = :7890'

macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理」，確認 HTTP、HTTPS 與自動代理設定。Wi-Fi 與乙太網路是不同的服務，切換網路後要重新確認。Linux 桌面環境的代理設定因桌面環境而異，也不能假設所有應用程式都會讀取桌面的代理開關。

瀏覽器排查：分別確認擴充功能、獨立設定與 PAC

Chrome 與 Edge：先排除擴充功能接管

Chrome 通常可從「設定」→「系統」→「開啟電腦的代理設定」查看系統代理；Edge 的入口通常位於「設定」→「系統與效能」→「系統」。不同版本的選單名稱可能略有差異，也可以直接在設定頁搜尋「代理」。

• 檢查代理切換擴充功能目前使用的模式。擴充功能可能固定連到其他埠號，或將部分網域加入直連清單。
• 暫時停用所有會修改代理設定的擴充功能，關閉所有瀏覽器程序後重新啟動測試。無痕視窗不代表擴充功能一定全部停用；允許在無痕模式執行的擴充功能仍可能生效。
• 如果裝置由組織管理，請查看 chrome://policy 或 edge://policy 中的代理政策。由政策鎖定的設定必須請裝置管理員調整。
• 檢查瀏覽器啟動參數是否包含 --no-proxy-server、--proxy-server 或 --proxy-pac-url；這些參數可能會改變實際行為。

Firefox：確認沒有使用另一組代理設定

前往「設定」→「一般」→「網路設定」→「設定」。選擇「使用系統代理設定」後再測試；如果選擇「手動代理設定」，請逐項確認 HTTP、HTTPS 或 SOCKS 的位址與埠號。也要檢查「不使用代理」的例外清單，尤其是曾為開發環境加入的網域後綴。

PAC：先確認瀏覽器是否將請求送進 Clash

PAC 指令碼中的 FindProxyForURL 會根據 URL 和主機名稱決定路由。若回傳 DIRECT，請求就不會經過本機 HTTP 代理；只有回傳 PROXY 127.0.0.1:7890，請求才會送至對應埠號。若結果為 PROXY 127.0.0.1:7890; DIRECT，代理無法使用時也可能退回直接連線，實際行為視應用程式的實作而定。

PAC 直連與 Clash 規則直連發生在不同階段。PAC 先決定是否使用代理；請求進入核心後，Clash 的 rules 才會繼續決定流向。暫時停用自動設定指令碼，只保留正確的手動 HTTP 代理，有助於縮小問題範圍；測試前先記下原設定，完成後再還原。請勿在工作裝置上任意覆寫組織下發的 PAC。

終端機排查：以明確指定代理進行對照

許多命令列程式不會讀取系統代理。瀏覽器可以連線、curl 卻仍直接連線，並不代表 Clash 失效。先用指令參數明確指定本機代理，排除環境變數造成的干擾。

Windows PowerShell 測試

使用 curl.exe，避免 Windows PowerShell 5.1 中的 curl 別名指向其他指令。以下指令會連線至示範網站、強制使用本機 HTTP 代理，並以命令列的略過清單覆寫可能存在的 NO_PROXY 設定：

curl.exe -v --connect-timeout 10 --max-time 30 --proxy http://127.0.0.1:7890 --noproxy localhost https://example.com/ --output NUL

這裡的 --noproxy localhost 只會讓 localhost 略過代理，測試目標 example.com 不在略過清單中。這也能避免部分舊版 PowerShell 傳遞空字串參數時的差異。此網域僅用於示範請求路徑，能否連線不代表其他目標網站也都能使用。

macOS 與 Linux 測試

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

查看詳細輸出中的本機連線位址與 HTTPS 通道協商。出現 CONNECT example.com:443 表示 curl 正在向 HTTP 代理要求建立通道；收到 200 Connection established 也不代表後續 TLS 交握與網頁請求一定成功，仍須確認最終結果及用戶端的連線記錄。

• Connection refused：優先檢查本機埠號與核心監聽狀態。
• 通道已建立，接著卻出現 TLS 錯誤：檢查系統時間、憑證信任設定，以及是否有其他 HTTPS 檢查軟體；不要把略過憑證驗證當成修復方式。
• 用戶端顯示節點連線逾時：代表請求已進入代理鏈，接下來應檢查節點與遠端連線。

環境變數與應用程式設定：只會影響適用的程序

明確指定代理測試成功後，再為需要代理的終端機程序設定環境變數。對 curl 而言，連線至 HTTPS 網站可使用 https_proxy；變數值中的 http:// 指的是「用戶端到代理」的通訊協定，不需要改成 https://。不同工具支援的變數及優先順序不盡相同。

先查看目前設定值

# PowerShell：列出目前程序中與代理相關的環境變數
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# macOS / Linux
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

特別檢查殘留的埠號、舊代理位址，以及 NO_PROXY 或 no_proxy。例如 NO_PROXY=* 會讓支援此慣例的工具略過所有代理；網域後綴的比對方式則應參考各工具文件。curl 對 HTTP 代理環境變數有特殊安全處理，在 POSIX shell 中建議優先使用小寫 http_proxy，不要只設定大寫 HTTP_PROXY。

只在目前的終端機設定，確認有效後再設為永久設定

# PowerShell：套用至目前程序及之後啟動的子程序
$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

# macOS / Linux：套用至目前 shell 及之後啟動的子程序
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

上述設定不會自動套用到已啟動的 IDE、背景服務或其他終端機視窗。確認環境變數有效後，請重新啟動目標程式，或直接在目前的終端機中執行。使用 sudo 後，環境變數可能遭到過濾；在 WSL、容器及遠端 SSH 工作階段中，127.0.0.1 也不一定等同於主機，應先確認網路邊界與實際可連線的位址。

Git 也可能設有獨立的代理設定。執行以下指令找出設定來源；先查看再修改，以免覆蓋儲存庫或組織要求：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

請求進入核心後：確認 Rule、DIRECT 與策略組

在 Connections 中找到目標請求，查看目標網域、符合的規則、規則內容與代理鏈。欄位名稱會因用戶端而異，但判斷方式相同：如果連線路徑為 DIRECT，代表這次請求被判定為直接連線；如果顯示策略組與實際節點，就沿著該節點繼續排查。

1. 確認模式：Rule 會依規則分流，Direct 模式會直接連線；Global 則使用全域策略。系統代理開關與這三種模式並非同一個設定。
2. 確認順序：規則通常依序比對，前面的網域、IP 或規則集項目可能會先命中；末尾的 MATCH 不會覆蓋已命中的規則。
3. 確認策略組內的選擇：即使規則指向名為「代理」的策略組，組內仍可能選到 DIRECT。策略組名稱不代表實際流量一定會經過代理。
4. 確認網域資訊：應用程式直接連線至 IP、DNS 快取或不同的流量接管方式，都可能影響核心可用於比對的資訊。網域規則沒有命中，不代表規則集一定失效。

必要時，可暫時切換至 Global，並選擇已知可用的節點進行對照。如果全域模式可用、Rule 模式卻直接連線，應優先檢查規則與策略組內的選擇；測試完成後記得還原原模式。切換節點或規則後，既有的 TCP、HTTP/2 連線不一定會重新建立，必須讓應用程式重新發出連線，才能確認新路徑。

若系統代理無法接管流量，再評估 TUN

系統 HTTP 代理不會接管所有 UDP 流量，也不保證能涵蓋自行實作網路堆疊的遊戲、命令列工具或其他應用程式。Clash Meta（mihomo）的 TUN 功能透過虛擬網路介面與路由接管流量，涵蓋範圍與系統代理不同，但仍取決於平台權限、路由、DNS 設定及核心配置。

本機埠號尚未確認前，不要同時啟用 TUN、變更 DNS 或切換全域模式。這麼做或許會改變結果，卻無法判斷是哪個步驟生效。如果目標應用程式確實不支援代理，請依照用戶端說明確認 TUN 所需的服務或管理員權限，並檢查是否與 VPN 或其他虛擬網卡衝突。瀏覽器的安全 DNS 會影響解析路徑，但不能直接等同於「瀏覽器繞過 HTTP 代理」。

重新測試與記錄：以相同目標比較修改前後

• 記錄用戶端名稱與實際版本、核心版本、作業系統版本，以及 HTTP 或混合代理埠號；不要只寫「最新版」。
• 每次只修改一項，保持測試網域、請求工具與所選節點一致，並記下測試時間。
• 同時保存瀏覽器測試結果、明確指定代理的 curl 結果、連線頁面顯示的命中規則與實際代理鏈。
• 若要確認出口 IP，請使用可信任的服務，並與連線記錄交叉比對。單一頁面顯示的地理位置可能有延遲，不能取代連線路徑的證據。
• 分享排查資訊前，請移除訂閱網址、存取權杖、節點憑證與個人瀏覽記錄；也應先檢查命令列的詳細輸出。

最後應能將問題定位到明確環節：本機埠號未監聽、應用程式未使用代理、PAC 或例外清單略過代理、規則選擇直連，或代理鏈連線失敗。只要明確指定代理的測試、瀏覽器設定與核心記錄三項證據能相互對應，就不必靠反覆重裝用戶端猜測原因。基本設定順序請參閱入門指南；規則與 DNS 的細節則可進一步查看進階設定。