Clash 系統代理無法使用：瀏覽器正常但終端機失敗怎麼辦
逐一檢查系統代理、瀏覽器獨立設定、終端機環境變數與本機監聽連接埠。
先確認瀏覽器使用的代理路徑
「瀏覽器可以存取，但終端機失敗」並不能直接表示 Clash 的系統代理開關失效。瀏覽器與命令列程式可能使用完全不同的網路路徑：瀏覽器可以讀取作業系統代理，也可能使用瀏覽器擴充功能、獨立代理設定或自身的安全 DNS；終端機程式則可能直接連線至目標位址，完全忽略系統代理。
排查的第一步不是反覆切換節點，而是確認瀏覽器流量究竟從哪裡進入 Clash。可以暫時關閉瀏覽器中的代理擴充功能與獨立代理選項，只保留 Clash 的系統代理功能，再重新開啟測試頁面。如果關閉擴充功能後瀏覽器也無法連線，原本成功的流量很可能來自擴充功能，而不是系統代理。
接著查看 Clash 用戶端的連線記錄。造訪一個先前未開啟過的網域，觀察連線清單中是否出現對應網域、目標位址、命中的規則與策略組。如果瀏覽器顯示存取成功，但 Clash 中沒有任何新連線，表示該請求沒有進入目前執行中的 Clash 執行個體。常見原因包括瀏覽器使用其他代理、瀏覽器啟用了獨立 VPN、系統中同時執行多個代理用戶端，或瀏覽器重用了尚未關閉的舊連線。
還應確認瀏覽器與終端機測試的是同一個網域與協定。造訪一般網頁、請求 HTTPS API、連線 Git 儲存庫以及下載軟體套件，可能涉及不同網域、連接埠與規則。某個網頁可用，不代表 Git、套件管理器或遠端 API 使用的目標也受到同一規則正確處理。
檢查 Clash 本機監聽連接埠與協定
終端機要透過 Clash 轉送流量，首先必須連線至正在監聽的本機代理連接埠。不同用戶端的預設值可能不同，匯入設定後也可能被覆寫，因此不要只憑經驗假定連接埠一定是 7890。應在用戶端的連接埠設定、執行記錄或目前生效的設定中確認實際數值。
常見設定會提供 HTTP 連接埠、SOCKS 連接埠或 mixed-port。mixed-port 可以在同一個連接埠接收 HTTP 與 SOCKS 代理連線，適合同時供瀏覽器、curl 與其他工具使用。以下片段僅為結構範例，實際排查時應以用戶端顯示的生效設定為準：
mixed-port: 7890
socks-port: 7891
allow-lan: false
mode: rule設定中出現連接埠不代表程序已成功監聽。連接埠可能被其他程式佔用，Clash 核心也可能因設定載入失敗而未啟動。Windows 可以使用 netstat 或 PowerShell 查看監聽狀態，macOS 與 Linux 可以使用 lsof 或 ss：
netstat -ano | findstr 7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890如果沒有任何監聽結果，應先回到 Clash 用戶端檢查核心執行狀態與記錄，而不是繼續修改終端機設定。若連接埠已被其他程序佔用，需要關閉衝突程式或修改 Clash 連接埠，並同步更新終端機中的代理位址。
確認監聽後，可以讓 curl 明確指定代理。這一步會繞過系統代理與環境變數，快速驗證「終端機到本機連接埠」及「Clash 到目標網站」這兩段路徑是否正常：
curl -I -x http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7891 https://example.com第一個命令使用 HTTP 代理測試，第二個使用 SOCKS5 測試。socks5h 中的 h 表示由代理解析目標網域，有助於區分本機 DNS 問題與代理連線問題。如果明確指定代理後可以成功，Clash 的連接埠與節點大致可用，問題通常集中在系統代理的讀取方式或終端機環境變數。
如果出現「connection refused」，優先檢查連接埠與核心狀態；如果長時間逾時，檢查防火牆、節點連通性與規則；如果收到代理驗證錯誤，則確認所用用戶端是否為本機連接埠設定了驗證資訊。若記錄顯示請求進入 Clash 後由 DIRECT 規則處理，還需要檢查規則順序與最終命中的策略組。
為終端機程式設定代理環境變數
許多命令列工具不會自動讀取桌面作業系統的代理設定，而是尋找 http_proxy、https_proxy 與 all_proxy 等環境變數。變數名稱可能有大小寫差異，實際支援範圍由程式決定。為減少相容性問題，可以同時設定小寫與大寫形式，但應避免在同一個工作階段留下互相衝突的位址。
macOS 與 Linux 暫時設定
在 Bash、Zsh 等 Shell 中，可以只為目前的終端機工作階段匯出代理變數：
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
curl -I https://example.comhttps_proxy 表示處理 HTTPS 目標時使用的代理，不代表變數值必須寫成 https://。本機 Clash 連接埠通常提供 HTTP 代理，因此位址仍常寫作 http://127.0.0.1:7890。如果希望統一使用 SOCKS，可以設定：
export all_proxy=socks5h://127.0.0.1:7891
export ALL_PROXY=socks5h://127.0.0.1:7891Windows CMD 與 PowerShell 暫時設定
CMD 使用 set 設定目前視窗的環境變數：
set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890
curl.exe -I https://example.comPowerShell 則需要寫入目前程序的 Env 範圍：
$Env:http_proxy = "http://127.0.0.1:7890"
$Env:https_proxy = "http://127.0.0.1:7890"
curl.exe -I https://example.com在 PowerShell 中應明確使用 curl.exe 完成測試，避免舊版環境中的命令別名造成測試結果歧義。對於 Invoke-WebRequest，也可以直接指定代理：
Invoke-WebRequest -Uri "https://example.com" -Proxy "http://127.0.0.1:7890"檢查殘留設定與排除清單
修改變數前，應先輸出目前值，確認是否殘留舊連接埠、失效主機名稱或另一款代理軟體的位址。macOS 與 Linux 可以執行 env | grep -i proxy，PowerShell 可以執行 Get-ChildItem Env: | Where-Object Name -Match 'proxy'。
no_proxy 或 NO_PROXY 用於指定不經過代理的位址。若目標網域意外出現在排除清單中，程式會直接連線。常見的合理排除項目包括 localhost、127.0.0.1 與區域網路服務，但過寬的後綴規則可能連帶排除外部網域。
處理系統代理、工具設定與平台差異
系統代理不是所有程式都必須遵守的統一轉送層。它更像是作業系統提供的一組代理參數，應用程式是否讀取、何時讀取以及支援哪些協定，都由應用程式自行決定。瀏覽器通常會讀取系統設定，而 Git、npm、Python 套件管理器、容器程序與部分 Java 程式經常使用自己的設定。
Windows 的系統代理與 WinHTTP
Windows 桌面應用程式常讀取使用者層級的系統代理，而部分系統元件與服務則使用 WinHTTP 設定。兩套設定並不完全相同。因此，瀏覽器正常但以服務身分執行的工具失敗，並不罕見。可以使用以下命令查看 WinHTTP 目前狀態：
netsh winhttp show proxy在尚未確認用途前，不要直接將使用者代理匯入 WinHTTP，因為這會影響依賴它的系統元件。更穩妥的方法是先讓特定命令明確連線至 Clash，確認問題範圍，再決定使用工具自身的設定，或調整系統層級設定。
Git 與套件管理器的獨立代理
Git 可以個別儲存 HTTP 與 HTTPS 代理。如果環境變數正確但 Git 仍然失敗，應檢查是否存在舊設定：
git config --global --get http.proxy
git config --global --get https.proxy需要使用目前 Clash HTTP 連接埠時，可以設定：
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890如果不再需要 Git 獨立代理，應刪除對應項目，而不是將值改成空字串。npm、pnpm、pip、Maven 與 Gradle 也各有設定來源。排查時要同時檢查工具設定檔、環境變數與 IDE 設定，避免同一個請求被多層設定重複覆寫。
代理協定必須與連接埠相符
將 SOCKS 連接埠當作 HTTP 代理使用，或將 HTTP 連接埠寫成 SOCKS 位址，會導致握手失敗。應從 Clash 用戶端確認連接埠類型，再讓工具使用對應的 URL 方案。HTTP 代理通常寫作 http://127.0.0.1:連接埠，SOCKS5 則寫作 socks5:// 或 socks5h://。
還要留意 127.0.0.1 與 localhost 的解析差異。部分環境會優先將 localhost 解析為 IPv6 位址 ::1，但 Clash 可能只監聽 IPv4。排查階段直接使用 127.0.0.1，可以減少這項變數。
檢查 TUN 模式、DNS 與隔離環境
TUN 模式透過虛擬網路介面接管更多流量，通常不要求每個終端機程式個別支援系統代理。但這不代表啟用 TUN 後所有命令都會自動成功。虛擬介面建立權限、路由寫入、DNS 接管、程序繞過規則以及其他 VPN 軟體，都可能影響結果。
如果一般系統代理下 curl 明確指定連接埠可以運作，但啟用 TUN 後直接請求仍然失敗，應檢查 Clash 記錄中是否出現該連線。完全沒有記錄通常表示路由沒有進入 TUN；有連線但網域解析失敗，則應檢查 DNS 設定；連線被規則分配到錯誤策略組時，應回到規則匹配結果進行修正。
Clash Meta，也稱為 Mihomo，支援更完整的 TUN、DNS 與規則功能，但圖形用戶端是否提供相關選項、使用哪種執行權限，取決於用戶端實作。修改 YAML 之前，應確認用戶端是否會在啟動時重新產生設定，避免手動修改被覆寫。
WSL、Docker、虛擬機器與遠端開發容器需要特別處理。它們看到的 127.0.0.1 通常指向自身，而不是主機。主機上的 Clash 即使監聽正常，容器內部存取 127.0.0.1:7890 也可能遭到拒絕。此時需要使用主機在該虛擬網路中的位址，並確認 Clash 允許區域網路連線、監聽位址涵蓋相應介面，同時檢查主機防火牆。
透過 SSH 登入遠端伺服器後，終端機命令會在遠端主機上執行。遠端主機的 127.0.0.1 同樣不是本機電腦。若要讓遠端命令使用本機 Clash，需要建立明確的 SSH 連接埠轉送，或在遠端環境設定可連線的代理，不能直接複製本機環境變數。
依序完成 Clash 終端機代理定位
有效的排查方式是逐層驗證，而不是同時修改系統代理、規則、DNS 與節點。每一步只回答一個問題，並記錄測試結果：
- 確認核心執行：檢查 Clash 用戶端狀態與啟動記錄，確保目前設定已成功載入。
- 確認連接埠監聽：從生效設定讀取 HTTP、SOCKS 或 mixed-port，再使用系統命令確認對應連接埠處於監聽狀態。
- 明確指定代理：使用
curl -x或--proxy直接連線至本機連接埠，排除系統代理讀取問題。 - 查看連線記錄：確認請求進入 Clash，並查看命中的規則、策略組、節點與錯誤資訊。
- 檢查終端機變數：輸出所有與 proxy 相關的變數，刪除舊位址與衝突值，再為目前工作階段設定正確連接埠。
- 檢查工具獨立設定：查看 Git、套件管理器、IDE 與執行環境是否儲存了另一套代理設定。
- 確認執行邊界：判斷命令位於主機、WSL、容器、虛擬機器還是遠端伺服器，確認其中的本機位址實際指向何處。
- 最後檢查 TUN 與 DNS：僅在基礎連接埠測試通過後，再分析虛擬介面、路由與網域解析。
若明確代理測試成功、環境變數測試也成功，但某個特定工具仍然失敗，問題基本上就在該工具本身。此時應開啟工具的詳細記錄，查看它連線的網域、讀取的代理設定以及 TLS 錯誤，而不是繼續更換 Clash 節點。
若所有明確代理測試都失敗，則回到 Clash 端檢查連接埠、設定與節點。可以分別測試多個目標網域，並在連線記錄中比較規則結果。只有部分網域失敗時，重點檢查規則、DNS 與目標服務；所有網域都無法建立連線時，優先檢查本機監聽、核心記錄與代理節點。
完成排查後，應清理不再使用的暫時變數與重複設定，只保留一條明確的代理路徑。系統代理適合桌面應用程式，環境變數適合終端機工作階段，工具獨立設定適合有固定需求的程式，TUN 則適合需要接管更多網路流量的情境。選擇符合目前環境的一層作為主要入口，可以減少連接埠變更與設定衝突造成的故障。