程式開發者 Clash 代理實戰：Git、SSH 與套件管理

開發者為什麼需要單獨處理代理

瀏覽器能正常開啟網站,不代表 Git、SSH 或套件管理工具也能直接連線。瀏覽器通常會讀取作業系統代理設定,但命令列工具各自有自己的網路實作:Git 可能使用 libcurl, OpenSSH 直接建立 TCP 連線,Homebrew 會依賴 curl、Git 與 Ruby 的下載流程,npm 則同時涉及 registry、套件 tarball 與 Git 相依套件。只開啟 Clash 的系統代理,並不能保證這些請求全部被接管。

常見症狀包括 git clone 停在百分之零、ssh: connect to host ... port 22: Operation timed out、Homebrew 更新公式庫失敗,以及 npm 顯示 ETIMEDOUT 或 ECONNRESET。這些錯誤不一定代表節點失效,也可能是命令列程式沒有讀到代理、代理類型填錯、Git 與 SSH 使用了不同的連接埠,或某一個相依下載網址沒有命中預期規則。

比較穩定的做法是先在 Clash 中確認一個固定的混合連接埠,再按工具的支援方式逐一設定。混合連接埠通常同時接受 HTTP 代理與 SOCKS5 代理,例如以下設定中的 7890。實際使用時應以目前設定檔的 mixed-port 為準,不要直接複製其他教學的連接埠。

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

Git over HTTPS:先設定最容易維護的方式

使用 HTTPS 位址複製或推送程式碼時,Git 主要透過 HTTP(S) 代理完成連線。這是最容易和 Clash 整合的方式,因為 Git 可直接指定代理入口,不必修改 SSH 設定或額外安裝轉接工具。若 Clash 的混合連接埠是 7890,可先在目前終端機工作階段執行:

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

第一、二行會把設定寫入目前使用者的 Git 全域設定,之後所有 HTTPS 遠端都會套用。第三行用來確認設定是否真的被讀取。若只想測試一次,不希望寫入全域設定,可改用環境變數:

HTTPS_PROXY=http://127.0.0.1:7890 \
HTTP_PROXY=http://127.0.0.1:7890 \
git ls-remote https://code.example.invalid/team/project.git

Windows PowerShell 可使用 $env:HTTPS_PROXY 與 $env:HTTP_PROXY 設定工作階段變數;設定只在目前視窗有效。測試時建議先執行 git ls-remote,因為它只取得遠端參照,不會下載完整工作樹,比較容易判斷是代理連線問題還是儲存庫權限問題。

檢查 Git 是否真的走 Clash

測試成功後,可以用以下指令查看 Git 的詳細連線過程:

GIT_CURL_VERBOSE=1 git ls-remote https://code.example.invalid/team/project.git

macOS 與 Linux 的寫法如上;Windows PowerShell 可先執行 $env:GIT_CURL_VERBOSE="1",再執行 Git 指令。詳細輸出中若看到連線先送往 127.0.0.1:7890,通常代表 Git 已經使用本機代理。若仍直接連線遠端的 443 埠,應檢查是否存在更高優先級的環境變數、專案內的 .git/config 覆寫,或 Git 版本讀取的設定檔不是預期位置。

某些公司內部儲存庫不應經過外部節點,可用特定主機的例外設定:

git config --global http.https://code.example.invalid.proxy http://127.0.0.1:7890
git config --global --unset http.proxy
git config --global --unset https.proxy

設定主機專用代理時,規則的主機部分必須和遠端位址一致。若要完全移除全域代理,使用 --unset 後再查詢一次設定;不要只關閉 Clash,因為 Git 仍可能保留已失效的本機代理入口,最後顯示「connection refused」而不是清楚的直連結果。

SSH 連線:用 ProxyCommand 穿過 SOCKS5

SSH 通常不會自動讀取 Git 的 http.proxy,也不會因為瀏覽器能代理就自動改走 Clash。SSH 預設直接連線遠端主機的 TCP 22 埠,而這個連接埠在部分網路環境中可能被封鎖或限速。要讓 SSH 透過 Clash,需要在 ~/.ssh/config 中加入 ProxyCommand,把 SSH 的 TCP 流量交給支援 SOCKS5 的轉接程式。

macOS 與多數 Linux 發行版可使用系統內建的 nc。設定檔範例如下:

Host code.example.invalid
  HostName code.example.invalid
  User git
  Port 22
  ProxyCommand nc -x 127.0.0.1:7890 -X 5 %h %p
  ServerAliveInterval 30
  ServerAliveCountMax 3

-x 指定 SOCKS5 代理位址,-X 5 指定 SOCKS5 協定,%h 會代換成目標主機,%p 會代換成目標連接埠。ServerAliveInterval 不是代理設定,而是讓長時間閒置的 SSH 工作階段定期送出保活封包,可降低網路設備清除連線狀態造成的中斷。

1. 建立或開啟使用者目錄下的 .ssh/config,Linux 與 macOS 可執行 mkdir -p ~/.ssh。
2. 把上面的主機設定替換成實際的程式碼託管主機,保留 %h 與 %p 不變。
3. 確認 Clash 的 SOCKS5 入口與設定檔中的連接埠一致,不要把只支援 HTTP 的入口填入 nc -X 5。
4. 執行 ssh -Tv [email protected],從詳細輸出確認 ProxyCommand 已被套用。

