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

先釐清：核心運作、系統代理與應用程式請求

用戶端顯示「執行中」，通常只代表代理核心已啟動，不表示瀏覽器正在使用它。節點延遲測試成功，也只能說明該次測試使用的連線路徑可用，無法證明網頁請求走的是同一個節點。排查時，請將以下三個環節分開確認：本機連接埠是否正在監聽、應用程式是否將請求送至該連接埠，以及核心收到請求後如何轉送。

Clash 與 Clash Meta（現稱 mihomo）核心負責接收及轉送連線；桌面用戶端的「系統代理」開關通常用來變更作業系統的代理設定。兩者並非同一個開關。Chrome、Edge 通常會讀取系統代理；Firefox 可另外設定代理；終端機程式則常讀取環境變數或自身設定。

1. 記下用戶端名稱、核心名稱、目前模式及本機監聽連接埠。
2. 使用固定的測試網址，例如 https://example.com/，避免每次測試都更換目標。
3. 開啟用戶端的連線清單和記錄，再送出一次請求，核對時間、網域、規則與出口策略。
4. 一次只調整一個項目。測試後還原暫時變更，並保留調整前後的結果。

步驟一：確認本機代理連接埠能否接受連線

分清 HTTP、SOCKS 與混合連接埠

在用戶端的設定或執行設定檔中，尋找 port、socks-port、mixed-port。選單名稱會因用戶端而異，請以實際生效的設定檔為準。以下僅說明欄位用途，不需要將三種連接埠全數加入現有設定，更不要覆寫訂閱中的節點與規則。

# 欄位範例：以目前核心實際生效的設定為準
port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false

• port：HTTP 代理入口；HTTPS 網站通常會透過 HTTP CONNECT 建立通道。
• socks-port：SOCKS 代理入口，不能直接當成 HTTP 代理連接埠填入。
• mixed-port：同一個入口可接受 HTTP 與 SOCKS 代理連線。

僅在本機使用時，位址建議填寫 127.0.0.1。系統代理指向 7890，但核心只在 7892 監聽，是常見的連接埠設定不一致。請勿為了修復本機連線而啟用「允許區域網路連線」，這個選項不會啟動本機連接埠。

檢查監聽狀態與使用中的處理程序

在 Windows 開啟 PowerShell，先測試連接埠，再查詢監聽處理程序。TCP 測試通過只代表有程式接受連線，還需確認監聽者確實是目前使用的代理核心。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess
# 將查詢到的處理程序 ID 填入；以下 1234 僅供示範
Get-Process -Id 1234

macOS 可使用以下命令；Linux 可執行 ss -lntp，再尋找對應的連接埠。部分處理程序資訊需要適當權限才能顯示。

lsof -nP -iTCP:7890 -sTCP:LISTEN

如果記錄中出現 address already in use，請先退出其他代理用戶端，再重新啟動目前的核心。若調整了監聽連接埠，也要同步更新系統代理、瀏覽器手動代理及終端機變數。不要直接結束用途不明的處理程序，也不要同時執行兩個用戶端搶用同一個連接埠。

步驟二：使用顯式代理測試，縮小故障範圍

先略過系統代理設定，明確指定 curl 使用哪個本機連接埠。這樣可分辨「應用程式沒有使用代理」與「代理本身無法轉送」。Windows 請使用 curl.exe，避免 Windows PowerShell 5.1 中 curl 別名造成參數差異；macOS 和 Linux 則使用 curl。

# Windows PowerShell：明確使用 HTTP 或混合代理連接埠
curl.exe -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

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

# 只有實際 SOCKS 連接埠為 7891 時才使用這一行
curl -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7891 https://example.com/

--noproxy "" 可清除本次請求的略過清單，避免既有的 NO_PROXY 造成干擾。socks5h 會將目標主機名稱交由代理解析；socks5 通常則由本機先解析。兩者結果不同時，可作為 DNS 排查線索，但不能只憑一次差異就判定某個 DNS 服務故障。

HTTPS 測試中看到 200 Connection established，通常只代表 CONNECT 通道已建立，仍需確認後續 TLS 握手及網頁回應。出現 403 也不代表系統代理失效，因為這可能是目標網站的存取政策所致。完整測試結果比單一狀態碼更有參考價值。

