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

先透過明確指定代理的請求判斷故障環節

開啟「系統代理」只代表用戶端嘗試將代理位址寫入作業系統設定，不代表所有應用程式都會讀取這項設定。mihomo 核心是否正在執行、應用程式是否連上本機連接埠，以及規則是否選用代理節點，是三個彼此獨立的問題。先測試一次不依賴瀏覽器設定的明確代理請求，再分別處理瀏覽器與終端機。

以下統一以本機混合連接埠 7890 為例。請先從用戶端的連接埠設定或目前生效的設定檔確認實際值，範例連接埠不一定是所有 Clash 用戶端的預設值。Windows PowerShell 請使用 curl.exe，避免舊版 Windows PowerShell 將 curl 解讀為其他命令。

# macOS / Linux
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com

# Windows PowerShell
curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com

• 連線遭拒：優先檢查核心、監聽連接埠及所屬程序，先別急著更換 DNS。
• 成功連上本機代理，但後續逾時：檢查用戶端連線記錄、命中規則、策略群組與節點。
• 收到網站的 HTTP 回應：表示這次明確指定代理的請求已完成；仍須確認實際使用的是代理出站，而非規則中的 DIRECT。

檢查連接埠、核心與程序占用情形

成功匯入訂閱，不代表本機代理已成功監聽。用戶端介面可能正常開啟，但核心可能因設定錯誤而退出；也可能有其他代理程式先占用了連接埠。先確認目前設定已啟用，再查看核心啟動記錄中的監聽資訊。

確認設定欄位

# 本機監聽範例，並非可直接連線的完整設定
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 會在同一個連接埠接受 HTTP 與 SOCKS 代理請求。若分開設定，port 對應 HTTP 代理，socks-port 對應 SOCKS 代理，兩者不可混用。上方片段沒有節點、策略群組或規則，不能取代訂閱；圖形介面用戶端也可能透過覆寫產生執行中的設定，請以最終生效值為準。

查看 7890 連接埠的監聽程序

# Windows PowerShell：查看監聽程序的 PID
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：查看程序名稱與 PID
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看監聽位址與程序資訊，部分資訊需要權限
ss -lntp 'sport = :7890'

在 Windows 上，可將查到的 PID 填入 Get-Process -Id 1234；其中 1234 僅為範例。若監聽程序屬於舊用戶端，請先正常結束舊程式，再啟動目前的核心。不要直接終止用途不明的系統程序。若查不到監聽結果，請檢查記錄中的設定解析錯誤、連接埠繫結失敗及核心退出原因。

若本機請求使用 localhost，也要留意它可能會解析為 IPv6 回環位址 ::1，但核心可能只監聽 IPv4。排查時先固定使用 127.0.0.1，確保位址與監聽結果一致。

瀏覽器排查：系統設定、擴充功能與 PAC

明確指定代理可以使用，但瀏覽器無法連線時，通常要檢查瀏覽器採用哪一套代理設定。不同瀏覽器、桌面環境與企業政策的行為不盡相同，不能只看用戶端開關的顏色。

1. Windows 11：前往「設定」→「網路和網際網路」→「Proxy」。檢查「使用 Proxy 伺服器」的位址與連接埠，並確認「使用設定指令碼」是否已啟用。
2. macOS：前往「系統設定」→「網路」→目前使用的網路服務→「詳細資訊」→「代理伺服器」。確認網頁代理伺服器、安全網頁代理伺服器與自動代理設定。
3. Chrome：在網址列輸入 chrome://settings/system，開啟電腦的代理設定；接著前往 chrome://extensions，檢查可控制代理的擴充功能。
4. Firefox：前往「設定」→「一般」→「網路設定」→「設定」。明確選擇「使用系統代理設定」，或手動填入與核心一致的 HTTP、HTTPS 代理位址。

先排除重複控制，再檢查 PAC

代理切換擴充功能可能會覆寫系統設定。請先暫時停用相關擴充功能，完全結束瀏覽器後重新開啟，再查看用戶端的連線清單。無痕視窗不一定能排除擴充功能的影響，因為擴充功能可能已獲准在無痕視窗中執行。

PAC 是依據請求網址決定使用代理或直接連線的指令碼，並非「所有流量都走代理」的開關。例如，指令碼回傳 DIRECT 時，瀏覽器就不會連線至本機代理。排查時先記下原本的設定，暫時只保留一種控制方式，避免自動指令碼、手動代理與擴充功能規則互相疊加。受公司或機構政策管理的裝置，請先聯絡管理員，不要刪除組織部署的設定。

在 Windows 上，可於 PowerShell 執行以下命令，查看目前使用者的部分代理設定。這些結果可協助判斷設定來源，但不代表所有瀏覽器最終都會採用這些設定：

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

netsh winhttp show proxy 顯示的是 WinHTTP 代理設定，不能據此判定 Chrome 使用的系統代理已啟用或停用。混淆這兩套設定，容易誤以為「命令顯示直接連線，但瀏覽器確實使用代理」。

終端機排查：明確設定代理環境變數

多數命令列工具不會自動讀取桌面系統代理。瀏覽器已能連上目標網站，但終端機中的 curl、Git 或套件管理工具仍然失敗，兩者並不矛盾。先使用暫時性的環境變數，不要立即修改全域設定；確認有效後，再決定是否寫入 shell 啟動檔。

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

