故障排除 預計閱讀 12 分鐘

系統代理無法生效排查：瀏覽器可使用代理，終端機為什麼不行

系統代理只對遵循系統設定的應用程式有效。分別從瀏覽器與終端機排查：檢查瀏覽器擴充功能和代理覆寫設定，確認終端機環境變數的寫法，並了解何時應改用 TUN 模式接管所有流量。

先釐清系統代理、應用程式代理與 TUN

開啟 Clash Nyanpasu 的「系統代理」後，客戶端會將本機代理位址寫入作業系統設定。以常見設定為例，代理伺服器是 127.0.0.1，混合連接埠是 7890。瀏覽器讀取這項設定後，會將 HTTP 請求以及透過 CONNECT 建立的 HTTPS 連線交給 Clash；Clash 再依照目前設定中的規則、策略群組與節點處理流量。

重點在於，系統代理是供應用程式讀取的設定，不是作業系統強制轉送所有網路封包。Chrome、Edge、Safari 等桌面瀏覽器通常會遵循系統代理，但許多命令列程式、遊戲啟動器、開發工具，以及採用自有網路堆疊的應用程式，會自行決定是否讀取。因此，「瀏覽器可以存取，終端機仍然直接連線」並不矛盾，通常代表代理核心與節點已正常運作，問題集中在終端機程式如何取得代理參數。

接管方式 生效範圍 常見設定位置 適用情境
系統代理 讀取作業系統代理設定的應用程式 Clash Nyanpasu「設定」→「系統代理」 瀏覽器與一般桌面應用程式
應用程式內代理 指定的應用程式本身 應用程式網路設定或啟動參數 Git、瀏覽器擴充功能、開發工具
環境變數 目前的終端機或由其啟動的程序 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY curl、套件管理器、命令列工具
TUN 模式 經由虛擬網路介面的更多流量 Clash Nyanpasu「設定」→「TUN 模式」 不讀取代理設定的應用程式與 UDP 流量

第一步：確認 Clash 核心與本機連接埠正常

不要一開始就修改系統網路設定。先在 Clash Nyanpasu 中確認設定已啟用、代理核心正在執行，並檢查目前模式是「規則」、「全域」還是「直連」。在規則模式下，某些目標依規則直接連線是預期結果；如果測試網域命中 DIRECT，即使請求已進入 Clash，也不會看到代理節點的出口。

核對混合連接埠與監聽位址

進入「設定」→「Clash 設定」或目前版本對應的連接埠設定頁面，查看 mixed-port。常見值為 7890，但匯入設定、連接埠衝突或手動調整，都可能讓實際值變成 7891、7897 等。後續指令中的連接埠必須與介面顯示一致。

預設監聽位址通常使用回環位址 127.0.0.1。如果指令就在本機執行，不需要開啟區域網路存取，也不應將代理位址填成本機 Wi-Fi IP。只有容器、虛擬機器或同一區域網路中的其他裝置需要存取時，才需要搭配 allow-lan、防火牆與監聽位址進一步設定。

使用 curl 直接測試本機代理

先繞過系統代理設定，明確指定 Clash 的 HTTP 代理來執行一次請求：

curl -I -x http://127.0.0.1:7890 https://www.example.com

如果回傳 HTTP/2 200、HTTP/1.1 200 OK 或目標網站的正常重新導向狀態，表示本機連接埠可連線，HTTPS 通道也已建立。若顯示 Failed to connect 或 Connection refused，請優先檢查連接埠、核心執行狀態與本機防火牆。若連線建立後逾時，則查看 Clash 記錄中的規則命中、節點錯誤與 DNS 結果。

也可以指定 SOCKS5 入口進行測試。混合連接埠通常同時接受 HTTP 與 SOCKS5，請以目前設定為準：

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

socks5h 中的字母 h 表示由代理端解析目標網域，適合用來區分本機 DNS 解析問題與代理鏈路問題。如果 HTTP 代理測試成功、直接請求失敗，基本上可以將排查範圍縮小至系統設定或應用程式設定。

瀏覽器可使用代理時，檢查擴充功能與代理覆寫

瀏覽器存取正常，只能證明「瀏覽器目前使用的某條代理路徑可用」，不能直接證明系統代理設定正確。Chrome 與 Edge 一般會讀取系統代理，但代理擴充功能、企業原則、啟動參數，以及瀏覽器內建的安全 DNS，都可能改變實際行為。Firefox 另有獨立的連線設定，可選擇系統代理、手動代理或直接連線。