步驟三：瀏覽器未走代理，分別檢查系統設定與擴充功能

Windows：檢查目前的系統代理，不要只看用戶端開關

1. Windows 11：前往「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」。Windows 10 的路徑則是「設定」→「網路和網際網路」→「Proxy」。
2. 確認代理位址是目前的本機入口，例如 127.0.0.1，並確認連接埠與核心設定一致。
3. 確認「使用設定指令碼」是否已啟用。指令碼網址屬於 PAC 設定，可能依規則讓部分網域直接連線；請勿與手動代理混為一談，只憑感覺判斷。
4. 檢查代理例外清單。若目標網域列在例外清單中，瀏覽器可能會略過代理。

先關閉其他代理工具的自動接管功能，再切換一次目前用戶端的系統代理開關，觀察系統設定是否隨之變更。公司管理的裝置可能受到組織政策控管；若設定自動還原，請聯絡管理員，不要反覆修改登錄檔。

netsh winhttp show proxy 顯示的是 WinHTTP 代理設定，不等於 Chrome、Edge 正在使用的系統代理狀態。即使 WinHTTP 顯示直接連線，也不能據此判定瀏覽器代理未啟用；也不需要為了讓瀏覽器上網而盲目執行匯入或重設命令。

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

macOS 13 及更新版本可前往「系統設定」→「網路」→目前連線的 Wi-Fi 或乙太網路→「詳細資訊」→「代理」。請確認修改的是目前正在使用的網路服務，而非已中斷連線的介面。檢查 HTTP 網頁代理與 HTTPS 安全網頁代理；若兩者都指向本機 HTTP 入口，連接埠應與用戶端設定一致。

HTTPS 網站使用本機 HTTP 代理入口是正常的，位址不必改成 https://127.0.0.1。一般 Clash 本機 HTTP 入口與用戶端之間通常不會使用 TLS；HTTPS 加密是在通道內進行。

Firefox 與代理擴充功能：一次只保留一個設定來源

在 Firefox 前往「設定」→「一般」→「網路設定」→「設定」，確認是否選擇「使用系統 Proxy 設定」。若使用手動代理，請直接核對位址、連接埠及「不使用 Proxy」清單。Chrome、Edge 也需檢查代理切換擴充功能目前使用的設定檔，以及擴充功能是否受企業政策管理。

• 暫時停用代理切換擴充功能後重新測試；無痕視窗不一定會停用所有擴充功能。
• 完全結束瀏覽器後重新開啟，避免重用舊連線而看不出設定變更。
• 送出測試請求時，觀察用戶端的連線清單。若沒有記錄，可作為入口或略過設定有誤的線索，但也要排除頁面快取、請求未送出及記錄篩選的影響。
• Linux 桌面上的應用程式不一定都遵循系統代理設定；顯式代理測試成功後，再依各應用程式實際支援的方式設定。

步驟四：終端機未走代理，檢查環境變數與工具設定

系統代理不會強制所有處理程序都經過代理轉送。終端機中的 curl、Git、套件管理工具可能會讀取環境變數，也可能使用各自的代理設定。已開啟的終端機或 IDE 不一定會取得之後新增的環境變數，因此請先只在目前工作階段測試，不要一開始就寫入全域設定。

macOS 與 Linux：設定目前的 shell

# 查看現有代理變數，請勿公開包含帳密的輸出內容
env | grep -iE '^(http|https|all|no)_proxy='

# 僅對目前終端機生效，請依實際設定修改連接埠
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 本次請求應讀取上述變數
curl -v --connect-timeout 5 --max-time 20 https://example.com/

# 排查完成後，移除本次新增的變數
unset http_proxy https_proxy

https_proxy 的值使用 http:// 並不矛盾：變數名稱表示目標 URL 使用 HTTPS，變數值則表示如何連線至代理伺服器。curl 的 HTTP 代理變數有大小寫規則，建議優先使用此處的小寫寫法；其他工具支援哪些變數，請參閱該工具的文件。

Windows PowerShell：使用處理程序層級的變數

