軟體工程師 Clash 實戰：用 TUN 模式穩定 Git、npm 與 AI 編程

先理解開發工具為何常常繞過代理

對軟體工程師而言，瀏覽器可以開啟網頁，並不代表整台電腦的開發流程都已經能穩定使用代理。Git、npm、pnpm、yarn、Docker、Python 套件工具，以及各種 AI 編程工具，可能分別採用作業系統網路設定、環境變數、應用程式自有設定或直接建立 TCP 連線。當其中一個環節沒有讀取 Clash 的代理位址，就會出現 GitHub clone 逾時、npm install 卡在某個套件、AI 編程工具無法建立工作階段等問題。

系統代理的本質是「提供設定」，不是強制所有封包經過代理。Chrome、Edge 等瀏覽器通常會讀取系統代理；命令列工具則可能只讀取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 環境變數。若工具使用自有網路堆疊，甚至可能完全忽略這些設定。TUN 模式則是透過虛擬網路介面接管較廣泛的 IP 流量，再交由 mihomo 核心依規則分流，因此更適合需要同時處理終端機、IDE 外掛與背景程序的開發工作站。

啟用 TUN 並設計安全的分流範圍

在 Clash Nyanpasu 或其他 mihomo 圖形客戶端中，通常可從「設定」→「TUN 模式」啟用虛擬網路介面。不同版本的選項名稱可能略有差異，常見項目包括自動路由、嚴格路由、堆疊模式、DNS 劫持與繞過私有網路。TUN 不等同於全域代理；它只是讓更多連線進入核心，最後仍由 rules、策略群組與 DNS 行為決定使用代理或直連。

第一次啟用時，請先關閉其他透明代理、VPN、企業安全軟體的網路過濾器，以及另一個正在執行的 Clash 核心。多個程式同時建立虛擬介面或修改路由表，可能造成循環路由、整台電腦斷網，甚至讓 DNS 請求反覆被轉送。Windows 可能跳出系統管理員授權；macOS 也可能要求允許網路擴充功能。這些權限是建立虛擬介面所需，不代表需要將代理開放到區域網路。

開發工作站的基本檢查順序

1. 確認核心已啟動，並在日誌中找不到 bind、route、tun 或 DNS 初始化錯誤。
2. 先以「規則」模式測試，不要一開始使用全域模式。規則模式較容易確認哪些網域經過代理，哪些本來就應該直連。
3. 開啟 TUN 後，檢查介面是否出現，並確認預設路由沒有被另一個 VPN 或網路工具覆蓋。
4. 將公司內網、家用路由器、印表機與本機服務保留直連，常見私有網段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。
5. 先測試單一網域，再測試 Git、npm 和 AI 工具，避免將整個工作區的錯誤誤判為 TUN 故障。

如果 TUN 開啟後瀏覽器正常，但區域網路開發服務無法存取，先檢查私有網段規則與「繞過私有網路」選項。若本機使用 localhost、127.0.0.1、::1 連線，也應避免讓這些位址被不必要地送入代理。Docker、虛擬機器和 WSL 的網路則可能使用額外的虛擬子網段，需依實際介面確認，不要盲目複製其他電腦的排除清單。

rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Developer
  - DOMAIN-SUFFIX,npmjs.org,Developer
  - MATCH,Proxy

上面的名稱只是示例，Developer 和 Proxy 必須與你的 proxy-groups 名稱完全一致。若訂閱已經帶有完整規則，應先確認規則順序，再以覆寫或本地設定補充內容；規則採用由上而下的首次匹配，將 MATCH 放在前面會讓後續規則全部失效。

讓 Git 與容器工具使用一致的連線

Git 可以透過 HTTP 代理、SOCKS 代理或 TUN 接管。若已啟用穩定的 TUN 模式，Git 通常不需要額外指定代理；但在排查階段，明確設定 Git 代理有助於判斷問題究竟在核心、DNS、路由還是 Git 自身。常見的 mihomo 混合連接埠是 7890，實際數值必須以客戶端目前顯示的設定為準。

