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

先確認代理入口，再檢查應用程式設定

先維持目前設定不變，使用明確指定代理的請求測試本機連接埠。開啟系統代理，只代表用戶端嘗試將代理位址寫入作業系統設定；這無法證明核心正在監聽，也不保證所有應用程式都會讀取這項設定。瀏覽器、命令列工具與虛擬網卡是不同的流量入口，混在一起排查容易把正常的直連規則誤判為代理失效。

先確認三項基準

1. 確認用戶端核心正在執行，且目前設定檔已啟用。匯入訂閱後若沒有切換至該設定檔，不代表規則已載入。
2. 記下目前的 HTTP 或 mixed 連接埠、執行模式及所選的策略組節點。排查期間先關閉 TUN，避免多種流量路徑互相影響。
3. 開啟用戶端的「連線」與「日誌」頁面，再對同一個目標發出請求。留意目標網域、命中的規則與最終策略，不要只看開關顏色。

不同用戶端的選單名稱可能不同。設定檔中的 port 代表 HTTP 代理入口，socks-port 代表 SOCKS 入口，mixed-port 則同時支援 HTTP 與 SOCKS。用戶端可能會覆寫這些值，請查看最終執行設定，而非只看訂閱原始內容。若只供本機使用，無須為了排查而開啟「允許區域網路連線」。

使用 curl 明確指定代理，區分連接埠故障與規則直連

在 Windows PowerShell 中請使用 curl.exe，避免 Windows PowerShell 5.1 的 curl 別名呼叫到 Invoke-WebRequest。macOS 與 Linux 可直接使用 curl。以下連線至 example.com 僅用來確認請求路徑，不適合用來判斷地區解鎖或測量節點速度。

Windows：明確指定 HTTP 代理

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

macOS / Linux：使用相同目標再次測試

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

--noproxy "" 會清除這次請求的略過清單，避免現有的 NO_PROXY 造成干擾。詳細輸出應先顯示已連線至 127.0.0.1:7890，接著對 HTTPS 目標發出 CONNECT example.com:443。若隧道成功建立，表示請求已進入本機代理；但仍須搭配用戶端連線紀錄，確認最終使用代理節點或 DIRECT。

Windows 可執行 Get-NetTCPConnection -LocalPort 7890 -State Listen 查看監聽狀態與所屬程序；Linux 可執行 ss -ltnp 'sport = :7890'；macOS 可執行 lsof -nP -iTCP:7890 -sTCP:LISTEN。若發現連接埠由其他程式占用，應先處理衝突，不要反覆更新訂閱。

單獨排查瀏覽器：擴充功能、系統代理與 PAC

明確指定代理的測試通過後，再檢查瀏覽器。Chrome 與 Edge 通常會讀取系統代理，但擴充功能、啟動參數及組織政策可能覆寫設定；Firefox 另有獨立的連線設定。瀏覽器能開啟網頁，不代表正在使用代理；快取頁面與規則直連都可能造成誤判。

先檢查作業系統中的代理設定

• Windows 11：前往「設定」→「網路和網際網路」→「Proxy」，檢查「手動 Proxy 設定」中的位址與連接埠。使用本機 HTTP 入口時，位址為 127.0.0.1，連接埠須與用戶端設定一致。
• macOS 13 及後續版本：前往「系統設定」→「網路」→目前使用的連線→「詳細資訊」→「Proxy」。分別檢查網頁 Proxy、安全網頁 Proxy 或自動 Proxy 設定，並確認修改的是目前使用的網路服務。
• Firefox：前往「設定」→「一般」→「網路設定」→「設定」，確認是否選取「使用系統 Proxy 設定」。若使用手動 Proxy，請記下位址、連接埠及不使用 Proxy 的位址清單。

Windows 的 netsh winhttp show proxy 查看的是 WinHTTP 設定，不能直接代表瀏覽器正在使用的使用者代理設定。不要因為這裡顯示直接連線，就認定用戶端沒有寫入系統代理；也不要為了解決瀏覽器問題而先修改整台電腦的 WinHTTP 設定。

