故障排查 預計閱讀 13 分鐘

系統代理已開卻未生效？瀏覽器與終端機分開排查的完整流程

瀏覽器會使用系統代理，終端機卻預設不會；本文依序檢查瀏覽器設定、終端機環境變數、export 寫法、連接埠衝突與繞過清單。

先確認問題發生在哪一層

「系統代理已啟用」只代表 Clash 用戶端嘗試將作業系統的代理位址改為本機監聽連接埠，不代表所有應用程式都會讀取這項設定。Chrome、Edge 與 Safari 通常會遵循系統代理；Firefox 可以使用自己的連線設定；curl、Git、npm、Python 套件管理器及多數終端機程式則可能直接連線網路。排查時應先區分瀏覽器、終端機與 Clash 核心，而不是反覆切換節點。

開始前先在用戶端確認三件事：設定檔已啟用、策略群組中有可用節點、核心處於執行狀態。不同用戶端的選單名稱略有差異，常見路徑是「設定」→「目前設定」、「代理」→「策略群組」以及「設定」→「系統代理」。如果記錄頁完全沒有新連線，問題通常位於應用程式與本機代理連接埠之間；如果記錄出現連線但顯示逾時、規則錯誤或節點失敗，再處理設定與遠端節點。

用四種現象快速定位

現象 優先檢查 常見原因
所有網頁都無法開啟 Clash 監聽連接埠與系統代理位址 核心未啟動、連接埠填錯或連接埠已被佔用
瀏覽器可用，終端機失敗 終端機環境變數與程式本身的設定 命令列工具未讀取系統代理
瀏覽器只有部分網站失敗 規則命中、繞過清單與擴充功能 網域直接連線、代理擴充功能覆寫系統設定
啟用 TUN 後可用，系統代理模式失敗 應用程式是否支援 HTTP 或 SOCKS 代理 應用程式繞過系統代理直接建立連線

核對 Clash 監聽連接埠與系統代理位址

Clash 常見的本機監聽形式包括 HTTP 連接埠、SOCKS5 連接埠與 mixed-port。較早期的設定常將 HTTP 設為 7890、SOCKS5 設為 7891；mihomo 設定也經常只啟用 mixed-port: 7890，讓同一連接埠同時接收 HTTP 與 SOCKS5 請求。連接埠並非固定值，最後應以用戶端「設定」→「連接埠設定」或目前設定中的實際數值為準。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

這段設定表示代理只監聽本機 127.0.0.1:7890。系統代理中的伺服器位址也應指向 127.0.0.1，HTTP 與 HTTPS 可以填寫同一個 mixed 連接埠。不要把訂閱節點的遠端位址填入作業系統代理設定，也不要把 Clash 的控制連接埠誤當成流量連接埠。

Windows 11 檢查路徑

  1. 開啟「設定」→「網路和網際網路」→「代理」。
  2. 確認「使用代理伺服器」是否已啟用。
  3. 核對位址是否為 127.0.0.1，連接埠是否與 Clash 目前的監聽連接埠一致。
  4. 如果用戶端使用自動設定指令碼，確認「使用設定指令碼」中的位址仍然有效。
  5. 切換系統代理後，關閉並重新開啟出問題的應用程式，避免它繼續使用舊的連線集區。

macOS 檢查路徑

  1. 開啟「系統設定」→「網路」。
  2. 選擇目前使用中的 Wi-Fi 或乙太網路連線。
  3. 進入「詳細資訊」→「代理伺服器」。
  4. 核對網頁代理 HTTP、安全網頁代理 HTTPS 與 SOCKS 代理的位址及連接埠。
  5. 如果 Clash 用戶端負責接管設定，不要同時保留另一款代理工具寫入的舊連接埠。

直接測試連接埠是否正在監聽

Windows 可以在 PowerShell 中執行以下指令。出現 Listen 或可以建立 TCP 連線，表示本機連接埠已開啟；連線失敗則應先重新啟動核心或解決連接埠衝突。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

macOS 與 Linux 可以使用 lsof 查看監聽程序：

lsof -nP -iTCP:7890 -sTCP:LISTEN
nc -vz 127.0.0.1 7890

如果監聽者不是目前的 Clash 或 mihomo 程序，先退出佔用連接埠的舊用戶端，再啟動正在使用的用戶端。也可以在「設定」→「連接埠設定」中改用未佔用的連接埠，例如 7892，接著重新啟用系統代理，讓作業系統同步新值。

瀏覽器未生效時逐項排查

Chromium 系列瀏覽器通常會讀取作業系統代理，但瀏覽器擴充功能、企業原則與獨立使用者設定都可能改變實際路徑。排查時建議先開啟一般視窗，暫時停用負責切換代理的擴充功能，再造訪目標頁面。無痕視窗不一定會停用所有擴充功能，應在擴充功能管理頁確認其狀態。