用 curl 與 Git 分段確認

先直接指定 HTTP 代理測試 HTTPS 連線：

curl -I -x http://127.0.0.1:7890 https://github.com
curl -I --proxy socks5h://127.0.0.1:7890 https://github.com

socks5h 的 h 表示由代理端解析網域，適合用來排除本機 DNS 解析差異。若第一個指令成功、第二個失敗，可能是混合連接埠對 SOCKS5 的支援方式、命令列 curl 版本或本機設定不同；若兩者都失敗，應回到 Clash 日誌查看規則命中與節點連線錯誤。

確認代理入口可用後，再設定 Git。HTTP 代理的設定方式如下：

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|sslVerify)'

Git 的 HTTPS 連線會透過 HTTP CONNECT 建立加密通道，因此代理欄位使用 http:// 並不表示 GitHub 的 HTTPS 被降級。若你的客戶端明確提供 SOCKS5 入口，也可使用：

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

使用 TUN 時，不建議長期同時保留 Git 代理和一組可能過期的環境變數。舊設定可能指向已關閉的 127.0.0.1:1080，造成 Git 繞過目前的路徑而逾時。需要回到 TUN 接管時，可以移除 Git 的全域代理：

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

如果只想讓某個專案使用代理，可在該專案目錄執行不帶 --global 的設定。企業 Git 伺服器、內部 GitLab 與本機開發網域通常應該直連，避免把內部憑證、內網流量或需要 VPN 才能到達的位址送到公共代理節點。

Docker 與 SSH 的額外注意事項

終端機中的 Git 代理設定不會自動套用到 Docker daemon 或容器內部。若是 docker pull 失敗，需分別確認 Docker daemon 的代理設定、容器建置時的 HTTP_PROXY，以及執行中容器的環境變數。容器中的 127.0.0.1 指向容器自己，不是宿主機，因此不能直接照搬主機代理位址。使用宿主機位址時，還要搭配 Docker 網路與 Clash 的區域網路監聽設定，並評估防火牆風險。

SSH Git 位址例如 [email protected]:org/repo.git 不會讀取 Git 的 HTTP 代理。它通常需要 SSH 自身的 ProxyCommand，或依靠 TUN 接管 TCP 連線。若採用明確的 SOCKS5 工具，設定前先確認公司政策與節點安全性；不要為了讓 clone 成功而關閉主機金鑰驗證，也不要將私鑰內容貼入代理工具或除錯記錄。

npm、pnpm 與 yarn 的套件下載策略

Node.js 套件安裝不只會存取一個網址。套件管理器可能先連到 registry，再依套件中繼資料取得 tarball，還可能讀取 Git repository、二進位檔案儲存站或 postinstall 腳本使用的其他服務。因此，首頁能開啟而 npm install 仍逾時並不罕見。啟用 TUN 後，先查看實際 registry 與目前代理設定：

npm config get registry
npm config get proxy
npm config get https-proxy
npm ping

官方 npm registry 常見位址為 https://registry.npmjs.org/，但團隊可能使用公司內部 registry。不要為了測試而永久改用來路不明的鏡像；套件名稱、完整性校驗、權限政策與可用性都應由團隊統一決定。若 TUN 已能穩定接管，可以先清除 npm 中過期的代理覆寫，避免它與 TUN 形成兩層代理：

npm config delete proxy
npm config delete https-proxy
npm config set fetch-retries 3
npm config set fetch-retry-mintimeout 20000
npm config set fetch-retry-maxtimeout 120000

重試參數只能改善短暫網路波動，不能修正錯誤 registry、憑證問題或完全無法連線的節點。若錯誤訊息明確指出 ECONNRESET、ETIMEDOUT 或 ENOTFOUND，應分別對照連線中斷、遠端逾時與 DNS 解析失敗，不要一律增加重試次數。