# 查看是否仍有舊設定
env | grep -iE '^(http|https|all|no)_proxy='

https_proxy 這個變數名稱表示目標網址使用的通訊協定，變數值不必以 https:// 開頭。連線至本機 HTTP 代理時，請使用 http://127.0.0.1:7890；HTTPS 請求會透過 CONNECT 建立通道。若將通訊協定改成 HTTPS，反而可能要求本機連接埠提供尚未啟用的 TLS 代理服務。

基於安全考量，curl 不會使用大寫的 HTTP_PROXY 作為 HTTP 代理變數，使用小寫格式較穩妥。其他程式對大小寫的判讀方式可能不同；若已有大寫變數或 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 -I --connect-timeout 10 --max-time 20 https://example.com
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

這些設定只會影響目前的 PowerShell，以及之後由它啟動的子程序，不會自動修改已在執行的編輯器或其他終端機。Windows Terminal 中先前開啟的其他分頁，也不會自動同步設定。WSL、容器與遠端 SSH 工作階段都是獨立環境，其中的 127.0.0.1 不一定指向主機的代理；不要為了解決這個問題，直接將代理開放給所有網路介面。

還原暫時設定

# macOS / Linux
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

# Windows PowerShell
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

若原本使用公司代理，請還原先前記錄的設定值，不要直接清空。關閉目前的 shell 也會捨棄這次的暫時修改；若已將內容寫入 ~/.zshrc、~/.bashrc 或 PowerShell 設定檔，則須另外修改。

只有單一工具失敗：檢查應用程式層級的覆寫設定

環境變數生效後，若仍只有某個工具失敗，請檢查該工具本身的代理設定。應用程式層級的選項可能會覆寫環境變數，背景服務也可能根本沒有繼承目前 shell 的環境。以 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

命令使用的是公開儲存庫。測試私有儲存庫時，驗證錯誤不能直接判定為代理故障。Git 的 HTTPS 傳輸可以使用 HTTP 代理，但以 git@ 開頭的 SSH 遠端位址使用不同的傳輸路徑，不會因設定 http.proxy 就自動透過同一代理連線。

同樣地，npm、Python 套件管理工具、Java 應用程式與容器建置，可能分別讀取設定檔、命令列參數或服務環境。先用 curl 作為基準確認連線，再排查特定工具。不要為了排查網路問題而停用 TLS 憑證驗證；若出現憑證錯誤，請檢查系統時間、信任鏈，以及組織網路中的憑證設定。

請求進入 mihomo 後：確認規則與節點

用戶端連線清單已出現目標網域，只能證明請求已進入核心，不能代表使用了預期的節點。規則模式會依序比對，前面的 DIRECT 規則、策略群組目前選取的 DIRECT，以及最後的 MATCH，都可能改變出站路徑。

• 檢查模式：確認目前使用規則模式；若暫時切換至全域模式進行對照測試，也要確認全域策略實際選用代理節點，測試結束後再切回原模式。
• 檢查命中規則：記下目標網域、符合的規則與最終策略鏈。訂閱引用的策略群組名稱必須與實際定義一致。
• 檢查節點：延遲測試成功只代表測試網址當時可連線，不保證所有網域、連接埠與通訊協定都能使用。
• 確認錯誤階段：本機連線失敗、節點連線逾時、DNS 解析失敗與 TLS 交握錯誤，應分別處理，不要一概歸因於「代理無效」。

需要比較對外 IP 時，可對同一個 IP 查詢服務分別執行直接連線與代理請求，再比對連線記錄。兩次查到的對外 IP 相同，不一定表示系統代理未生效：規則可能讓該查詢網域直接連線，TUN 也可能接管看似直接連線的請求。測試時記下 TUN 狀態與策略，避免同時變更多個變數。

# 不使用 curl 的應用程式層代理；啟用 TUN 時仍可能接管這次請求
curl --proxy "" --noproxy "*" --max-time 20 https://api.ipify.org

# 明確使用本機 HTTP 代理
curl --noproxy "" -x http://127.0.0.1:7890 --max-time 20 https://api.ipify.org

何時該使用 TUN，何時繼續修復系統代理

若問題只出現在瀏覽器，且明確指定代理的測試已成功，應先修復瀏覽器設定；若終端機工具支援代理變數，透過工具設定通常更容易定位問題。TUN 適用於需要接管不讀取系統代理的應用程式，或需要涵蓋更多 IP 流量的情境，但不應作為排查所有問題的第一步。

TUN 模式透過虛擬網卡與路由接管流量，通常也涉及權限、DNS 與路由設定。它無法自動修復失效的節點、錯誤的訂閱或規則，也不保證能避開其他 VPN 與安全軟體的網路政策。請先關閉其他同類型的流量接管程式，記錄目前的路由與 DNS 狀態，再依照用戶端說明啟用。

若要進一步回報問題，請保留作業系統版本、用戶端與 mihomo 核心版本、實際監聽連接埠、失敗的命令及錯誤發生時段。分享記錄前，請移除訂閱 URL、存取權杖與節點憑證。完整設定項目請參閱完整文件；基本匯入與流量接管步驟請參閱使用教學。