Chrome 與 Edge

  • Chrome 可進入「設定」→「系統」→「開啟電腦的代理設定」，確認它跳轉至目前系統的代理頁面。
  • Edge 可進入「設定」→「系統與效能」→「開啟電腦的代理設定」。
  • 完全退出瀏覽器程序後重新開啟。只關閉一個分頁不會清除既有的長連線。
  • 在 Clash 記錄中依目標網域觀察規則命中結果。如果記錄顯示 DIRECT，應檢查規則順序，而不是修改瀏覽器連接埠。
  • 如果瀏覽器受組織原則管理，請在網址列開啟 chrome://policy 或 edge://policy，查看是否存在固定代理原則。

Firefox 的獨立連線設定

Firefox 可以不遵循系統代理。進入「設定」→「一般」→「網路設定」→「設定」，通常有四種狀態：不使用代理、自動偵測、使用系統代理設定、手動代理設定。希望遵循 Clash 系統代理時，選擇「使用系統代理設定」；需要獨立測試時，可以選擇手動設定並填入 127.0.0.1 與實際連接埠。

使用 SOCKS5 手動設定時，代理位址可填 127.0.0.1，連接埠填入 Clash 的 SOCKS 或 mixed 連接埠，並選擇 SOCKS v5。若介面提供「使用 SOCKS v5 時代理 DNS 查詢」，建議在診斷階段啟用，讓網域解析也沿著相同路徑完成。

檢查繞過清單

系統代理通常會繞過 localhost、127.0.0.1、區域網路位址或使用者手動加入的網域。Windows 代理頁中的「不對以下列出的項目開頭的位址使用代理伺服器」，以及 macOS 代理頁中的「忽略這些主機與網域的代理設定」，都會讓符合條件的目標直接連線。

如果某個網域始終沒有出現在 Clash 記錄中，先從繞過清單移除該網域及其萬用字元寫法，再重新啟動瀏覽器。區域網路管理頁通常應繼續保留直連，例如路由器位址 192.168.1.1；不要為了測試而刪除所有本機位址例外。

終端機預設不使用系統代理的處理方法

終端機本身只是執行指令的環境，是否使用代理取決於 curl、Git、npm、pip 等具體程式。許多命令列工具會讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY，但也有程式只讀取小寫變數，或優先使用自己的設定檔。因此即使瀏覽器已可使用，終端機仍需要個別設定。

macOS、Linux 與 Bash、Zsh

以下是只對目前終端機工作階段生效的 HTTP 代理寫法。代理位址中的 http:// 表示終端機程式透過 HTTP 代理協定連線至本機連接埠，不限制目標網站只能使用 HTTP。

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

使用 SOCKS5 時，可以為支援此變數的程式設定：

export ALL_PROXY="socks5h://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

socks5h 中的字母 h 表示由 SOCKS 代理端解析網域，可減少本機 DNS 路徑與代理路徑不一致的情況。並非所有程式都能識別這種格式，遇到不支援時應改用程式本身的代理選項。

Windows PowerShell

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5h://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

這些變數只會影響目前的 PowerShell 視窗，以及從該視窗啟動的子程序。關閉視窗後便會失效，適合用於排查。需要清除時執行：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Windows 命令提示字元

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1

同樣地，如果只需要暫時診斷，不要立即使用永久環境變數。舊連接埠一旦寫入系統層級變數，即使 Clash 後來改用其他連接埠，新的終端機程式仍會繼續連線至舊位址，形成「系統代理正確但指令始終失敗」的現象。

使用 curl 分別測試代理、DNS 與目標網站

curl 適合直接指定代理，不依賴系統代理與目前的環境變數。先使用明確的 HTTP 代理發出請求，並加入 -v 查看連線過程：

curl -v --proxy http://127.0.0.1:7890 https://example.com/

如果輸出先出現連線至 127.0.0.1:7890，同時 Clash 記錄新增 example.com，表示終端機到 Clash 的路徑正常。若提示 Connection refused，優先檢查連接埠與核心；若本機連線成功但之後逾時，則查看策略群組節點、規則命中結果與遠端連線。

SOCKS5 測試可以使用：

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

再使用不指定代理的指令進行對照：

curl -v https://example.com/

明確指定代理時成功而一般指令失敗，表示 Clash 本身可以運作，問題集中在環境變數或程式設定。兩個指令都失敗時，繼續查看記錄：明確代理請求沒有進入記錄，多半是連接埠錯誤；進入記錄後仍連線失敗，則屬於設定、規則或節點鏈路問題。

確認環境變數的實際值

macOS 與 Linux 可執行：

env | grep -i proxy

PowerShell 可執行：

Get-ChildItem Env: | Where-Object Name -Match "PROXY"