排除瀏覽器代理擴充功能的獨立設定

  1. 暫時停用負責切換代理的瀏覽器擴充功能。
  2. 完全結束瀏覽器後重新啟動，避免背景程序繼續沿用舊連線。
  3. 只開啟 Clash Nyanpasu 的系統代理，然後重新存取測試頁面。
  4. 在 Clash 的連線記錄中確認出現對應網域，並查看規則命中結果。

如果停用擴充功能後立即失效，表示先前是擴充功能直接連線至 127.0.0.1:7890，而不是系統代理生效。此時應檢查作業系統代理位址是否仍指向舊連接埠，或系統代理開關是否被其他代理軟體覆寫。

檢查 Firefox 的連線設定

Firefox 可進入「設定」→「一般」→「網路設定」→「設定」。選擇「使用系統代理設定」時，才會跟隨作業系統；選擇「手動代理設定」時，需將 HTTP 代理與 HTTPS 代理填入 127.0.0.1 和實際混合連接埠。若使用 SOCKS，應選擇 SOCKS v5，並依需求啟用透過 SOCKS 代理 DNS。

辨識安全 DNS 造成的差異

瀏覽器的 DNS over HTTPS 可能讓網域解析路徑與終端機不同。終端機通常先呼叫系統 DNS，瀏覽器則可能向自己的加密 DNS 服務查詢。若情況是瀏覽器可存取、終端機顯示「無法解析主機」，請先執行 nslookup 或 dig 檢查系統解析，再使用前面的 socks5h 請求測試代理端解析。此時問題不一定出在代理連接埠，也可能是系統 DNS、VPN 殘留設定或網路介面優先順序。

終端機為什麼不會自動跟隨系統代理

命令列工具跨平台執行時，往往不依賴桌面作業系統的代理介面。curl、Git、Python、Node.js 及各類套件管理器對代理變數的支援也不完全相同。最穩定的做法是先為目前終端機工作階段設定環境變數，再啟動目標指令；測試完成後清除變數，避免日後切換連接埠時仍連線至舊位址。

Windows PowerShell 暫時設定

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

curl.exe -I https://www.example.com

HTTPS_PROXY 的值寫成 http:// 是常見且正確的設定：這表示用戶端先透過 HTTP 代理建立 CONNECT 通道，再在通道內傳輸 HTTPS。不要因為變數名稱含有 HTTPS，就擅自將通訊協定改成 https://，除非本機代理連接埠明確提供 TLS 代理服務。

這些 PowerShell 變數只會影響目前視窗，以及從該視窗啟動的子程序。關閉視窗後設定便會失效。清除方式如下：

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

Windows CMD 暫時設定

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

curl.exe -I https://www.example.com

Windows 中還有 WinINET 與 WinHTTP 兩套代理機制。瀏覽器和許多桌面程式會讀取系統介面的代理設定，某些系統服務則使用 WinHTTP。可以用 netsh winhttp show proxy 查看 WinHTTP 狀態，但不要為了修復一般終端機請求就直接匯入全域設定；先確認目標程式究竟讀取哪一套設定。

macOS 與 Linux 的目前工作階段設定

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

curl -I https://www.example.com

同時設定小寫變數，可以相容於只讀取小寫名稱的工具：

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

清除目前工作階段變數可執行：

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

如果要寫入 ~/.zshrc、~/.bashrc 或其他 shell 設定，建議定義開啟與關閉代理的函式，而不是長期固定一個連接埠。如此一來，Clash 未啟動時，終端機不會反覆等待不存在的本機代理。修改設定檔後，需要重新開啟終端機或執行相應的 source 指令。

Git、套件管理器與開發工具需要個別核對

環境變數設定正確後，部分工具仍可能被自己的設定覆寫。排查時應同時檢查「系統設定、環境變數、應用程式設定」三個層級，並留意設定優先順序。最常見的情況是 Git 中儲存了舊連接埠，或 npm 設定仍指向已停用的代理位址。

Git 的代理設定

查看 Git 目前讀取到的代理來源：

git config --show-origin --get-regexp "http\..*proxy|https\..*proxy"

需要為目前使用者設定代理時，可執行：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

日後改用環境變數或 TUN 模式時，應移除這兩項，避免固定設定繼續覆寫新的連線路徑：

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

npm 與 pnpm 的代理記錄

npm config get proxy
npm config get https-proxy
pnpm config get proxy
pnpm config get https-proxy

如果輸出的是舊位址，應更新為目前連接埠或刪除對應設定。套件管理器還會受到鏡像來源、憑證鏈、DNS 與儲存庫服務狀態影響，因此「下載失敗」不能只看代理開關。建議先用 curl 請求相同的儲存庫網域，再查看指令的詳細記錄，區分 TCP 連線失敗、網域解析失敗、TLS 錯誤與伺服器限流。

