為什麼瀏覽器能連線，終端機卻不行？

在 Clash 用戶端開啟「系統代理」後，通常是讓遵循作業系統代理設定的應用程式，透過本機 HTTP 或 SOCKS 代理連線。瀏覽器可能會自動使用這項設定，但終端機中的 git、npm、curl 或程式建置工具，不一定會讀取系統代理。結果可能是網頁能開啟，執行 git clone 時卻逾時，或套件安裝停在連線階段。

TUN 是另一種流量接管方式。mihomo 建立虛擬網路介面，讓作業系統將符合路由條件的 IP 封包送入代理核心，再依設定中的規則決定直連或轉送。這與在 Git、npm 裡分別填入代理位址不同：TUN 處理的是網路流量路徑，應用程式代理設定處理的則是應用程式如何使用代理服務。

  • 適合先測 TUN：多個不讀取系統代理的命令列工具都無法連線，而瀏覽器透過代理可以正常使用。
  • 適合明確設定工具代理：只有 Git 或 npm 需要代理，其他終端機流量應維持原路徑。
  • 不要將「已連線」當作成功證明：用戶端顯示 TUN 啟用，只表示接管介面已建立；路由、DNS、策略選擇或遠端節點仍可能有問題。

啟用 TUN：先確認核心、權限與路由設定

開始前先備份目前設定，記下用戶端版本、mihomo 核心版本、混合連接埠，以及目前的代理模式。開啟 TUN 通常需要額外的系統權限：Windows 可能要求以管理員權限建立介面，macOS 可能要求核准網路或系統擴充功能；Linux 則可能需要建立 TUN 裝置及設定路由的權限。若用戶端沒有取得必要權限，可能出現啟用失敗、沒有路由變更或重新啟動後失效。

以下為設定片段範例，應合併至現有主設定檔的頂層 tun: 區塊，不要因此刪除原有的節點、代理群組與規則。欄位支援情況會隨核心版本及用戶端覆寫方式而異；如果介面已提供 TUN 設定，應以介面產生的執行設定為準，避免重複設定同一欄位。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

mixed-port: 7890
allow-lan: false
mode: rule
  • enable 啟用 TUN 介面；若用戶端另有 TUN 開關，可能會在啟動時覆寫設定檔中的值。
  • stack 選擇封包處理堆疊。mixed 是常見選項，但效能與相容性可能受作業系統、核心版本及網路環境影響。
  • auto-route 讓核心協助設定流量路由；auto-detect-interface 用於偵測出口介面。多網卡、虛擬機或 VPN 環境下，偵測結果仍須實際驗證。
  • dns-hijack 用來處理符合條件的 DNS 封包，不等於所有應用程式的 DNS 查詢都必定會進入 mihomo。
  • mixed-port 是供應用程式使用的代理入口範例，與 TUN 介面不是同一項設定；控制 API 連接埠也不能代替代理連接埠。

儲存後重新載入設定，再由用戶端啟用 TUN。先不要同時切換 DNS 模式、代理規則與多個節點。選定一個明確可用的策略群組，然後依序測試 IP 連線、網域解析及實際下載；每一步都記下結果，才容易找出故障環節。

逐項測試 Git 與 npm，不要只看下載進度

啟用 TUN 後，先在同一個終端機視窗執行簡單 HTTPS 測試。這能確認終端機流量是否到達測試網站，但不能證明 GitHub、套件註冊表或特定節點一定可用。若本機混合連接埠不是 7890，請使用用戶端顯示的實際埠號。

curl -v --connect-timeout 5 --max-time 20 https://example.com/ -o /dev/null

Windows PowerShell 可改用 curl.exe，避免 curl 別名影響測試：

curl.exe -v --connect-timeout 5 --max-time 20 https://example.com/ -o NUL

測試成功後，再執行實際的 Git 操作。例如使用 HTTPS 複製公開儲存庫：

git clone https://github.com/example/project.git

上例中的 example/project 是示意路徑，請換成實際儲存庫。若 HTTPS 測試成功但 Git 仍失敗，先查看 Git 是否設定了舊代理或使用不同的協定。SSH 連線使用的是 SSH 設定與連接埠，不會因為 HTTPS 測試成功就自動證明 SSH 可用；可先比較 HTTPS 複製結果，再檢查 SSH 金鑰、主機驗證及網路是否允許 SSH 連線。

npm 可先查看目前的註冊表和代理設定，再進行安裝測試：

npm config get registry
npm config get proxy
npm config get https-proxy
npm view express version
npm install express

npm view 只查詢套件資訊，適合用來區分註冊表連線問題與本機安裝問題。確認查詢成功後，再安裝專案所需套件；實際開發時應遵循專案中的鎖定檔及套件管理器版本，不要為了測試而任意更換全域設定。

測試結果優先檢查下一步
curl 也逾時TUN 是否啟用、目標是否命中正確規則、目前節點是否可用查看連線記錄，確認請求是否進入 mihomo
curl 成功，Git HTTPS 失敗Git 專屬代理、遠端 URL、憑證或儲存庫存取權限檢查 Git 設定並以同一個 HTTPS URL 重試
Git 成功，npm 查詢失敗npm 註冊表、npm 專屬代理與憑證設定先確認註冊表 URL，再查詢單一套件資訊
查詢成功，安裝失敗套件相依性、鎖定檔、磁碟空間及安裝腳本錯誤查看 npm 完整錯誤輸出，勿將所有安裝錯誤視為代理問題

