開發者 Clash 終端機代理與 TUN 模式實戰指南

先理解開發者代理的流量範圍

對一般瀏覽器使用者而言，開啟系統代理後可以正常瀏覽網站，往往就代表設定大致可用；但開發工作流包含的連線類型更多。終端機中的 git、套件管理器、容器工具、SSH 外掛、語言伺服器與 AI 編程工具，可能各自使用不同的網路函式庫，也可能完全不讀取作業系統的代理設定。此時只開啟系統代理，不能保證所有開發工具都能經過 Clash。

TUN 模式的作用，是在作業系統中建立虛擬網路介面，將符合路由條件的 IP 流量交給 mihomo 核心處理。它與 HTTP 或 SOCKS5 代理的差異，在於應用程式不需要主動支援代理協定；只要連線經過系統路由，就有機會被 TUN 接管。因此，TUN 特別適合處理不提供代理設定的工具，以及同時使用多種網路函式庫的開發環境。

設定 mihomo TUN 模式與 DNS

在 Clash Verge Rev、Mihomo Party 或其他採用 mihomo 核心的用戶端中，TUN 通常位於「設定」→「系統設定」、「服務」或「TUN 模式」區域。不同用戶端的開關名稱可能是「啟用 TUN」、「Service Mode」或「系統接管」。Windows 可能需要安裝服務或授予系統管理員權限；macOS 則可能要求允許網路擴充功能。若權限未完成，介面看似已開啟，實際上仍可能沒有虛擬介面。

TUN 的核心設定通常包括堆疊類型、路由自動設定、嚴格路由與 DNS 劫持。桌面開發環境可以先使用較保守的設定，確認連線穩定後再調整。以下是常見的 mihomo 配置示意，實際欄位仍應以目前核心版本與用戶端支援程度為準。

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route: true 會嘗試將系統流量導入 TUN；auto-detect-interface: true 適合筆記型電腦在 Wi-Fi、乙太網路與 VPN 介面之間切換。strict-route 可以減少部分流量繞過虛擬介面的情況，但若同時使用公司 VPN、虛擬機器或 WSL，可能需要依環境調整。不要在不了解路由表的情況下強行新增大量自訂路由，否則可能造成區域網路、內部 Git 服務或 Docker 網段無法存取。

TUN 啟用後的三項檢查

1. 確認虛擬介面存在：在系統網路介面中查看名稱包含 mihomo、Clash 或 Meta 的介面。若完全沒有出現，優先處理服務權限與核心啟動問題。
2. 確認連線進入核心：開啟 Clash 的「連線」或「日誌」頁面，執行一次 curl，觀察是否出現目標網域、命中規則與策略組。
3. 確認 DNS 沒有分流錯誤：如果日誌顯示網域解析失敗、解析到不可達位址或內部網域被送往公開 DNS，應檢查 DNS 模式與 fake-ip-filter。

開發環境經常同時存在 127.0.0.1、區域網路位址、Docker bridge 網段與公司內網網段。對內部 Git、資料庫或測試服務，不應一律套用代理。可以在規則中將私有網段與本地域名交給 DIRECT，但規則順序必須放在廣泛的代理規則之前，並透過連線頁確認實際命中結果。

rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,github,PROXY
  - MATCH,PROXY

讓終端機、Git 與套件管理器走對代理

啟用 TUN 後，多數終端機請求可以不設定代理直接運作；但保留明確的命令列代理設定，仍有助於在關閉 TUN 時進行可重複測試。常見 mixed-port 是 7890，但這不是固定標準，請以用戶端「設定」→「連接埠」或目前配置中的實際值為準。

# macOS、Linux、Git Bash
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:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local

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

設定環境變數後，可以先用測試命令確認是否生效。curl -I https://github.com 會顯示 HTTP 回應標頭；如果 Clash 連線頁出現 GitHub 網域，代表請求至少已經進入核心。若終端機回應 Could not resolve host，應先處理 DNS；若顯示 Connection refused，則通常是本機連接埠錯誤、核心未啟動或代理類型填寫不符。

Git 的設定與撤銷方式

Git 可以使用全域 HTTP 代理，也可以只對特定主機設定。建議在需要穩定驗證時使用主機限定設定，避免公司內部 Git 或本地測試服務被不必要地送往代理節點。

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

# 查看目前設定
git config --global --get-regexp 'http.*proxy'

# 不再使用 Git 的明確代理
git config --global --unset http.https://github.com.proxy
git config --global --unset https.https://github.com.proxy

Git over HTTPS 的代理連線成功，不代表 Git over SSH 也會成功。[email protected]:帳號/專案.git 使用的是 SSH 連接埠，通常是 22；它不會自動讀取 HTTP 代理設定。若公司網路封鎖 SSH，應改用 HTTPS 遠端網址，或另外建立 SSH 的 ProxyCommand。修改遠端網址後，可用 git remote -v 檢查是否仍然指向預期的協定。

npm、pnpm 與 Python 套件下載

npm 與 pnpm 通常可以讀取 HTTP_PROXY、HTTPS_PROXY，也可以在各自的設定檔中指定代理。若同時設定了環境變數與 registry 代理，排查時要先確認沒有舊值覆寫新值。

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 registry

# 還原為不使用 npm 明確代理
npm config delete proxy
npm config delete https-proxy

套件來源與網路代理是兩件不同的事。npm 預設 registry、公司私有 registry 與鏡像來源可能需要不同的認證和網域規則；當下載出現 401 或 403 時，不要只切換節點，也要檢查 token、registry 位址與登入狀態。對 pnpm，除了代理設定，也要留意全域 store 是否已有損壞的壓縮檔；可以先執行一次完整的套件驗證，再判斷是否為網路問題。