pnpm 與 yarn 的設定不要混為一談

pnpm 通常會讀取 npm 相容設定，但專案內的 .npmrc、使用者目錄的設定和環境變數可能互相覆蓋。請在專案目錄執行 pnpm config list，並檢查是否有提交到版本庫的 registry 或代理設定。yarn 不同主要版本的設定指令與設定檔格式可能不同，應先以目前專案鎖定的版本為準，不要把 Yarn 1 的指令直接套用到 Yarn Berry 專案。

• 同一個專案固定一個 registry，避免開發者各自使用不同來源而產生鎖檔差異。
• 確認 package-lock.json、pnpm-lock.yaml 或 yarn.lock 中的 tarball 網址是否仍可存取。
• 遇到單一套件下載失敗時，先記錄失敗的主機名稱，再檢查該主機的規則命中結果。
• 不要把含有帳號密碼或存取權杖的 registry URL 提交到公開版本庫。

AI 編程工具與 IDE 的穩定使用方式

AI 編程工具通常同時使用 HTTPS 長連線、串流回應、檔案上傳、登入服務與更新服務。這些請求不一定由內建瀏覽器處理，也不一定遵循 IDE 的代理選項。TUN 模式可以涵蓋更多由背景程序建立的 TCP 流量，但不能保證所有應用程式的憑證、WebSocket、HTTP/2 或企業 TLS 檢查都能正常工作。

建議先將 AI 工具、IDE、Git 和套件管理器全部關閉，再啟用 TUN，讓它們在相同的路由與 DNS 狀態下重新啟動。接著觀察 Clash 的連線頁面，確認請求的實際網域、命中的策略群組和所使用的節點。不要只看主程式名稱；IDE 外掛可能由獨立程序執行，登入、模型請求、遙測與更新也可能使用不同網域。

對需要串流回應的工具，穩定性通常比最低延遲更重要。可建立一個簡單的比較表：固定同一個節點，連續執行三次登入或測試請求，記錄首個回應時間、完整回應時間、是否中途斷線，以及 Clash 日誌中的錯誤。若切換到另一節點後首個回應變慢但不再中斷，對實際編程工作而言，後者往往更適合。

完整驗證與故障排查流程

完成設定後，不要只用瀏覽器測試。應按照由底層到應用程式的順序驗證，確保每一層都走到預期路徑。先確認本機核心，再確認 DNS，再確認一般 HTTPS，最後才測試 Git、套件管理器與 AI 編程工具。這樣可以把「代理未啟動」、「網域解析失敗」、「節點不穩定」和「應用程式不支援代理」區分開來。

1. 在 Clash 介面確認核心運作、模式為「規則」，並固定一個測試節點或策略群組。
2. 使用 curl -I -x http://127.0.0.1:7890 https://github.com 測試本機代理入口。
3. 使用 curl -I --proxy socks5h://127.0.0.1:7890 https://registry.npmjs.org 測試代理端 DNS。
4. 執行 git ls-remote https://github.com/example/example.git，使用實際可公開存取的測試專案替換範例位址。
5. 在全新暫存目錄執行套件安裝，避免既有快取讓測試結果看起來正常。
6. 啟動 AI 工具後觀察連線記錄，確認登入網域與 API 網域並非被規則誤判為 DIRECT。
7. 完成測試後，再決定是否保留 Git 或 npm 的明確代理設定，避免長期累積重複配置。

最後，為日常開發保留一份簡短的設定紀錄，包括目前使用的 mixed-port、TUN 是否自動啟動、私有網段排除規則、Git 與 npm 是否使用明確代理，以及常用策略群組的用途。當訂閱更新、核心升級或公司網路政策變更時，先依這份紀錄逐項驗證，比重新安裝客戶端或刪除全部設定更安全。穩定的開發代理不是把所有流量一律送出，而是讓 Git、套件來源、AI 服務、內部資源與本機服務各自走適合的路徑。