故障排除 預計閱讀 10 分鐘

系統代理已開啟卻無法使用？分別排查瀏覽器與終端機

瀏覽器擴充功能接管代理、終端機未使用系統代理，是兩種常見原因。本文整理檢查順序、環境變數設定方式，以及 TUN 模式替代方案。

先釐清：請求未進入核心，還是規則選擇了直連

「系統代理」只是在作業系統中登記代理伺服器位址與連接埠，不代表整台裝置的所有流量都會交由 Clash 處理。應用程式是否採用這項設定，取決於使用的網路元件；瀏覽器擴充功能、應用程式內的代理選項，以及終端機環境變數，也都可能改變實際連線路徑。

另一種常見誤判是：請求已進入 mihomo 核心，卻被規則分配到 DIRECT。此時出口 IP 沒有變化，是規則判斷的結果，不代表系統代理失效。請先開啟用戶端的「連線」頁面，依目標網域篩選，再檢查符合的規則、策略群組與最終出站。

觀察結果優先檢查項目下一步
連線頁面沒有目標請求應用程式是否使用代理檢查瀏覽器設定，或明確指定代理
出現請求，最終出站為 DIRECT規則順序與策略群組選擇確認該網域是否原本就應直連
請求進入代理群組，但連線逾時節點、目標網站與網路連線狀態換用已知可用的節點進行比對
明確指定代理可用，一般連線卻失敗系統代理接入環節分別排查瀏覽器與終端機

第一步：明確指定代理，確認本機監聽連接埠

先不要修改規則、訂閱或 DNS。請先對同一個目標位址發出明確指定代理的請求，單獨確認核心能否接收請求。Windows PowerShell 請使用 curl.exe，避免 Windows PowerShell 5.1 中的 curl 別名影響參數解析；macOS、Linux 則使用 curl。

# Windows PowerShell
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 通道；同時在用戶端的「連線」或「日誌」中查看對應紀錄。

  • 立即顯示連線遭拒：檢查核心是否正在執行、連接埠是否填錯，以及監聽位址是否包含 IPv4 迴路位址。
  • 已連上本機連接埠，但 CONNECT 後失敗：接著檢查節點、規則、TLS 或目標網站是否可用，不要反覆切換系統代理開關。
  • 收到 HTTP 407：檢查本機代理驗證設定。請勿將含密碼的完整指令貼到公開日誌中。
  • 收到目標網站的 HTTP 回應：表示這次請求已經通過本機代理入口；是否經由遠端節點轉送，仍須以用戶端的出站紀錄為準。

在 Windows 可執行 Get-NetTCPConnection -State Listen -LocalPort 7890 檢查監聽狀態；在 macOS 可執行 lsof -nP -iTCP:7890 -sTCP:LISTEN。如果連接埠已被其他程式占用，請先確認是哪個程序，再關閉衝突程式或變更用戶端連接埠。

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

Chrome 與 Edge：先排除擴充功能接管代理

  1. 在用戶端開啟「系統代理」，確認訂閱已啟用，且目前的策略群組已選取可用節點。
  2. Chrome：開啟「設定」→「系統」→「開啟電腦的代理伺服器設定」；Edge：開啟「設定」→「系統與效能」，找到電腦代理伺服器設定入口。各版本的介面文字可能不同。
  3. Windows 11：前往「設定」→「網路和網際網路」→「代理伺服器」；Windows 10：前往「設定」→「網路和網際網路」→「代理伺服器」。確認手動代理的位址與連接埠是否和用戶端設定一致。
  4. 開啟 chrome://extensions/ 或 edge://extensions/，暫時停用具有代理控制功能的擴充功能，包括會自動切換代理設定的擴充功能。
  5. 完全結束瀏覽器後重新開啟，再連線至同一個測試位址，並查看用戶端的連線紀錄。

無痕視窗無法充分隔離測試：擴充功能可能獲准在無痕模式中執行，系統層級設定也仍然有效。更可靠的比較方式，是建立一個未設定代理擴充功能的瀏覽器設定檔。如果頁面顯示「由貴組織管理」，也請檢查 chrome://policy/ 或 edge://policy/；受管理的裝置應由管理員調整政策。

Firefox：明確選擇代理來源

在 Firefox 前往「設定」→「一般」→「網路設定」→「設定」。選擇「使用系統代理設定」，才能與用戶端寫入的系統代理保持一致。若選用「手動設定代理伺服器」，則須自行維護 HTTP 代理位址、連接埠與 HTTPS 代理選項。既有的 SOCKS 設定不會因為開啟系統代理而自動失效。

macOS 可前往「系統設定」→「網路」→目前的網路連線→「詳細資訊」→「代理伺服器」，檢查 Web 代理與安全 Web 代理。Linux 桌面環境的代理設定是否會被應用程式採用，取決於桌面環境與應用程式的實作；不能只憑桌面開關就認定所有瀏覽器都已生效。

終端機排查：設定 HTTP_PROXY 與 HTTPS_PROXY

終端機程式通常不會自動採用桌面系統代理。curl、Git 與套件管理工具也可能讀取各自的設定檔。若瀏覽器可以連線、終端機卻失敗，請先為目前的終端機工作階段設定環境變數，避免一開始就修改系統層級環境。

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

# 測試結束後清除本次設定
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXY 指定 HTTPS 目標請求應使用哪個代理，不代表本機代理位址必須寫成 https://。常見的 HTTP 或混合監聽連接埠會使用 http://127.0.0.1:7890，再透過 CONNECT 轉送 HTTPS 連線。

