Clash 系統代理已開啟卻無效？檢查瀏覽器與命令列終端

先分清系統代理、應用程式代理與規則分流

開啟系統代理，只代表作業系統已記錄代理設定，不代表所有程序都會使用它。瀏覽器可能遵循系統設定，也可能被擴充功能或個別設定覆蓋；命令列程式通常需要環境變數或專用參數。連線進入 Clash 核心後，還得依目前模式、規則與策略組決定最終出口。

因此，「出口 IP 沒變」不能單獨證明系統代理失效。連線可能已進入核心，但命中 DIRECT；也可能是應用程式完全繞過代理。排查時應同時查看應用程式設定與用戶端連線紀錄，別只看網頁能不能開啟。

在支援這些欄位的 Clash 或 mihomo 核心中，以下片段表示只在本機提供 HTTP 與 SOCKS 代理入口。請將它合併至既有設定；片段不包含節點與規則，不能取代完整訂閱。

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

mixed-port 可同時接受 HTTP 與 SOCKS 代理連線；獨立的 port 和 socks-port 則須依協定分別使用。
allow-lan: false 適合本機測試。排查本機瀏覽器問題時，不必為了連線而開放區域網路存取。
mode: rule 會繼續依規則分流。要確認的是目標連線符合哪條規則，而不只是查看模式名稱。

第一步：確認核心監聽狀態與明確指定代理的請求

先略過系統代理開關，直接用命令指定代理入口。如果明確指定代理也失敗，應先檢查監聽連接埠、核心執行狀態與節點連線，而不是繼續修改瀏覽器選項。

確認 7890 是否正在監聽

Windows PowerShell 可執行以下命令。輸出中的 OwningProcess 是程序識別碼，可在工作管理員的「詳細資料」頁面核對，避免把其他軟體占用的連接埠誤認為 Clash。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS 可使用 lsof，Linux 可使用 ss。若沒有輸出，先確認實際連接埠是否不同，以及設定是否已成功載入。

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

# Linux
ss -lntp 'sport = :7890'

使用 curl 明確指定 HTTP 代理

Windows 請使用 curl.exe，避免部分 PowerShell 環境中的同名別名造成干擾。macOS 與 Linux 只要將命令名稱改為 curl 即可。這裡的 --noproxy "" 用來排除既有略過清單對本次測試的影響。

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

先確認是否連上 127.0.0.1:7890，再查看 HTTPS 的 CONNECT 通道是否建立，最後才檢查目標網站的回應。範例網域僅供連線測試；排查實際問題時，請使用同一個出錯的目標網址。

觀察結果	優先檢查項目
連線至本機 7890 遭拒	核心是否正在執行、連接埠是否一致，以及監聽位址是否可連線。
已連上本機入口，但目標連線逾時	用戶端記錄中的目標、規則、策略組與節點出口。
請求成功，但瀏覽器仍失敗	瀏覽器代理來源、擴充功能、略過清單與既有連線。
指定參數後成功，一般終端機命令失敗	是否已設定環境變數、程式是否支援，以及設定是否被工具本身覆蓋。

CONNECT 成功只能證明代理入口接受了通道請求，無法單獨證明流量經過某個遠端節點。最終路徑仍須依據用戶端連線詳細資料中的規則與鏈路判斷。

第二步：依代理設定來源逐項檢查瀏覽器

先核對作業系統中的實際位址

Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」，查看手動代理位址與連接埠。macOS 可前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「Proxy」。不同系統版本的名稱可能略有差異，重點是檢查目前使用中的網路服務，而非已中斷連線的 Wi-Fi 或網卡。

本機入口通常填入 127.0.0.1，連接埠須與核心監聽的連接埠一致；不要把訂閱網址填進代理伺服器位址欄位。
若使用 PAC 自動設定，請確認自動設定指令碼網址與比對規則。PAC 可能依目標選擇直連，不代表所有網址都會經過同一個入口。
關閉用戶端的系統代理後又自動恢復，可能是其他代理軟體或管理原則重新寫入設定；建議先只保留一個設定來源。

接著排除擴充功能與瀏覽器個別設定

在一般桌面環境中，Chrome 和 Edge 通常會讀取系統代理設定，但代理切換擴充功能、啟動參數與企業原則都可能覆蓋設定。請先停用代理相關擴充功能，完全結束瀏覽器後重新開啟，再測試同一個網址。無痕視窗不一定能排除所有擴充功能，因為擴充功能可能獲准在無痕模式中執行。

Firefox 可在「設定」→「一般」→「網路設定」→「設定」中檢查代理來源。若要沿用作業系統設定，請選擇「使用系統代理設定」；若選擇「手動設定代理」，則須另外核對位址、連接埠與「不使用代理」清單。

公司管理的裝置也應檢查瀏覽器是否受管理。Chrome 的 chrome://policy 與 Edge 的 edge://policy 可用來查看原則是否生效；若受管理原則限制，請向管理員確認，不要反覆覆寫設定。

檢查略過清單與連線重用

瀏覽器與系統通常會略過本機位址、內部網域或指定網段的代理。使用 localhost、路由器管理頁面或公司內部網路位址測試，往往無法判斷公網代理是否正常。修改設定後，既有長連線也可能繼續重用；關閉相關分頁、完全結束瀏覽器再重新啟動，比反覆重新整理同一頁更適合重新測試。