暫時停用可控制代理的擴充功能

開啟 Chrome 的 chrome://extensions/ 或 Edge 的 edge://extensions/，暫時停用具有代理控制功能的擴充功能，再完全關閉並重新啟動瀏覽器。無痕視窗不一定能隔離代理設定來源，也不保證所有擴充功能都已停用。若裝置由組織管理，請查看 chrome://policy/ 或 edge://policy/；受政策管理的設定應交由管理員確認。

PAC 傳回 DIRECT 時，本機核心不會收到該請求

PAC 是瀏覽器端的代理選擇指令碼，與 Clash 核心中的規則屬於不同層級。PAC 傳回 DIRECT 時，瀏覽器會直接連線；傳回 PROXY 127.0.0.1:7890 時，才會將請求交給本機 HTTP 入口。若 PAC 設為 PROXY 127.0.0.1:7890; DIRECT，代理無法使用時也可能改為直連。

排查時可暫時停用自動設定指令碼，只保留一組手動代理設定，重新啟動瀏覽器後再對同一個目標發出請求。記下舊的 PAC 位址，以便還原；不要同時啟用兩種設定，再猜測哪一種優先。若用戶端完全沒有瀏覽器請求紀錄，但有明確指定代理的 curl 紀錄，請優先檢查瀏覽器的略過清單與 PAC，而非調整規則集。

單獨排查終端機：環境變數與工具設定

終端機程式不一定會讀取系統代理。curl、Git 與套件管理工具各有不同的設定來源；即使系統代理已開啟，仍直接連線也很常見。先檢查目前終端機的環境變數，再檢查工具專用設定；已在執行的程序通常不會自動取得之後才修改的環境變數。

macOS / Linux：只為單一指令設定代理

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
curl -v --noproxy "" --max-time 20 https://example.com/ -o /dev/null

此處 https_proxy 的值仍以 http:// 開頭，表示先連線至本機 HTTP 代理，再透過 CONNECT 建立通往 HTTPS 網站的隧道。不要因為目標網址使用 HTTPS，就把本機代理位址改成 https://127.0.0.1:7890；一般 HTTP 代理連接埠並未提供 TLS 代理入口。

curl 使用小寫的 http_proxy 環境變數設定 HTTP 代理；其他變數是否支援大小寫，則因工具而異。若 NO_PROXY 或 no_proxy 包含目標網域、位址範圍或 *，請求可能會略過代理。保留必要的本機略過項目並逐一確認，不要永久清空所有略過規則。

PowerShell：設定目前工作階段的代理變數

Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$env:HTTP_PROXY = 'http://127.0.0.1:7890'
$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
curl.exe -v --noproxy "" --max-time 20 https://example.com/ -o NUL

以上設定只會影響目前的 PowerShell 及之後啟動的子程序，無法更新已在執行的 IDE、終端機分頁或背景工作。若要取消測試，而且這些變數原本不存在，可使用以下指令；若原本已有值，請還原先前記錄的舊值。

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY -ErrorAction SilentlyContinue

Git 能否連線，須檢查 Git 自己的代理設定來源

git config --show-origin --get-regexp '.*proxy.*'

此指令會顯示儲存庫、本機使用者或系統層級設定中的代理相關項目。請留意，也可能存在針對特定 URL 的設定；若沒有符合的項目，指令可能以非零狀態結束，這不代表 Git 已損壞。HTTPS 儲存庫與 SSH 儲存庫使用不同的傳輸機制，http.proxy 無法直接解決 SSH 連線問題。npm、pip 等工具也須分別確認設定，不能因為 curl 成功，就推論所有開發工具都已使用代理。

檢查規則與 DNS：流量進入核心不代表使用了節點

瀏覽器或終端機的請求出現在連線清單後，排查方向就應從「入口問題」轉為「路由問題」。規則模式會依序比對規則，再交由對應的策略或策略組處理。命中 DIRECT、選到直連成員，或優先符合程序規則，都可能使流量仍經由本機網路送出。

