原理解析 預計閱讀 13 分鐘

Clash 開發者終端機代理與 TUN 工作流實戰

客戶端面板裡那個跳動的延遲數字,很多人把它當成「這條線路好不好用」的唯一依據。但 80ms 和「用起來流暢」之間,中間隔著測試目標、丟包率、頻寬瓶頸和鏈路壅塞四道坎。本文拆開延遲數字的測量方式,說明它到底反映了什麼、又遺漏了什麼,並提供幾種更貼近真實瀏覽體驗的自測手段。

為什麼開發終端機不能只依賴系統代理

在瀏覽器裡打開系統代理後，網頁通常能正常載入，但這不代表整台電腦上的開發工具都會自動走 Clash。系統代理主要提供 HTTP、HTTPS 或 SOCKS 代理設定，應用程式必須主動讀取這些設定，或者自身提供代理欄位，流量才會進入代理核心。瀏覽器、部分桌面應用程式和少數 SDK 通常支援得不錯，命令列工具的行為則不一致。

例如 git 可以透過全域設定指定 HTTP 代理，npm、pnpm、pip 和部分雲端 CLI 也能設定代理，但每個工具的參數名稱、設定檔位置和代理協定支援都不同。某個工具使用 HTTPS 代理，另一個工具只接受 SOCKS5，還有工具完全忽略系統代理。當專案同時需要 Git、套件管理器、容器工具和 IDE 外掛時，逐個設定很快就會變成難以維護的清單。

TUN 模式處理的是另一個層級。mihomo 核心會建立虛擬網路介面，透過路由表接管符合條件的 TCP 和 UDP 流量，再依照規則把連線送往代理、直連或拒絕。應用程式不需要知道 Clash 的監聽埠，也不必提供代理設定，只要流量沒有繞過作業系統的路由層，就有機會被 TUN 接管。

核心概念:環境變數和工具專用代理設定適合精準控制單一命令；TUN 模式適合補上不支援代理設定的工具。兩者不是互相取代，而是先用 TUN 建立基礎接管，再用工具設定處理需要獨立路由或特殊代理協定的場景。

先分清系統代理、環境變數與 TUN 的工作範圍

開發環境最常見的問題不是節點不可用，而是同一條連線到底經過哪一層代理沒有弄清楚。系統代理通常影響會讀取作業系統設定的圖形介面程式；環境變數影響目前 Shell 啟動的命令列程序；TUN 則透過虛擬介面和路由規則接管更底層的流量。三者同時開啟時，某些程式可能先讀取環境變數，再把請求送進 TUN，造成重複代理或連線失敗。

在 macOS、Linux 或 WSL 的 Shell 裡，可以先用環境變數做短時間測試。HTTP 代理和 HTTPS 代理的寫法通常如下，實際埠號要以 Clash 客戶端的設定為準：

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:7891
export NO_PROXY=127.0.0.1,localhost,::1,.local

HTTP_PROXY 和 HTTPS_PROXY 的名稱表示請求類型，不一定代表代理伺服器本身使用 HTTP 或 HTTPS。許多工具對 HTTPS_PROXY 仍接受一個普通的 HTTP CONNECT 代理位址。ALL_PROXY 常用來指定 SOCKS5，但不是所有工具都會讀取它。若工具同時讀取多個變數，通常會優先使用更具體的 HTTP_PROXY 或 HTTPS_PROXY。

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:7891"
$env:NO_PROXY="127.0.0.1,localhost,::1,.local"

這種設定只對目前終端機工作階段有效，關閉視窗後就會消失。正式加入 Shell 啟動檔前，建議先用單一命令驗證，避免把錯誤的代理位址寫進所有專案。測試完成後可以執行 env | grep -i proxy，或在 PowerShell 使用 Get-ChildItem Env:*proxy*，確認是否存在殘留變數。

注意:開啟 TUN 後，如果終端機仍保留指向不存在埠號的 HTTP_PROXY，工具可能先嘗試連錯代理而不是交給 TUN。遇到「瀏覽器正常、命令列逾時」時，先檢查環境變數，再判斷是不是節點或規則問題。

