開發者必備：用Clash TUN設定Git與npm終端機代理工作流

先分清終端機代理與 TUN 接管

瀏覽器能開網頁，不代表 git、npm 或 Docker 一定能連線。這些工具可能不讀取作業系統的系統代理設定，也可能由背景服務或虛擬機器負責連線。排查時先分清兩種入口：手動代理是讓工具連到本機 HTTP 或 SOCKS 代理；TUN 則透過虛擬網路介面和路由接管更多 IP 流量。前者設定明確，適合先驗證命令列工具；後者較方便涵蓋不支援代理環境變數的程式，但需要核心、作業系統和用戶端具備相應權限。

本文設定以使用 mihomo 核心的 Clash 用戶端為例。不同用戶端的選項名稱與服務管理方式可能不同；啟用 TUN 前，請在「關於」、「核心」或執行記錄中確認核心為 mihomo，並備份目前設定。以下範例假設本機混合代理連接埠為 7890，這不是所有用戶端的固定值，請以實際設定為準。

啟用 TUN 前先確認核心、路由與 DNS

在 Clash 用戶端中，先更新並啟用目前使用的設定檔，確認代理群組有可用節點，再以規則模式測試一般網站。接著在設定中啟用 TUN；某些平台會要求安裝或啟動服務、授予管理員權限，或重新啟動核心。請透過用戶端提供的服務管理入口完成操作，不要為了測試而停用防火牆或系統安全功能。TUN 開關顯示已啟用，只能表示相關功能已啟動，仍須用連線記錄確認實際命中規則與出站。

mihomo 的設定可包含以下 TUN 欄位，但應合併到現有設定，而不是在 YAML 中重複新增同名的 tun 欄位。實際可用選項會受 mihomo 版本與作業系統影響；若用戶端已管理 TUN 參數，優先使用介面設定，避免介面和覆寫檔互相覆蓋。

mixed-port: 7890
allow-lan: false
mode: rule

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

auto-route 會協助建立流量路由，但不代表所有系統流量都必然經過代理。作業系統的路由、網卡優先順序、IPv6、VPN、容器網路與區域網路例外，都可能改變結果。dns-hijack 的範例用於處理一般 53 埠 DNS 查詢，不能攔截所有以 HTTPS 或 TLS 傳送的 DNS。DNS 欄位應與現有設定一併檢查，不要只複製 TUN 片段就假設解析路徑已符合需求。

依作業系統檢查權限與服務

• Windows：若用戶端提供服務模式，先確認服務已正常執行，再啟用 TUN。系統跳出使用者帳戶控制提示時，確認程式來源後才授權。若出現虛擬網卡或路由錯誤，先關閉其他 VPN 或網路接管工具並重新測試。
• macOS：依用戶端指示授予網路擴充功能或相關系統權限。macOS 的權限提示及選項位置可能隨系統和用戶端版本變動；授權後重新啟動核心，再確認 TUN 狀態與連線記錄。
• Linux：TUN 通常需要核心支援與建立虛擬介面的權限。若用戶端以服務方式執行，檢查服務狀態和記錄；容器、網路命名空間及既有防火牆規則可能讓流量不經預期路由。

首次驗證時先只保留一個 TUN 或 VPN 類工具。若啟用後區域網路服務、遠端桌面或公司內部網域失效，先關閉 TUN 回復網路，再檢查規則和路由；不要直接將所有私有網段流量送往代理節點。

用環境變數讓 Git 與 npm 明確使用本機代理

即使已啟用 TUN，仍可用明確的代理設定診斷命令列工具。若本機混合代理埠為 7890，在支援 POSIX shell 的終端機中可暫時設定：

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

HTTPS_PROXY 的值常仍使用 http://，因為工具會透過 HTTP CONNECT 隧道建立 HTTPS 連線；不要只因目標網址是 HTTPS 就改成 https://127.0.0.1:7890。ALL_PROXY 是否生效取決於工具支援，且示例中的 SOCKS 位址須由目前設定的監聽埠接受。NO_PROXY 用來讓本機服務或指定網域略過代理，請按實際需求增補，避免過度擴大例外範圍。

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

如果明確指定代理的 curl 成功，而 Git 或 npm 仍失敗，應檢查工具自身設定、憑證、DNS 或目標服務，而不是立即修改 TUN 路由。若要確認流量經過哪個策略組，請同時查看 Clash 的連線面板；收到 HTTP 回應並不能單獨證明使用了預期的節點。

設定 Git HTTP 與 HTTPS 傳輸