Windows 內建 OpenSSH 的行為取決於版本與所使用的 netcat 實作。有些環境沒有支援 -x 的 nc.exe,這時可安裝相容的轉接工具,或改用 mihomo 的 TUN 模式直接接管 SSH 流量。啟用 TUN 後,仍要確認規則沒有把目標主機送往 DIRECT,並在 Clash 連線記錄中觀察 22 埠請求。

Homebrew 與 npm:分別處理下載來源

Homebrew 不只有一個下載點。更新時可能連線到公式庫與 cask 資料,安裝時還會依公式提供的 URL 下載原始碼、預編譯套件或二進位檔。最穩妥的方式是先以環境變數做一次測試,確認 curl 類工具可以透過 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:7890
brew update

HTTP_PROXY 與 HTTPS_PROXY 適合大多數 HTTPS 下載流程,ALL_PROXY 則可能被部分工具採用。若同時存在多個代理變數,不同程式的優先順序可能不同,排查時可先只保留與協定相符的變數。確認有效後,再決定是否把它們寫入 shell 設定檔;在共用電腦或公司網路環境中,不建議無條件永久寫入。

npm 有自己的代理設定,可直接指定 HTTP 與 HTTPS:

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 ping

npm ping 用來測試目前 registry 是否能回應,比直接安裝大型套件更適合定位問題。若專案透過 Git URL、SSH URL 或安裝腳本下載額外內容,npm 的代理設定不一定能涵蓋後續工具;這時還要分別檢查 Git、SSH 或系統層 TUN。

若只想在單一專案使用代理,可把設定寫入專案的 .npmrc,不要使用全域設定:

npm config set proxy http://127.0.0.1:7890 --location=project
npm config set https-proxy http://127.0.0.1:7890 --location=project

專案完成後可用 npm config delete proxy --location=project 與對應的 https-proxy 移除。若錯誤是憑證驗證失敗,不要用永久關閉 TLS 驗證的方式繞過問題;先確認系統時間、企業憑證、Node.js 版本與 Clash 是否被中間設備重新簽發憑證。調高逾時只適合處理慢速網路,不能修復錯誤的代理協定。

規則分流與故障排查順序

開發者流量不適合一律套用全域代理。程式碼託管、套件 registry、容器映像與文件服務可能位於不同地區,應以網域規則分流,而不是只依賴 IP 或程序名稱。mihomo 設定中可以先保留內網直連,再把需要代理的開發服務交給專用策略組:

rules:
  - DOMAIN-SUFFIX,corp.example.invalid,DIRECT
  - DOMAIN-SUFFIX,code.example.invalid,Developer
  - DOMAIN-SUFFIX,registry.example.invalid,Developer
  - GEOIP,CN,DIRECT
  - MATCH,Developer

上例中的 Developer 必須是設定檔中真實存在的代理節點或策略組名稱。若託管服務使用多個 CDN、重新導向主機或套件下載網域,只寫一個主網域後綴可能不夠,需要從 Clash 連線記錄找出實際命中的網域,再補充規則。規則順序仍然遵循第一個命中即停止,不要把 MATCH 放在清單中段。

1. 先確認 Clash 本身有可用節點,在用戶端測試延遲,並暫時切換到全域模式作為對照。
2. 確認本機代理入口可用,例如以 curl -x http://127.0.0.1:7890 https://example.invalid 測試代理通道是否接受連線。
3. 分別測試 DNS 與 TCP,執行 nslookup 或 dig,再用 Git、SSH、npm 的最小測試指令驗證。
4. 在 Clash 記錄頁搜尋目標主機,查看實際命中的規則、策略組、連接埠與是否出現重試。
5. 確認工具端沒有重複代理。環境變數、Git 全域設定、專案設定與 npmrc 同時存在時,先清掉多餘項目再重新測試。
6. 最後才調整節點或逾時參數。若 HTTPS 成功但 SSH 失敗,通常是 SSH 沒有套用 ProxyCommand,不應直接更換所有節點。

日常使用的安全與維護細節

代理設定可能包含帳號、權杖與內部主機資訊。不要把帶有認證資訊的代理 URL 提交到 Git 儲存庫,也不要把含有私人 registry 權杖的 .npmrc 放進公開專案。若公司使用內部憑證,應按照組織規範安裝 CA,不要以 strict-ssl=false 或關閉 SSH 主機金鑰檢查作為長期解法。

本機代理通常只監聽 127.0.0.1,這能避免區域網路其他裝置直接使用你的入口。若設定 allow-lan: true,必須同時限制允許的位址、設定防火牆規則與足夠複雜的控制面板密鑰,否則同一網路內的其他裝置可能把你的電腦當成公開代理。開發用電腦也不建議隨意暴露外部控制 API。

完成設定後,可把 Git 與 npm 的代理檢查指令整理成專案文件,但不要寫入真實訂閱連結或私人認證。當切換辦公室、家庭網路或 VPN 環境時,先檢查 Clash 是否仍在執行、混合連接埠是否變更、TUN 是否取得授權,再開始修改工具設定。若不再使用代理,應移除 Git、npm 與 shell 中的殘留設定,避免下次 Clash 關閉後所有開發工具都指向不存在的本機連接埠。

常見問題