清理重複代理：環境變數、Git 與 npm 設定

TUN 已能正常轉送終端機流量時，通常不必同時再為每個工具指定本機代理。若環境變數或工具設定仍指向已關閉的代理服務，請求可能先嘗試連到錯誤位址，出現 connection refused；若 TUN 又接管這些連線，排查路徑會更複雜。這種情況下，先確認是否有明確需求，再決定保留 TUN 或保留工具專用代理，不要兩邊輪流修改。

先查看目前終端機程序中的代理環境變數。不同 shell 的顯示方式不同：

# macOS / Linux
env | grep -i proxy

# Windows PowerShell
Get-ChildItem Env:*proxy*

常見變數包括 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY，也可能使用小寫名稱。測試時可在目前的 shell 暫時移除變數；這不會清除使用者或系統層級的永久設定。完成後重新開啟終端機，確認變數是否又被 shell 設定檔或開發工具注入。

# macOS / Linux：只影響目前 shell
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

# Windows PowerShell：只影響目前視窗
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY -ErrorAction SilentlyContinue

Git 的代理設定可能存在系統、全域、目前儲存庫或命令列層級。先查看來源，再決定要改哪一層：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'
git config --global --unset http.proxy
git config --global --unset https.proxy

第二行與第三行會移除全域設定；如果設定在儲存庫層級，需先進入該儲存庫，再檢查並調整對應層級。若希望 Git 明確使用本機 HTTP 代理，則應填入實際監聽的位址與埠號，例如 http://127.0.0.1:7890，且確認服務正在監聽。不要把控制 API 埠或已停止服務的埠填入 Git 設定。

npm 同樣可能保留獨立代理值。若打算改由 TUN 接管，可檢查並視需要移除 npm 設定：

npm config get proxy
npm config get https-proxy
npm config delete proxy
npm config delete https-proxy

npm config delete 會依 npm 設定來源移除相關值；執行前先確認它們是否由公司網路、專案或使用者設定檔管理。若環境要求使用明確代理，就不應任意刪除，而應核對代理服務仍在執行、連接埠正確，並且沒有與 TUN 路由互相衝突。

DNS 與規則排查：找出連線在哪一段中斷

終端機連線失敗不一定是代理設定錯誤。若錯誤是 Could not resolve host、ENOTFOUND 或 no such host，優先檢查 DNS；若名稱已解析但連線逾時，則再檢查規則、策略群組及節點。記錄錯誤訊息時要移除私人儲存庫名稱、存取權杖及可能包含帳號資訊的 URL。

  1. 檢查是否有連線記錄：在 mihomo 日誌或用戶端連線頁面中，重新執行一次失敗命令。若沒有新連線，可能是應用程式使用了不同的網路路徑、命令沒有真正送出，或 TUN 沒有接管該流量。
  2. 檢查匹配規則：確認 GitHub 或套件註冊表網域命中的規則，最後指向存在且已選取可用節點的代理群組。規則模式依序比對；過早匹配的直連規則可能讓請求繞過代理。
  3. 比較 DNS 與 IP 連線：可使用 nslookup registry.npmjs.org 或作業系統提供的 DNS 查詢工具查看解析結果。不要把能解析網域等同於 HTTPS 一定能連線；DNS、TCP、TLS 與 HTTP 是不同階段。
  4. 確認目前出口介面：多網卡、公司 VPN、容器或虛擬機可能改變預設路由。停用其他 VPN 後做一次對照測試，並記錄每次只變更了哪一項。

若使用 fake-ip，DNS 模組可能回傳供核心識別與轉送的假 IP，而不是網站的實際公網位址。不要因為查詢結果落在保留位址範圍，就直接判定解析錯誤；應配合 mihomo 的 DNS 設定、連線記錄與實際請求一起判斷。若部分內部網域、區域網路服務或開發環境名稱異常，可檢查 fake-ip-filter、DNS 政策與該網域預期使用的解析器。

常見問題

開啟 TUN 後，還需要設定 Git 和 npm 的代理嗎？

若確認 TUN 已接管相關流量，且規則能正確轉送，一般不需要再為 Git 和 npm 各自設定代理。若工作環境要求特定工具使用指定代理，則可保留明確設定，但應確認代理位址可用，並以實際連線記錄驗證請求路徑。

Git HTTPS 可以使用，為什麼 SSH 複製仍失敗？

HTTPS 與 SSH 使用不同協定與連線設定。SSH 通常使用連接埠 22，也可能在特定環境使用其他連接方式；HTTPS 成功不能證明 SSH 流量已被正確路由。先檢查 SSH 主機、金鑰、主機指紋與網路政策，再以 HTTPS URL 作為對照。

停用 TUN 後網路變慢或無法連線，怎麼處理？

先從用戶端正常停用 TUN，等待系統路由還原，再確認是否仍有公司 VPN、其他代理程式或殘留的工具代理設定。若網路狀態未恢復，可重新啟動用戶端或網路介面，並查看系統代理是否仍指向本機服務。不要在原因未明時連續重設整份網路設定。

npm 註冊表能連線，但套件安裝仍失敗，是代理問題嗎？

不一定。註冊表查詢成功表示至少部分 HTTPS 請求可用；安裝仍可能因相依套件下載、套件版本、鎖定檔、磁碟空間或安裝腳本失敗。請保留完整錯誤輸出，確認失敗的是哪個套件與哪個階段，再針對該網域或本機環境排查。