Git 使用 HTTP 或 HTTPS clone 時，可設定 Git 專屬代理。以下設定會寫入目前使用者的全域 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 --show-origin --get-regexp 'http\..*proxy'

若只想讓特定專案使用代理，可在該專案目錄省略 --global，改寫本機設定；該設定會保存在專案的 .git/config，分享專案前應檢查是否意外包含私人代理資訊。停用全域設定可執行 git config --global --unset http.proxy 和 git config --global --unset https.proxy。若遠端網址使用 SSH，例如 git@host:group/project.git，Git 的 HTTP 代理設定通常不會處理這條 SSH 連線；可改用 HTTPS 遠端網址，或在確認 TUN 路由接管 SSH 流量後測試。不要把 SSH 連線失敗誤判為 HTTPS Proxy 設定錯誤。

處理 npm、套件登錄檔與 Docker 拉取

npm 可透過使用者層級設定指定 HTTP 與 HTTPS 代理。以下以本機 HTTP 代理為例：

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 install，查看終端機錯誤與 Clash 連線記錄。不同 npm 版本、Node.js 版本及套件本身對代理設定的處理可能不同；若只有某個套件安裝失敗，還要確認錯誤來自套件登錄檔、套件 tarball 網址，還是安裝腳本另外存取的主機。npm 的代理設定也可能保存到使用者設定檔，工作結束後可用 npm config delete proxy 與 npm config delete https-proxy 清除。不要為了解決憑證錯誤而設定 strict-ssl=false，這會降低 TLS 憑證驗證安全性。

Docker 拉取映像則要先確認命令連到哪個 Docker daemon。在 Linux 上，docker pull 通常由背景中的 Docker Engine 服務下載映像；目前 shell 的 HTTPS_PROXY 不一定會傳給服務。若使用 Docker Desktop，daemon 位於受管理的虛擬環境中，應依 Docker Desktop 的 Proxy 設定調整，而不是只修改宿主機終端機變數。TUN 有機會接管 daemon 的網路流量，但仍須依實際路由、服務權限與防火牆驗證。

若 Linux daemon 必須直接使用 HTTP 代理，請依所用發行版的 Docker 文件設定 daemon 專用代理，再重載服務並確認服務狀態。不要在公開範例或共用設定中放入含帳密的代理 URL。設定完成後執行一次明確的拉取測試，並觀察 Clash 連線記錄或 Docker 服務記錄；若只有 daemon 失敗，而一般終端機的 curl 成功，問題通常位於 daemon 的代理環境或服務網路，而非 Git 或 npm 設定。

按固定順序驗證，避免把路由問題當成工具問題

建議一次只改一項，並記錄使用的網路、設定檔、代理埠與測試結果。先確認 Clash 核心已啟動、節點可用，再檢查本機代理連接埠；接著用 curl 測試明確代理，再分別測試 Git、npm 和 Docker。每次測試都在 Clash 連線面板核對網域、命中規則、策略組與最終出站。測試後若發現連線命中 DIRECT，先檢查規則順序及目標網域，不要先改動代理埠。

1. 本機拒絕連線：確認 Clash 核心仍在執行，並核對設定中的 mixed-port 與命令中的埠號。若代理監聽在其他位址，127.0.0.1 不一定可用。
2. 連線逾時：查看節點是否可用、策略組是否選到有效出站，並檢查 TUN、系統代理或其他 VPN 是否改變路由。
3. 只有特定網域失敗：核對規則命中、DNS 解析結果與套件工具實際存取的網域；不要假設所有請求都只連到主要登錄檔。
4. Git 成功、npm 失敗：檢查 npm 專屬設定、登錄檔網址及 TLS 錯誤。先分辨連線逾時、名稱解析失敗和憑證驗證失敗，再處理對應問題。
5. 終端機成功、Docker 失敗：分別檢查 Docker Engine 或 Docker Desktop 的代理設定。重新開啟終端機不會重啟 daemon，也不會替 daemon 更新環境變數。
6. 啟用 TUN 後區域網路中斷：先停用 TUN 恢復管理連線，再確認內網網段、DNS 例外、IPv6 與其他 VPN 的路由衝突。

完成驗證後，移除不再需要的 Git、npm 或 shell 代理設定，避免它們在 TUN 關閉時仍指向無法連線的本機埠。只需要讓開發工具走代理時，可保留工具專屬設定；需要涵蓋不支援代理的程式時，再使用 TUN。兩種做法不是互相取代的固定答案，選擇應以可驗證的流量路徑、工作環境和安全需求為準。

常見問題