macOS 與 Linux：留意變數大小寫

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

# 測試結束後清除本次設定
unset http_proxy https_proxy no_proxy

在區分大小寫的環境中，curl 的 HTTP 代理只接受小寫的 http_proxy，其他程式讀取變數的規則也可能不同。請先用上方的最小設定進行驗證，再依照目標工具的文件設定大寫變數。如果原本已設定代理變數，請先記下原值，測試後再還原，不要直接刪除原有的可用設定。

環境變數只會影響目前的程序，以及之後啟動的子程序。已開啟的 IDE 終端機、背景工作與系統服務不會因此自動更新。若需要永久設定，請再將設定加入對應 shell 的啟動檔，重新開啟終端機後確認；代理關閉時，請勿留下失效的固定位址。

應用程式獨立設定：Git、SOCKS 與隔離環境

Git：檢查殘留代理，先別急著覆寫全域設定

Git 的 HTTP 傳輸可能同時受環境變數與 Git 設定影響。請先查看設定來源，確認是否殘留舊連接埠、遠端代理位址，或依 URL 指定的設定。輸出內容可能包含驗證資訊，分享前請先遮蔽敏感資料。

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

# 僅為這次 Git 指令指定代理
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

第二條指令只會驗證 Git 的 HTTPS 連線路徑，不會寫入全域設定。以 git@ 開頭的 SSH 儲存庫位址使用另一種傳輸方式，不會因為設定 http.proxy 就自動經由 HTTP 代理連線。

SOCKS：區分本機解析與代理端解析

如果用戶端只有 SOCKS 監聽連接埠，就不能將它當成 HTTP 連接埠使用。假設已確認 SOCKS 連接埠為 7891，可執行下列指令；若使用混合連接埠，請替換成該連接埠的實際值。

curl --proxy socks5h://127.0.0.1:7891 --noproxy "" --connect-timeout 10 --max-time 20 https://example.com/

curl 中的 socks5h:// 會將目標網域交由 SOCKS 代理端解析；socks5:// 通常則由本機先行解析。這項差異有助於判斷本機 DNS 是否故障，但不能據此認定所有應用程式的 DNS 查詢都已由代理接管。

WSL、容器與虛擬機也有位址邊界問題：其中的 127.0.0.1 不一定指向主機。WSL 的 NAT 與鏡像網路模式行為不同，請依實際模式確認主機位址。若需跨網路存取監聽連接埠，再評估「允許區域網路」、監聽位址與防火牆範圍；請勿直接將代理連接埠暴露於公用網路。

TUN 模式：處理不讀取代理設定的應用程式

如果應用程式既不讀取系統代理，也不支援明確指定代理，可以考慮使用 mihomo 用戶端提供的 TUN 模式。TUN 透過虛擬網路介面與路由引導 IP 流量，接入層級與 HTTP 系統代理不同；它並不是讓瀏覽器「更強制地讀取系統設定」。

  1. 先透過明確指定代理確認節點、訂閱與規則可用，再匯出目前設定並保留備份，以便還原。
  2. 在用戶端「設定」中找到「服務模式」，依照提示安裝或啟用服務；部分用戶端採用其他提升權限的方式，請以目前版本的介面為準。
  3. 開啟「TUN 模式」，並檢查日誌中的虛擬介面與路由是否成功建立。涉及的 auto-route、DNS 接管與介面偵測設定，應與用戶端產生的設定保持一致。
  4. 先關閉其他 VPN 或類似的虛擬網卡流量接管功能，避免預設路由互相競爭；接著測試瀏覽器、終端機、區域網路裝置與內部網站。
  5. 若發生網路中斷，請先關閉 TUN，再還原原有的系統代理設定。故障時請勿同時重設 DNS、路由與規則。

TUN 是否會接管特定應用程式，取決於路由、排除項目、網路介面與權限。UDP、QUIC 等流量能否正常轉送，也取決於核心設定與節點支援狀況。啟用 TUN 後，規則仍可能選擇 DIRECT；「流量進入 TUN」與「最終經由遠端節點連線」仍是兩件不同的事。

重新測試順序：每次只變更一個變數

排查完成後，請使用相同的目標、節點與規則模式進行比對。不要只憑某個網頁能否開啟，或單次出口 IP 查詢就下結論：快取、略過清單與目標網域的分流規則都可能影響結果。

  • 本機入口：明確指定 127.0.0.1:7890 後，用戶端是否有記錄到該請求。
  • 瀏覽器：停用代理擴充功能並確認代理來源後，連線紀錄中是否出現請求。
  • 終端機：設定目前工作階段的環境變數後，目標工具是否成功送出相同請求。
  • 出站選擇：請求實際符合哪條規則，以及策略群組最終選取了哪個節點。
  • 還原檢查：關閉用戶端後，是否需要移除終端機代理變數；關閉 TUN 後，內部網路存取與 DNS 是否恢復正常。

提交故障紀錄時，請保留作業系統版本、用戶端與核心版本、實際監聽連接埠、失敗指令、發生時間及相關日誌片段。請刪除訂閱網址、驗證資訊與敏感網域。若要進一步檢查規則與 DNS，請參閱故障排除手冊；系統代理、策略群組與 TUN 的差異，則可查看概念速查。

下載Clash