第三步：在終端機個別設定 http_proxy 與 HTTPS_PROXY

用戶端開啟系統代理後，終端機不會自動為所有命令設定環境變數。請先在目前工作階段暫時設定，確認有效後再考慮永久保存。使用 HTTP 代理入口時，即使目標網站採用 HTTPS，代理位址通常仍應寫成 http://127.0.0.1:7890；不要只因變數名稱含有 HTTPS 就改成 https://。

macOS 與 Linux：暫時設定目前的 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 --connect-timeout 10 --max-time 30 -v https://example.com/

# 測試結束後移除這次設定
unset http_proxy https_proxy no_proxy

curl 的 HTTP 代理變數只接受小寫的 http_proxy；其他程式對大小寫的支援可能不同。若同時存在大寫變數、ALL_PROXY 或工具本身的設定，也應一併檢查，避免移除一組變數後仍受其他設定影響。

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

# 測試結束後移除這次設定
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY

這些設定只適用於目前的 PowerShell，以及之後啟動的子程序，不會修改已執行中的 IDE、終端機或背景服務。若原本已有變數值，請先記下來，測試結束後還原原值，不要直接刪除。透過系統介面永久修改變數後，通常需要重新啟動相關應用程式，才能載入新值。

第四步：檢查 Git、WSL 與工具本身的代理設定

如果 curl 正常，但某個工具失敗，不要立刻判定節點無法使用。Git、套件管理器與執行環境可能有各自的代理設定，也可能透過不同網路函式庫處理環境變數。以 Git 為例，先查看所有已定義的設定及其來源：

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

遠端網址使用 SSH：[email protected]:git/git.git 不會經過 Git 的 HTTP 代理流程，須檢查 SSH 本身的連線方式。
WSL 2：在預設 NAT 網路下，Linux 中的 127.0.0.1 指向 WSL 自身，不能直接視為 Windows 主機。鏡像網路模式的行為不同，請依目前的網路模式確認主機可連線的位址。
容器：容器內的迴路位址也不是主機位址。若確實需要跨越網路邊界存取代理，應限制監聽介面與防火牆來源，不要直接對所有網路開放。
sudo 與背景服務：環境變數可能遭到過濾，或服務是由不同帳戶啟動。互動式終端機測試成功，不代表服務程序也有相同的環境。

第五步：請求進入核心後，再檢查規則與出口

在用戶端的連線清單或執行記錄中，依目標網域與測試時間找出本次請求。請記錄目標位址、符合的規則、選取的策略組與實際鏈路。各用戶端介面名稱不盡相同，但這些資訊比「已啟用」狀態更能說明流量的去向。

若看到 DIRECT，先確認是否符合直連規則，或策略組目前是否選了直連。
若請求進入預期的策略組後逾時，請再檢查節點、伺服器端與本機至節點的連線。
若完全沒有相關記錄，先確認記錄層級、篩選條件與請求是否確實送出，再回頭檢查應用程式的代理入口。

短暫將 log-level: debug 調高可取得更多線索，重現問題後請恢復為 info。記錄可能包含網域、內部網路位址與訂閱相關資訊，提供給他人前應先遮蔽敏感資料。不要透過停用 TLS 憑證驗證來「修復」代理；憑證錯誤應分別檢查憑證鏈、系統時間與網路攔截。

何時該考慮 TUN 模式？

應用程式不支援代理設定，或需要接管更多網路流量時，再考慮使用 TUN。系統代理主要仰賴應用程式主動使用代理入口；TUN 則透過虛擬網卡與路由接管流量，涵蓋範圍不同。Clash Meta 後續發展的 mihomo 支援相關功能，但能否使用仍取決於用戶端整合、系統權限與執行環境，不能把所有名為 Clash 的用戶端都視為相同實作。

在 mihomo 環境中，以下僅為欄位關係範例，並非適用於所有裝置的通用設定。部分用戶端會依介面選項產生這些欄位，請優先核對最終生效的設定，避免介面開關與手動輸入的內容互相覆蓋。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

auto-route 涉及路由接管，通常需要管理員權限或相應的網路權限。
auto-detect-interface 用於自動判斷出口介面；若同時使用多張網卡、虛擬網卡或 VPN，仍須核對實際出口。
DNS 接管需要另外檢查 DNS 模組、攔截規則與系統解析路徑；以上四項不代表 DNS 已完整處理。
瀏覽器的安全 DNS、IPv6 與 QUIC／UDP 流量應依實際鏈路判斷，不宜一概視為故障原因。

依測試結果逐步縮小範圍，不要同時變更多個開關

最精簡的排查流程：確認監聽連接埠 → 明確指定代理進行測試 → 核對瀏覽器設定來源 → 檢查終端機環境變數 → 查看用戶端規則與鏈路。只有應用程式確實無法透過一般代理連線時，才進一步評估 TUN。

每次重新測試時，請保留四項資訊：作業系統與用戶端名稱、實際監聽連接埠、完整執行命令，以及同一時間的連線記錄。若明確指定代理後成功、瀏覽器仍失敗，就繼續檢查瀏覽器；若終端機加上參數後成功、不加參數就失敗，就繼續檢查環境變數與工具設定。如此可將「系統代理無效」拆解成可驗證的問題，無須反覆重新安裝用戶端。

需要確認欄位含義，可查看Clash 設定欄位；初次匯入設定與選擇代理模式，可依序參閱入門指南。