容器與虛擬機器中的 127.0.0.1

Docker 容器、WSL 與虛擬機器中的 127.0.0.1 通常指向它們自己的網路環境，不一定是主機。若直接複製主機上的 Clash 位址，常見結果就是連線遭拒。此時需要使用主機在該虛擬網路中的位址，並在 Clash 中依需求開啟區域網路存取，同時設定作業系統防火牆。開放範圍應限制在可信任的網路，不要直接暴露於公共網路。

什麼時候應改用 TUN 模式

如果目標應用程式不支援 HTTP 或 SOCKS 代理，也不讀取環境變數，系統代理就很難覆蓋。典型情境包括部分遊戲啟動器、使用 UDP 的程式、固定直接連線的桌面應用程式，以及需要同時接管多個開發工具的工作環境。此時可以考慮 TUN 模式，讓流量先經過虛擬網路介面，再交由 mihomo 核心依規則處理。

TUN 模式解決的是接管範圍

TUN 不會自動提升節點品質，也不會修復訂閱中的錯誤伺服器參數。它主要改變流量進入 Clash 的方式。啟用後，原本繞過系統代理的 TCP 或 UDP 流量有機會被統一接管，規則模式、策略群組與節點選擇仍依目前設定執行。

在 Clash Nyanpasu 中，可從「設定」→「TUN 模式」啟用相關功能。Windows 首次啟用可能需要系統管理員權限來建立虛擬網路介面；macOS 可能會顯示網路延伸功能或系統權限確認；Linux 通常需要相應的網路管理權限。不同客戶端版本的選單名稱會略有差異，但應以 TUN 開關、網路介面狀態與核心記錄作為判斷依據。

啟用前後的檢查順序

  1. 關閉其他 VPN、加速器或同類 TUN 程式，避免路由表同時被多方修改。
  2. 記錄目前的系統代理狀態、混合連接埠與 DNS 設定，方便還原。
  3. 啟用 TUN 後確認虛擬介面建立成功，並觀察核心記錄是否出現權限錯誤。
  4. 先測試瀏覽器與 curl，再測試原本無法被接管的應用程式。
  5. 檢查區域網路位址、印表機與開發伺服器是否仍可存取，必要時設定直連規則。

TUN 與系統代理在部分客戶端中可以同時啟用，但排障階段最好一次只驗證一種接管方式。否則同一個請求可能經過不同入口，難以判斷問題來自系統代理、環境變數還是虛擬介面。確認 TUN 正常運作後，再依使用習慣決定是否保留系統代理。

DNS、規則與回環位址的常見誤判

終端機顯示網域解析失敗

如果錯誤發生在連線代理之前，例如顯示 Could not resolve host，請先判斷使用的是 HTTP 代理還是 SOCKS。HTTP CONNECT 請求通常會將目標主機名稱交給代理處理；socks5:// 可能先在本機解析，而 socks5h:// 則明確要求由代理端解析。用兩種寫法進行對照測試，可以快速判斷故障位於系統 DNS 還是代理鏈路。

請求進入 Clash 卻顯示 DIRECT

規則模式會依網域、IP、程序或規則集選擇策略。如果記錄顯示 DIRECT，表示請求已被接管，只是規則決定直接連線。可以檢查目前設定的規則順序、目標網域所屬規則集，以及最終的兜底規則。暫時切換至全域模式可用於對照，但測試結束後應恢復原本模式，避免把原本應直接連線的區域網路與中國大陸服務全部交給代理節點。

localhost 經過代理後存取異常

開發伺服器常使用 localhost:3000、127.0.0.1:5173 或其他本機連接埠。設定環境變數時，應透過 NO_PROXY 排除 localhost、127.0.0.1 與 ::1，否則某些工具會嘗試將本機請求傳送至代理。需要存取內網服務時，也可以依工具支援的格式加入公司網域或網段，但不同程式對萬用字元與 CIDR 的支援並不一致。

依現象縮小問題範圍的完整清單

最有效的排查順序是：先確認本機連接埠，再明確指定代理進行測試，接著檢查系統代理或環境變數，最後才考慮 TUN。瀏覽器已可正常存取時，通常不必反覆更換節點或訂閱；應將注意力放在終端機是否讀取代理、連接埠是否一致、DNS 在哪裡解析，以及請求是否真正進入 Clash 核心。

下載 Clash 客戶端 依系統選擇安裝包