為開發工作設定 mihomo TUN 模式

不同 Clash 客戶端的介面名稱可能不同，Clash Verge Rev、Mihomo 系列客戶端一般會在設定或系統頁面提供 TUN 開關。Windows 通常需要管理員權限建立虛擬網卡與修改路由；macOS 可能需要核准網路延伸功能；Linux 則可能需要相應的網路管理權限。先完成權限授予，再啟用 TUN，否則開關可能短暫亮起後自動關閉。

如果使用可編輯的 mihomo 設定檔，可以參考下面的結構。這段設定是工作流示例，不應直接覆蓋訂閱提供的完整規則；實際欄位是否可用，也要看客戶端所附核心版本。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.internal'
    - 'localhost.ptlogin2.qq.com'

auto-route 讓核心嘗試把系統路由導向 TUN，auto-detect-interface 用來辨識目前可用的實體網路介面，stack: mixed 則通常在 TCP 與 UDP 相容性之間取得較平衡的結果。dns-hijack 會把符合條件的 DNS 查詢導入核心；如果 DNS 沒有被接管，應用程式可能解析出本地網路可見的結果，接著造成規則匹配不準或 DNS 洩漏。

開發機的 DNS 例外不能照抄一般手機或家用裝置設定。公司內網、私有套件倉庫、資料庫服務和容器網路可能使用 .corp、.internal、.lan 或自訂網域。這些網域需要由公司 DNS 或 VPN 提供解析，加入 Fake-IP 例外後仍要確保查詢會送到正確的 DNS 伺服器。若公司 VPN 和 TUN 同時存在，必須確認兩者的路由優先順序，以及 Fake-IP 網段沒有和 VPN 分配的網段重疊。

  1. 先關閉其他 VPN、代理核心和網路加速工具，避免多個虛擬介面同時修改預設路由。
  2. 在 Clash 客戶端中確認核心狀態為執行中，再開啟 TUN，接受系統權限或網路延伸功能提示。
  3. 檢查 TUN 介面是否出現，並確認系統預設路由沒有被寫成無效的下一跳。
  4. 先測試一般網域，再測試私有網域與本機服務，分別確認代理路由和直連路由。
  5. 最後才開啟開機自啟，避免尚未完成例外規則時讓整台電腦每次啟動都進入錯誤路由。

Git、套件管理器與容器工具的實際設定

TUN 開啟後，先不要立即把所有工具都設定成代理。建議先在終端機觀察連線日誌，確認 Git 和套件工具的請求是否已被核心看見。如果 TUN 已經成功接管，工具專用代理只在需要固定走某個入口、或工具本身不支援透明接管時再加入。

Git 的 HTTP(S) 遠端可以使用全域設定，也可以只對單一專案設定。全域設定方便，但容易把公司內網或區域服務也送進代理；專案設定則較容易審查。

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|https\..*proxy'

# 不需要 Git 專用代理時移除
git config --global --unset http.proxy
git config --global --unset https.proxy

如果 Git 的 SSH 遠端使用 git@... 形式，http.proxy 不會影響 SSH。這時應優先讓 TUN 接管 SSH 的 TCP 連線，或在 SSH 設定裡針對特定主機指定代理跳板；不要把 HTTP 代理語法直接填到 SSH 的設定中。若 SSH 仍然逾時，可從 Clash 日誌確認是否出現對應的目標主機和 22 埠連線。

Node.js 專案常見的 npm、pnpm 和 yarn 都有自己的代理設定，但設定可能會被專案級檔案覆蓋。以 npm 為例：

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 專用代理
npm config delete proxy
npm config delete https-proxy

Python 的 pip 可以用單次命令指定代理，這適合排查，不會改動使用者設定：

python -m pip install --proxy http://127.0.0.1:7890 套件名稱

容器工具要分開看待。主機上的 Docker CLI、Docker daemon、容器內的套件管理器並不是同一個網路命名空間。主機終端機能走代理，不代表 daemon 拉取映像時也會使用相同代理；容器內執行 apt、npm 或 pip 時，也可能需要在容器環境變數或建置參數中單獨設定。這也是「主機瀏覽器正常，但 Docker pull 失敗」很常見的原因。

