工程師的代理問題，不只是一個瀏覽器開關

對開發者而言，代理是否正常，通常不是打開瀏覽器測試一個網站就能判斷。日常工作裡可能同時存在 Git push、套件管理器、SSH、Docker、雲端 CLI、IDE 外掛與測試腳本等多條網路管線，而每個工具對代理的支援方式都不一樣。瀏覽器能載入頁面，不代表 git clone、npm install 或 docker pull 也會走同一條出口。

當工程師搜尋「終端機代理怎麼設定」、「Clash TUN 開發環境」或「Git push 連線逾時」時，真正想解決的往往是另一個問題：如何讓不同工具在不重複設定環境變數的前提下，穩定使用同一套分流規則。這正是 TUN 模式適合開發工作流的地方。它在系統網路層建立虛擬介面，讓原本不理解 HTTP 或 SOCKS 代理的程式，也有機會被 Clash／Mihomo 統一接管。

不過，TUN 並不是開啟後就能解決所有錯誤的萬用按鈕。DNS 模式、路由排除、公司內網、容器網路、SSH 長連線和 Git 自己設定的 Proxy，都可能影響最後結果。本文以「先辨識流量，再逐步接管」為原則，整理一套適合 Windows、macOS 與 Linux 開發環境的設定方法。

合規提醒：Clash／mihomo 是本機流量轉送與規則管理工具，不提供遠端節點。請使用合法、可信任且符合服務條款的訂閱或設定來源；公司網路、內部 Git 與雲端憑證也應遵循組織的安全政策。

先理解三種代理路徑與各自的限制

工程環境常見的代理路徑大致分成三類。第一種是系統代理，由作業系統提供 HTTP 或 SOCKS 設定，適合瀏覽器以及會主動讀取系統設定的 GUI 應用程式。它的優點是容易開關，缺點是終端工具、虛擬機和部分 Electron 應用程式不一定會繼承。

第二種是終端機環境變數。你可以在 shell 中設定 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY，讓 curl、部分 SDK 和套件工具使用本機代理埠。這種方式很直觀，但容易留下多份設定：PowerShell 一份、zsh 一份、CI 腳本又一份；一旦 Clash 混合埠改變，所有工具都要重新調整。

第三種是TUN 模式。它不要求每個應用程式理解代理協議，而是把符合路由條件的流量交給 Clash 核心判斷。對 Git、Docker、語言套件管理器或不支援 Proxy 的二進位程式而言，TUN 可以降低個別設定的數量。不過，TUN 需要虛擬網卡、管理員或系統擴充權限，並可能與 VPN、企業安全軟體及虛擬化網路產生衝突。

  • 瀏覽器能通、終端不能通：優先檢查系統代理與終端環境變數是否一致，再觀察 TUN 是否真的接管。
  • 終端能通、Docker 不能通：檢查 Docker daemon、容器 DNS 與 Docker Desktop 的獨立網路層，不要只改宿主機 shell。
  • Git fetch 成功、push 失敗：分別確認 HTTPS 與 SSH 使用的傳輸方式，兩者可能根本沒有共用同一個代理設定。
  • 內網服務突然失效：把公司網域、私有 IP、localhost 和內部 DNS 放入 DIRECT 或繞過清單。

開啟 TUN 前的準備：先保留可回復的基線

在修改設定前，建議先記錄目前的工作狀態。包括 Clash 使用的混合埠、HTTP 埠、SOCKS 埠、DNS 模式、目前啟用的 profile，以及作業系統是否已開啟系統代理。若你正在使用企業 VPN、Docker Desktop、WSL 或虛擬機，也應先測試內網服務與本機開發站點，這些結果會成為之後排障的對照組。

另外，請先確認 Clash 客戶端使用的是支援 TUN 的 Mihomo 或相容核心。Clash for Windows 已停止維護，對新的設定欄位與核心功能支援有限；在 2026 年的桌面環境，通常可考慮使用 Clash Verge Rev、Mihomo Party 或其他仍有維護的 Mihomo 客戶端。不同客戶端的選單名稱可能略有差異，但核心概念通常包括 TUN 開關、堆疊模式、自動偵測介面、嚴格路由與 DNS 設定。

設定檔方面，不建議一開始就使用非常寬泛的規則，例如把所有外部網域都送入代理。開發環境更需要清楚的流量分層：套件 registry、原始碼平台、容器映像倉庫與雲端 API 可以使用開發者策略組；公司 Git、內部套件庫、資料庫與本機服務則應保持直連。這樣做不只減少延遲，也能避免憑證、內網存取和審計紀錄被不必要地送往外部出口。