1. 找出剛才測試的目標，記下命中的規則、策略鏈與所選節點，不要只看策略組名稱。
2. 確認執行模式不是直連模式。使用規則模式時，請檢查規則順序，尤其留意排在前面的網域、程序與位址規則。
3. 必要時可短暫切換至全域模式，並確認全域策略選取了可用的代理節點。對同一個目標重新發出請求後，請切回原有模式。全域測試只用於排除規則因素，並非永久解決方法。
4. 若請求進入核心後回報解析失敗，再檢查 DNS 設定與日誌；不要同時更換節點、DNS 與規則集。

瀏覽器的安全 DNS 設定可能影響網域解析路徑，但不足以證明流量「繞過 HTTP 代理」。使用 HTTP CONNECT 時，瀏覽器可以將目標網域交給代理處理；TUN 則還涉及 DNS 接管與網域對應。請依據連線紀錄判斷請求走向，不要只憑 DNS 設定推論。修改 Fake-IP 設定後，也可能需要重新建立連線；既有長連線無法代表修改後的結果。

何時啟用 TUN：處理不讀取代理設定的應用程式

若明確指定代理、瀏覽器系統代理與終端機變數都已確認正常，只有部分不讀取代理設定的應用程式仍直接連線，再考慮啟用 TUN。TUN 透過虛擬網卡與路由接管指定範圍的流量，和系統代理是不同的開關；它也無法補救節點無法使用、訂閱錯誤或規則設為直連等問題。

從權限、路由與 DNS 三方面檢查

• 權限與服務：依照用戶端提示安裝或啟動所需服務，並確認虛擬網卡已成功建立。Windows、macOS 與 Linux 的權限機制各有不同，不應一概套用同一套操作。
• 路由接管：檢查目前執行設定中的 tun.enable、auto-route 等項目與日誌。即使已建立 TUN 網卡，也不代表所有目的位址或協定都會經過該網卡。
• DNS 與衝突：檢查是否有其他 VPN、虛擬機器網路或企業安全軟體同時變更路由與 DNS。每次只停用一種來源，並記下還原方式，以免影響正常的公司網路。

桌面用戶端可以代為管理部分 TUN 設定；若直接部署 mihomo 核心，則須自行確認權限與執行設定。若遇到區域網路裝置無法連線、DNS 逾時，或啟用 TUN 後完全無法上網，請先關閉 TUN，恢復已確認正常的系統代理路徑，再檢查路由與 DNS。不要把所有問題都歸咎於「需要以系統管理員身分執行」。

依測試結果縮小問題範圍，避免反覆重新安裝

最有效的排查紀錄包含四項：本機入口是否可連線、目標請求是否出現在核心、命中哪種策略，以及哪個應用程式發生問題。針對同一個目標分別測試明確指定代理的 curl、瀏覽器與應用程式，可減少不同網站、快取及節點狀態造成的干擾。

• 明確指定代理的 curl 也失敗：先修復連接埠、核心執行狀態或後續節點鏈路。
• 明確指定代理的 curl 成功，但瀏覽器沒有連線紀錄：優先檢查擴充功能、PAC 與瀏覽器的代理設定來源。
• 瀏覽器成功，終端機失敗：檢查目前程序的環境變數、略過清單與工具專用設定。
• 請求都有紀錄，但出口仍是直連：確認規則與策略選擇，不要再修改系統代理。
• 只有特定應用程式直接連線：確認該程式是否支援代理，再決定要個別設定或啟用 TUN。

向他人提供排查資訊時，可附上作業系統版本、用戶端與核心版本、實際監聽連接埠，以及已移除敏感資訊的錯誤日誌。請刪除訂閱網址、存取權杖、節點密碼與私人目標網域。若仍無法找出原因，可繼續查看故障排除說明；還原代理設定後，再參考使用指南整理日常設定。