# 查看目前處理程序中已有的代理環境變數
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|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 5 --max-time 20 https://example.com/

# 僅在這些變數是本次暫時新增時才刪除
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

如果變數原本已有值，請先記錄並在測試後還原，不要直接刪除。特別檢查 NO_PROXY 是否包含目標網域，或是否設為 *；支援此設定的工具可能因此略過所有目標的代理。若設定了 ALL_PROXY，也要確認沒有留下舊的 SOCKS 連接埠。

Git、WSL 與容器：不要假設它們共用同一個入口

可使用以下兩個命令查看 Git 代理值及其來源。來源可能是系統、使用者或儲存庫設定；修正時應調整對應層級，避免只刪除使用者設定，卻漏掉目前儲存庫的設定。若輸出含有使用者名稱、密碼或內部位址，分享前請先遮蔽。

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

WSL、容器及虛擬機器中的 127.0.0.1 不一定指向主機系統。WSL 的 NAT 與鏡像網路行為不同，容器通常也有獨立的網路空間。請先確認執行環境及主機可連線的位址，再判斷是否需要調整監聽位址與防火牆；不要直接將代理公開至所有網路介面。Git 的 SSH 遠端網址也不會因為設定了 HTTP 代理，就自動改走同一條連線路徑。

步驟五：請求已進入 Clash，再檢查規則、DNS 與 TUN

連線清單有記錄：檢查實際使用的出口

用戶端已記錄目標網域時，排查重點應從「系統代理開關」轉向轉送路徑。規則模式會依序比對，命中 DIRECT 就會直接連線；策略群組也可能實際選到直連項目，而非預期的代理節點。查看連線詳細資料中的規則、策略鏈與目標位址，比反覆切換開關更有效。

1. 固定目標位址，記錄目前命中的規則與最終選定的出口。
2. 短暫切換至全域模式，並明確選擇一個代理節點，再向同一個位址送出請求。
3. 若只有全域模式成功，請切回規則模式，檢查對應網域規則、規則集及後備項目。
4. 測試完成後還原原本模式。全域模式僅供比對，不是所有問題的長期解決方案。

可暫時將記錄層級調整為 debug，重現一次後再恢復為 info。遇到 connection refused，需確認遭拒的是本機入口還是遠端服務；遇到 i/o timeout，則需確認逾時發生於 DNS、節點撥號還是目標連線。不要只截取錯誤訊息最後幾個字。

DNS 與 TUN：分別驗證，不要同時變更

顯式 HTTP 代理、SOCKS、本機直接連線、瀏覽器安全 DNS 及 TUN DNS 接管可能使用不同的解析路徑。nslookup 成功只代表該命令使用的路徑能解析，不能證明核心使用相同結果。若請求發生網域解析錯誤，請搭配核心記錄檢查 dns 設定，參閱 DNS 設定說明，不要一次更換所有上游伺服器。

TUN 會透過虛擬網路介面接管符合條件的流量，適合處理不讀取顯式代理設定的程式，但它並不是「加強版系統代理開關」。TUN 也涉及權限、路由、DNS 及其他 VPN 的相容性。系統代理與 TUN 同時啟用時，測試結果可能來自另一個入口。

收尾：保留診斷資料，還原暫時設定

回報問題時，請提供可重現問題的最小資料：作業系統、用戶端與核心版本、HTTP／混合連接埠、是否啟用 TUN、瀏覽器名稱、curl 顯式代理測試結果，以及同一時間的連線詳細資料。版本號請從實際用戶端確認，不要只寫「最新版」。

• 記錄「顯式代理成功、瀏覽器失敗」這類對照結果，不要只寫「連不上」。
• 註明確切時間與目標網域，方便從記錄中找到同一次請求。
• 遮蔽訂閱連結、節點密碼、請求中的 Cookie、授權標頭及敏感查詢參數。
• 還原暫時調整的模式、記錄層級、瀏覽器擴充功能狀態及環境變數。

最後依序確認：連接埠正常監聽後，再測試顯式代理；顯式代理成功後，再分別設定瀏覽器與終端機；請求進入核心後，再檢查規則、節點與名稱解析。每個步驟都能觀察結果，不必一開始就重裝用戶端。