實務建議：在修改 profile 前先複製一份備份，並為開發用途建立獨立策略組，例如 DEV-PROXY。不要直接改動唯一的主設定檔，否則測試失敗時很難判斷是規則變更還是核心本身的問題。

動手設定：用 Clash TUN 接管開發流量

以下流程適用於大多數支援 Mihomo 的桌面客戶端。介面文字可能顯示為「Tun Mode」、「TUN」、「Service Mode」或「虛擬網卡」，請以實際版本為準。每完成一個階段，都應立即測試，不要一次開啟大量進階選項。

  1. 先確認本機代理埠：在 Clash 的設定或概覽頁記下 HTTP、SOCKS 與混合埠，例如 7890。若要保留終端環境變數作為備援，請確認它們指向目前仍在監聽的埠。
  2. 選擇並啟用開發用 profile：先確認 YAML 可以成功載入，策略組有可用節點，且規則提供者已完成更新。若 profile 本身無法解析，TUN 只會把問題變得更難追蹤。
  3. 開啟 TUN 與必要權限：在客戶端設定中啟用 TUN。Windows 可能需要管理員授權或 Service Mode；macOS 可能要求允許網路擴充功能；Linux 則可能需要建立 tun 裝置與相應權限。
  4. 設定堆疊與介面：優先使用客戶端推薦的 mixed 或 gvisor 類型，並開啟自動偵測網路介面。若你使用有線網路、Wi-Fi、VPN 頻繁切換，這項設定能降低路由綁定錯誤。
  5. 建立直連排除：將 127.0.0.1、localhost、公司內網網域、私有 IP 範圍與開發資料庫加入 DIRECT 規則。Docker、WSL 或虛擬機的內部網段，應依實際架構補入，不要直接照抄其他人的網段。
  6. 逐項測試開發工具：先測試 DNS 與 HTTPS，再測試 Git、套件下載和 Docker。每次只改一個變數，並在 Clash 的連線列表中確認主機名稱、命中規則和出口策略。

完成後，可以用以下指令做基本檢查。它們不代表所有工具都已設定完成，但能快速確認 DNS、HTTPS 與 Git 是否有流量進入預期路徑：

Shellcurl -I https://example.com
git ls-remote https://github.com/example/project.git
npm config get proxy
npm config get https-proxy

如果 TUN 已啟用，但 Clash 連線列表完全沒有對應紀錄，通常代表流量沒有經過該核心，或應用程式使用了特殊網路命名空間。若列表有紀錄但請求逾時，則應檢查策略組、DNS 解析、節點品質與 TLS 錯誤，不要反覆開關 TUN。

Git、套件管理器與 Docker 的分別處理方式

Git：先分清 HTTPS 與 SSH

Git 使用 HTTPS 時，通常可以透過系統代理、環境變數或 Git 自己的設定工作；但若你曾經執行過 git config --global http.proxy，Git 可能會繞過你以為的路徑，直接使用舊設定。請先查看：

Shellgit config --global --get http.proxy
git config --global --get https.proxy
git remote -v

如果你使用 SSH remote，例如 [email protected]:org/repo.git，HTTP Proxy 設定不會自動套用。這時可讓 TUN 在網路層接管，也可以依公司政策透過 SSH 的 ProxyCommand 或本機 SOCKS 轉送。SSH 連線屬於長連線，測試時應觀察是否能穩定完成 clone、fetch 和 push，而不是只看 TCP 是否曾經建立。

npm、pnpm 與 Python 套件下載

套件安裝常常不是只連一個網域。以 npm 為例，metadata 可能來自 registry.npmjs.org，實際 tarball 卻由另一個 CDN 或套件維護者指定的主機提供。只為 registry 寫規則，可能造成「能查版本、下載時逾時」。pnpm、Yarn、pip、Poetry 和 Cargo 也各自有 registry、快取與鏡像設定，應在 Clash 連線紀錄裡找出實際主機，再補充精確規則。

若你已經啟用 TUN，建議不要同時在每個套件管理器裡硬寫不同代理，除非公司環境明確要求。多層代理可能導致重複轉送、憑證驗證失敗或 NO_PROXY 行為不一致。最穩妥的做法是先以 TUN 完成基本測試，再只保留必要的工具層設定。

Docker：宿主機通，不代表 daemon 也通