工作對象 優先檢查位置 常見問題
Git HTTP(S) git config 與 Clash 連線日誌 全域代理殘留、內網遠端被誤送代理
Git SSH TUN 路由、SSH 設定、目標埠號 HTTP 代理設定不會自動作用於 SSH
npm / pnpm / pip 工具設定檔、Shell 環境變數 設定檔層級不同，或憑證與代理驗證衝突
Docker daemon daemon 的代理設定與服務重啟狀態 主機 TUN 不等於 daemon 已取得代理環境
IDE 外掛 IDE 網路設定、程序日誌與 TUN 日誌 外掛可能使用獨立網路程序，忽略 Shell 變數

IDE、規則分流與可重複的排錯流程

IDE 通常同時包含內建終端機、語言伺服器、套件索引、遠端開發連線和外掛更新服務。即使內建終端機可以執行 git clone，外掛登入或語言伺服器下載依賴仍可能使用另一個程序。處理這種情況時，不要只在 IDE 的代理欄位裡填一個位址，也不要只看瀏覽器結果；應該把 IDE、Shell 和核心日誌分成三個觀察點。

第一步是建立最小測試。選一個可以穩定存取的公開網域、一個套件倉庫網域，再選一個公司內網網域，分別用瀏覽器、終端機和 IDE 觸發請求。Clash 日誌應能看到目標網域、命中的規則和最後使用的策略組。若瀏覽器有記錄、終端機沒有記錄，可能是終端機走了另一個代理或連線根本沒有離開本機；若三者都有記錄但結果不同，則要比較它們命中的規則和目標埠號。

第二步是把規則按用途拆開。公開程式碼託管、套件倉庫和 AI 服務可以使用代理策略組；公司內網、私有 Git、資料庫、授權伺服器和本機開發服務通常應使用直連或公司 VPN。規則順序很重要，較精確的網域規則要放在寬泛的關鍵字規則之前，否則一條 DOMAIN-KEYWORD 規則可能先攔走本來應該直連的內部主機。

rules:
  - DOMAIN-SUFFIX,example-internal.test,DIRECT
  - DOMAIN-SUFFIX,packages.example.test,DIRECT
  - DOMAIN-SUFFIX,code-host.example,PROXY
  - DOMAIN-SUFFIX,registry.example,PROXY
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

上面的網域只是示意，不能直接當作實際服務清單。私有網域應以團隊提供的清單為準，私有 IP 段也要配合實際網路環境調整。對內網網域使用 DIRECT 並不代表一定能連線，還要確認本機有公司 VPN、正確 DNS 和到內網的路由。

  1. 查看環境代理變數，暫時移除不確定來源的 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY。
  2. 確認 Clash TUN 狀態、DNS 模式、Fake-IP 例外和虛擬介面都正常。
  3. 用 nslookup、dig 或作業系統的 DNS 工具測試公開與內部網域，記錄解析結果是否符合預期。
  4. 在終端機執行一次最小請求，再從 Clash 日誌確認規則、代理組和連線錯誤。
  5. 單獨測試 Git、套件管理器、容器 daemon 和 IDE 外掛，不要一次修改所有設定。
  6. 問題解決後，把真正需要的設定寫入專案文件或使用者設定，並移除臨時命令和過期代理。

安全提醒:不要把帶有帳號、密碼或存取權杖的代理 URL 寫進 Git 設定、Shell 啟動檔、Dockerfile 或專案儲存庫。若工具需要代理驗證，優先使用作業系統或工具支援的安全憑證機制；排錯完成後也要檢查設定檔和命令歷史，避免敏感資訊被長期保留。

穩定的開發工作流通常不是「所有流量一律代理」，而是讓 TUN 負責透明接管，讓規則決定公開服務、公司網路和本機服務的方向，再用 Git、npm 或 pip 的專用設定處理少數特殊工具。當每一層的責任清楚，clone、安裝依賴、拉取映像和 IDE 登入就能用同一套日誌與規則排查，不必在多個客戶端開關之間反覆嘗試。

下載客戶端
下載客戶端