處理 Docker Hub 與容器內的代理邊界

Docker 是開發者最容易誤判的部分。主機上的 curl 能經過 Clash，只代表主機程序的連線正常；docker pull 實際上可能由 Docker daemon 發出請求，而 Docker daemon 的服務環境與使用者終端機不同。尤其在 Linux 上，daemon 常以 systemd 服務執行，不會自動繼承目前 Shell 的 HTTP_PROXY。

如果 docker pull nginx 出現 registry 逾時，先在 Clash 連線頁查看是否看得到 registry-1.docker.io、auth.docker.io 等目標。完全沒有記錄，通常表示 Docker daemon 沒有使用主機代理；有記錄但回應錯誤，才進一步檢查節點、DNS、憑證與 Docker Hub 的登入狀態。

Linux 上可以為 Docker daemon 建立代理環境設定，修改後必須重新載入 systemd 並重啟 Docker。以下是概念範例，連接埠請替換為目前 Clash 的實際 mixed-port：

sudo mkdir -p /etc/systemd/system/docker.service.d

sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'EOF'
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=localhost,127.0.0.1,.local"
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker
docker info

Docker Desktop 則應在應用程式的「Settings」→「Resources」或「Proxies」區域查看代理選項，實際位置會隨版本和作業系統不同。不要假設 Docker Desktop 一定能使用主機上的 127.0.0.1；在虛擬化環境中，這個位址可能指向容器或虛擬機器自身，而不是主機的 Clash。若改用區域網路位址讓 Docker 存取，必須同時確認 Clash 的 allow-lan、監聽位址與防火牆，並避免把代理服務暴露到不可信網路。

建置映像檔與容器內連線

docker pull、docker build 和容器執行階段是三條不同路徑。即使 pull 已經成功，Dockerfile 中的 apt、npm 或 pip 仍可能無法連線；這些命令在建置容器內執行，需要透過 build arguments 或 Dockerfile 設定代理。另一方面，執行中的容器若要呼叫外部 API，也需要在容器環境中設定代理或確保 TUN 可以接管 Docker 網路。

• 先確認 daemon 能取得基礎映像檔，再測試 Dockerfile 內的套件下載。
• 只在需要的建置階段傳入代理，不要把含有認證資訊的代理網址永久寫入映像檔層。
• 將 localhost、資料庫服務名稱與內部網域加入 NO_PROXY，避免內部服務繞行外部節點。
• 建置完成後檢查映像檔歷史紀錄，確認沒有把帳號、權杖或完整訂閱網址寫入。

設定 Cursor 與 AI 編程工具的連線

Cursor、VS Code 外掛及其他 AI 編程工具通常不只有一條連線。登入、更新檢查、模型請求、擴充功能下載與遙測可能使用不同的網域和 HTTP 用戶端。某些版本會讀取作業系統代理，某些版本則提供獨立的 HTTP proxy 欄位；啟用 TUN 後，未提供代理欄位的連線通常較容易被接管，但仍會受到 DNS、TLS 憑證、企業防火牆與規則分流影響。

排查 Cursor 時，先不要同時修改多個設定。可以依序完成以下流程：先確認瀏覽器能開啟登入頁，再確認 Cursor 本身的登入狀態，接著查看「Help」→「Toggle Developer Tools」或「Output」中的錯誤，最後在 Clash 連線頁搜尋相關網域。若 Cursor 沒有任何連線記錄，可能是應用程式使用了獨立網路程序或受到系統防火牆阻擋；如果有連線但 TLS 失敗，則要檢查系統時間、根憑證與企業 HTTPS 檢查工具。

若使用 VS Code 相容的設定，可以在設定搜尋 http.proxy、http.proxySupport 與 http.proxyStrictSSL。不建議為了暫時繞過憑證錯誤而長期關閉嚴格 SSL 驗證；這會降低編輯器外掛與登入連線的安全性。較正確的做法是確認代理是否正在重新簽發憑證、系統是否已安裝可信根憑證，以及目前連線是否本來就應該走公司內部代理。

用一組固定測試確認整條鏈路

完成 TUN、終端機與工具設定後，應使用固定順序測試，而不是同時執行多個大型下載。先清除可能殘留的舊環境變數或重啟終端機，再確認 Clash 核心、策略組與規則模式正常。測試結果最好記下時間、節點、命中規則與錯誤訊息，方便比較切換 TUN 前後的差異。

1. 用 curl -I https://github.com 測試終端機 HTTPS。
2. 用 git ls-remote 測試 Git HTTPS 遠端，但不要立即執行完整 clone。
3. 用 npm view npm version 測試套件 registry，而不是直接安裝大型依賴。
4. 用 docker pull 下載一個小型公開映像檔，並同時查看 Docker daemon 日誌。
5. 在 Cursor 中重新登入或執行一個簡單請求，對照應用程式 Output 與 Clash 連線記錄。

當 TUN 啟用後出現無法連線、系統網路變慢或虛擬機器失去網路，先關閉 TUN 驗證問題是否消失，再查看路由表和 DNS。不要直接刪除所有規則或切換到全域模式長期使用，因為這只能暫時避開規則錯誤，無法解釋哪些內部服務應該直連、哪些外部服務需要代理。完成測試後，將設定收斂為最少必要的代理、DNS 與路由規則，通常比堆疊多個代理工具更穩定。

常見問題