Docker 是最容易被誤判的場景之一。宿主機的 shell 可以透過 TUN 下載套件，不代表 Docker daemon、Docker Desktop 虛擬機或容器內 DNS 也會使用相同路由。當 docker pull 報 i/o timeout、TLS handshake timeout 或找不到 registry 時，請先分辨錯誤發生在 daemon 拉取映像檔，還是容器啟動後連不到外部服務。

對 Docker Desktop 使用者，應檢查其應用程式內的代理設定與網路模式；對 Linux daemon，則可能要在 systemd 服務層設定代理並重新載入服務。容器內的 HTTP_PROXY、HTTPS_PROXY 與 NO_PROXY 也不會自動等同於宿主機設定。內部 registry、Docker socket、資料庫與服務發現網域通常應列入排除清單，否則容易出現映像檔能拉取、容器卻無法連回公司環境的情況。

DNS、路由與穩定性：避免「偶爾能用」

TUN 開發環境最常見的錯誤，不是完全無法連線，而是同一個指令有時成功、有時逾時。這通常與 DNS 解析結果、策略組自動切換、IPv6 路由或不同工具的連線重試邏輯有關。當網域解析到不適合目前出口的 IP，規則即使命中正確策略，也可能在 TLS 階段失敗。

請在遇到間歇性錯誤時，記下四項資訊：發生時間、目標主機、命中規則、使用節點。若同一主機在數次測試中被分配到不同出口，先把策略組暫時固定到單一穩定節點，再測試 Git 或套件安裝。這能區分「自動選擇導致的波動」與「所有節點都無法連線」。對需要長時間維持的 SSH、WebSocket 或遠端開發連線，固定出口通常比單純追求最低延遲更重要。

現象 優先檢查 處理方向
瀏覽器正常，Git 失敗 Git Proxy、SSH 或 TUN 是否接管 確認 remote 類型與 Clash 連線紀錄
npm 查詢成功，下載逾時 tarball CDN 與實際命中主機 依連線紀錄補規則，不要只放行 registry
Docker pull 失敗 daemon 或 Docker Desktop 網路 在 Docker 層設定代理，並測試 registry
內網服務無法存取 DIRECT 規則、DNS 與私有網段 排除公司網域與內部 IP，避免送往外部節點
SSH 連上後頻繁斷線 節點穩定性與策略組切換 暫時固定節點，觀察長連線是否改善

不要忽略安全邊界：代理設定可能包含帳號、內網網域與開發服務資訊。請避免把完整 YAML、訂閱連結、SSH 金鑰、API Token 或詳細連線紀錄直接貼到公開論壇；分享排障資料前，應先遮蔽憑證與識別資訊。

日常維護與故障回復方法

一套穩定的開發代理環境，重點不只是「今天能連」，而是下週更新訂閱、切換網路或升級核心後仍然知道怎麼回復。建議保留一份已驗證的 profile 備份，記錄核心版本、TUN 堆疊、DNS 模式和自訂規則的變更原因。當出現大範圍錯誤時，可以先停用最近新增的規則或切回備份，而不是直接刪除整個設定。

平時更新 Clash 或 Mihomo 核心時，先閱讀版本說明，特別留意 DNS、路由、TUN stack、IPv6 和規則提供者格式的變化。若作業系統更新後 TUN 無法啟動，請重新檢查網路擴充權限、Service Mode、虛擬網卡狀態與防火牆規則。Windows 上可查看網路介面與服務狀態；macOS 上應確認系統設定中的網路擴充允許項目；Linux 則要檢查 tun 裝置、路由表和 systemd 服務日誌。

排障時最好採用固定順序：先確認 Clash 核心正在執行，再確認 TUN 介面存在，接著確認 DNS 能解析，然後用單一固定節點測試 HTTPS，最後才回到 Git、套件管理器和 Docker。這個順序能把「核心未啟動」「規則未命中」「節點不可用」與「應用程式自己的設定錯誤」分開，避免在多個設定檔之間來回切換。

相較於只依賴系統代理的工具，許多同類方案在終端機、Docker 和 SSH 之間缺少一致的流量視角；有些介面操作簡化了，卻沒有清楚呈現命中規則與連線去向，遇到套件 CDN 或長連線錯誤時便很難定位。Clash 官網 的優勢在於把 Clash／Mihomo 的 TUN、規則、終端代理與開發工具場景放在同一套可檢查的工作流程中，既保留進階設定能力，也用較清楚的步驟降低重複試錯；如果你正準備把 Git、npm、SSH 與 Docker 整合到穩定的開發環境，不妨前往下載，再依本文的基線測試逐項建立自己的代理配置。