重點尋找舊位址、舊連接埠與重複變數。例如 HTTPS_PROXY 指向 127.0.0.1:7890，而小寫的 https_proxy 仍指向 127.0.0.1:1080。不同程式的讀取順序各異，重複值會造成結果不一致。診斷階段應讓大小寫變數保持一致。

Git、npm 與其他工具的獨立代理設定

環境變數正確後，如果只有某個工具失敗，應查看它的專屬設定。專屬設定通常比系統代理更穩定，但連接埠變更後也需要同步更新。

Git

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --get-regexp "http.*proxy"

取消全域代理時執行：

git config --global --unset http.proxy
git config --global --unset https.proxy

如果儲存庫層級設定另有代理，進入儲存庫後執行 git config --local --get-regexp "http.*proxy"。本機設定的優先級高於全域設定，可能導致只有某個儲存庫連線失敗。

npm

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config get proxy
npm config get https-proxy

清除設定時使用：

npm config delete proxy
npm config delete https-proxy

優先使用單次指令，而非永久寫入

排查階段建議先使用 curl 的 --proxy、程式指令參數或目前工作階段的環境變數。確認路徑穩定後，再決定是否寫入 ~/.zshrc、~/.bashrc 或工具設定。如此可避免用戶端調整連接埠後，啟動指令碼仍持續注入舊值。

規則、代理模式與假連線現象

請求進入 Clash 記錄後，下一步是查看規則命中結果。Rule 模式會依序從上到下比對網域、IP、GeoSite、GeoIP 與兜底規則。某個網域命中 DIRECT 時，會直接連線，不會經過所選的代理節點。排查單一網站時，可以在記錄中確認命中的策略群組，再檢查設定檔中的規則順序。

Global 模式通常會將請求交給全域策略群組，適合短時間判斷問題是否來自規則。如果 Rule 模式失敗而 Global 模式成功，表示本機連接埠與節點基本可用，應回頭處理規則設定，而不是長期依賴 Global 模式。Direct 模式會讓請求直接連線，無法用來驗證代理節點。

延遲測試成功不代表目標請求成功

  • 延遲測試只會存取用戶端預設的測試位址，通常不能代表所有網域都可存取。
  • 節點顯示幾十毫秒，只代表測試請求當時完成，不代表瀏覽器正在使用該節點。
  • 策略群組可能選擇了「自動選擇」，但實際請求命中了另一個策略群組。
  • 既有瀏覽器連線可能重複使用舊通道，切換節點後應重新整理頁面或重新啟動應用程式再測試。
  • UDP、IPv6 與一般 TCP 請求可能經過不同處理路徑，不能只用一種測試推斷所有流量。

何時考慮 TUN 模式

系統代理主要涵蓋會主動讀取 HTTP、HTTPS 或 SOCKS 代理設定的程式。部分桌面應用程式、遊戲啟動器、系統元件及自行實作網路堆疊的軟體會忽略系統代理。mihomo 的 TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，適合處理這些應用程式，但不能用來替代修正連接埠填寫錯誤。

啟用 TUN 前，應先確保設定、節點與規則在一般代理測試中可用。接著進入用戶端「設定」→「TUN 模式」啟用功能。Windows 可能需要允許用戶端安裝或啟用網路元件；macOS 可能要求確認網路延伸功能權限。啟用後再次觀察記錄，確認原本缺少的應用程式請求是否出現。

依固定順序完成最後排查

  1. 確認目前設定已啟用、策略群組已選擇可用節點，且 Clash 或 mihomo 核心正在執行。
  2. 在「設定」→「連接埠設定」讀取實際連接埠，不要憑經驗假定一定是 7890。
  3. 使用 Test-NetConnection、lsof 或 nc 確認連接埠正在監聽。
  4. 核對作業系統代理位址是否為 127.0.0.1，連接埠是否與用戶端一致。
  5. 排除瀏覽器代理擴充功能的影響，檢查 Firefox 獨立設定與系統繞過清單。
  6. 使用 curl 的 --proxy 參數進行明確測試，同時觀察 Clash 記錄。
  7. 瀏覽器可用但終端機失敗時，設定目前工作階段的 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。
  8. 只有 Git、npm 等單一工具失敗時，再檢查該工具的專屬代理設定。
  9. 請求已進入記錄但失敗時，核對 Rule、Global、Direct 模式及實際命中的策略群組。
  10. 應用程式完全忽略系統代理，且一般代理鏈路已確認正常後，再啟用 TUN 模式。

有效的排查過程應始終保留一組對照結果：瀏覽器是否產生記錄、明確指定代理的 curl 是否成功、一般 curl 是否讀取環境變數、目標網域命中了哪條規則。將問題拆成「應用程式到本機連接埠」「Clash 規則處理」「節點到目標位址」三段後，系統代理已開卻未生效通常可以定位到明確環節。

Clash下載