開發者 Clash 實戰：Git、SSH 與 Homebrew 代理工作流

開發者為什麼需要獨立的 Clash 代理工作流

對一般瀏覽器使用者而言，打開系統代理後能正常載入網頁，往往就代表代理已經生效；但對開發者來說，Git、SSH、Homebrew、npm、Docker與各種 CLI 工具可能各自採用不同的代理機制。瀏覽器遵循系統代理，不代表終端裡的 git 會自動使用同一個出口；ssh 通常直接建立自己的 TCP 連線，brew 則可能同時存取 GitHub、套件 CDN 與二進位下載站。只要其中一環沒有命中 Clash 規則，就會出現「網頁能開、程式碼拉不下來」的落差。

常見症狀包括 GitHub clone 長時間停在百分之零、git push 回報 connection reset、SSH 公鑰驗證明明正確卻在握手階段逾時，以及 brew update 可以取得部分索引，卻在某個 formula 或 cask 下載時卡死。這些問題不一定代表節點速度不足，更常見的原因是不同工具走了不同路徑：Git 的 HTTPS 遠端可能遵循 Git 設定中的 proxy，SSH 遠端則不會讀取 http.proxy；Homebrew 還可能受到 shell 環境變數、Git 設定與下載器行為的共同影響。

因此，建立開發者代理環境時，建議先把流量拆成三類：第一類是程式碼與套件來源，例如 GitHub、GitLab、npm registry 與 Homebrew 資源；第二類是SSH 遠端連線，包括公司 Git 伺服器與代管平台；第三類是本地或企業內網，例如 localhost、公司網域與內部 API。三類流量不一定要使用同一個策略，但必須能被清楚觀察、驗證與回復。

動手前：確認 Clash、埠號與系統代理狀態

無論你使用 macOS 上的 Clash Verge Rev、ClashX、Mihomo，或 Windows 上的 Clash Verge Rev、Mihomo Party，第一步都不是直接修改 Git 設定，而是確認核心確實在運作。打開客戶端後，先查看目前使用的設定檔、核心版本、運行模式與本機監聽埠。常見的 mixed-port 可以同時接收 HTTP 與 SOCKS5 流量，開發工具通常比較容易統一接入；如果你只開啟了 SOCKS5 埠，卻把 http://127.0.0.1:7890 填入 Git，可能會得到連線被拒絕或協定錯誤。

請在 Clash 的連線頁確認代理請求是否持續出現。測試時不要只打開首頁，而應該實際執行一次 git ls-remote、一次 SSH 連線，以及一次 Homebrew 更新，然後觀察日誌裡的主機名稱、連接埠與命中策略。若日誌完全沒有記錄，通常表示工具沒有經過 Clash，問題應先回到環境變數、Git 設定或 SSH 設定，而不是急著更換節點。

macOS 的系統代理可以在「系統設定 → 網路 → 目前網路介面 → 詳細資訊 → 代理伺服器」查看；Windows 則可在「設定 → 網路和網際網路 → Proxy」檢查。系統代理主要影響遵循作業系統設定的應用程式，並不會自動改寫所有終端程式。若公司 VPN、PAC 腳本、舊加速器或安全軟體同時存在，還可能把流量導向另一個出口。排障前最好先記下原有設定，完成測試後才能準確復原。

Git HTTPS：只代理需要的遠端與套件來源

Git 使用 HTTPS 遠端時，最容易控制的方式是設定 Git 自己的代理。先查看目前是否存在舊設定，避免你以為正在使用 Clash，實際上仍指向已關閉的公司代理或其他軟體。可使用 git config --global --list --show-origin 檢查來源；全域設定、專案設定與系統層級設定可能同時存在，越接近目前專案的設定通常優先級越高。

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp 'http\..*proxy'

如果 Clash 的混合埠是 7890，Git HTTPS 常見寫法如下。埠號必須依你的客戶端實際設定調整，不能因為別人的教學使用 7890 就直接照抄。若你的 mixed-port 支援 HTTP CONNECT，使用 http:// 前綴通常比把它誤寫成 socks5:// 更容易與 Git 的 HTTPS 流量配合。

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

設定完成後，先不要立即執行大型 clone。可以用一個小型公開儲存庫或遠端參照測試，確認請求是否出現在 Clash 日誌。若遇到憑證錯誤，不要直接加入 http.sslVerify false 來「修好」問題；這會讓 Git 在傳輸過程中失去重要的憑證驗證。應先檢查系統時間、根憑證、企業 TLS 攔截與代理是否正確轉送 SNI。

對不需要代理的內網 Git 伺服器，可以使用 NO_PROXY 或 Git 的例外設定，避免內部流量繞到公共節點。若你同時處理公開 GitHub 專案與公司 GitLab，不建議粗暴地把所有網域都交給同一策略組。比較穩定的做法是按照網域後綴與實際工作需求建立規則：公開代管服務走代理，公司內網與 VPN 可達的主機保持直連，並透過連線日誌確認判斷符合預期。

切換網路環境時如何清理 Git 代理

開發者最常忽略的是「代理設定會留下來」。你在旅館網路中為了 clone 設定全域代理，回到公司或家中後，即使關閉 Clash，Git 仍會嘗試連接 127.0.0.1:7890，於是看起來像 GitHub 故障。需要停用 Git 代理時，可以移除對應欄位，而不是把網址改成另一個不確定的埠。

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

若同一台電腦有多個工作專案，也可以避免使用全域設定，改在單一儲存庫內設定。這樣可以讓公司專案與個人專案各自使用不同的代理策略，降低把公司內網網址送到公共代理的風險。每次修改後，以 git config --show-origin --list 確認實際生效來源，比只看命令是否回傳成功更可靠。

SSH：GitHub push 失敗時先分辨 22 埠與替代入口

SSH 與 Git HTTPS 是兩條不同的路徑。當遠端網址是 [email protected]:owner/repository.git 時，Git 會呼叫 SSH，而不是使用前面設定的 http.proxy。因此，HTTPS clone 成功不能證明 SSH push 一定能用；反過來，SSH 成功也不代表 Homebrew 的 HTTPS 下載沒有問題。排查時先執行詳細模式，觀察 DNS 解析、實際連線埠、金鑰交換與驗證階段各自停在哪裡。

ssh -vT [email protected]
ssh -G [email protected]
git remote -v

如果輸出顯示卡在連接 22 埠，可能是目前網路封鎖了 SSH 常用埠，也可能是 Clash 規則沒有讓這條 TCP 流量走適合的節點。這時可以在 ~/.ssh/config 為特定主機指定代理命令。使用 Mihomo 或其他支援 SOCKS5 的本機代理時，常見方式是透過系統已安裝的 nc 或相容工具建立 SOCKS5 轉送；不同 macOS、Windows 與 nc 版本的參數可能不同，應先用 nc -h 確認語法。

Host github.com
    HostName github.com
    User git
    Port 22
    ProxyCommand nc -x 127.0.0.1:7890 -X 5 %h %p

這段設定的重點不是固定某個埠號，而是讓 SSH 明確知道應該經過哪個本機 SOCKS5 入口。若你的 Clash 只提供 mixed-port，請確認客戶端是否允許 SOCKS5 連線；若不支援，就應改用專門的 SOCKS 埠，或採用 SSH over HTTPS 的替代配置。修改後可用 ssh -G github.com 檢查 proxycommand 是否真的被解析，然後再執行 ssh -vT。

看到 GitHub 回覆「successfully authenticated」通常只代表金鑰驗證成功，不代表你對所有儲存庫都有權限，也不代表 git push 的遠端路徑正確。若驗證成功但 push 被拒絕，應檢查儲存庫權限、分支保護、遠端 URL 與帳戶對應；若連驗證訊息都沒有，才繼續追查 Clash、DNS、埠號與 ProxyCommand。這種分層可以避免把權限問題誤判成代理問題。

Homebrew：更新、formula 與 cask 為什麼會走不同網域

Homebrew 的「更新卡住」經常不是單一下載失敗，而是多段來源鏈中只有一段沒有命中代理。brew update 可能先透過 Git 取得 tap 的變更，接著從 GitHub 或其他代管站拉取索引；安裝 formula 時，Homebrew 會依 formula 內的 URL 下載原始碼；安裝 cask 時，則可能前往軟體供應商、Release CDN 或物件儲存服務。你只把 GitHub 加入策略組，並不代表所有軟體安裝來源都會走同一條路。

先使用診斷命令確認 Homebrew 本身、Git 與本地環境沒有明顯問題。若 Homebrew 顯示權限、Xcode Command Line Tools 或目錄擁有者錯誤，應先處理系統環境，不要把所有錯誤歸因於代理。對下載逾時則要把終端輸出時間點與 Clash 日誌對起來，確認是否有請求進來、請求去了哪個網域，以及策略組是否在中途切換節點。

brew config
brew doctor
brew update --verbose

在 macOS 上，Homebrew 通常會繼承目前 shell 的環境變數，但不同安裝方式、Shell 啟動檔與圖形介面啟動的終端可能並不相同。你可以先查看目前是否存在代理環境變數，再決定是否需要暫時設定。不要把帶有帳密的代理 URL 寫入共享腳本或提交到儲存庫；若代理需要驗證，應使用作業系統的安全憑證管理或只在當次工作階段注入。

env | grep -i proxy
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

HTTP_PROXY、HTTPS_PROXY與 ALL_PROXY 並不是所有程式都以完全相同的方式解析。若你同時設定了 Git proxy、環境變數與 Clash 系統代理，可能形成多層轉送，甚至因協定不匹配而失敗。建議一次只保留一種主要控制方式，測試完成後記錄結果，再逐項加入其他設定。對本機服務、公司內網與容器網路，則應妥善設定 NO_PROXY，例如 localhost、127.0.0.1與內部網域，避免請求被送往外部節點。

Windows 使用者若透過 PowerShell 執行 Homebrew 或其他 Unix 工具，也要注意環境變數只在目前視窗有效，或可能被使用者層級與系統層級變數覆蓋。macOS 使用者則要檢查 ~/.zshrc、~/.zprofile與 CI 啟動腳本是否各自設定了不同代理。最穩定的團隊做法，是在文件中明確寫出「啟用代理」「停用代理」「確認目前設定」三組命令，並禁止把含有私人節點資訊的完整設定檔提交到版本庫。

跨平台排障：從命中規則到最小化重現

當 Git、SSH 或 Homebrew 其中一項失敗時，請採用由近到遠的排查順序。第一層是本機監聽：確認 Clash 核心啟動、埠號未被其他程式佔用，而且客戶端沒有處於全局關閉或暫停狀態。第二層是工具配置：檢查 Git proxy、SSH config、環境變數與 Homebrew 所在的 shell 是否一致。第三層是規則與節點：從連線日誌找出實際主機名，確認流量不是被 MATCH 誤送直連，也不是因為過寬的規則被送往不合適的策略組。第四層才是 DNS、TLS、憑證與上游服務本身。

1. 先記錄失敗命令、時間、作業系統、Clash 客戶端與目前核心版本。
2. 在不改動多項設定的前提下，重現一次並同步查看 Clash 連線日誌。
3. 把失敗拆成 DNS、TCP 連線、TLS 握手、驗證與下載五個階段。
4. 用最小測試取代大型操作，例如用 git ls-remote 取代完整 clone。
5. 每次只改一個變數，成功後立即記錄規則、埠號與工具設定。

如果 Clash 日誌顯示連線已建立，但工具仍然失敗，下一步要看協定層是否匹配。例如把 SOCKS5 代理填入只接受 HTTP CONNECT 的欄位，可能會讓 TCP 已經出現卻在 TLS 前失敗；若 SSH 的 ProxyCommand 可以連到代理，但主機指紋或金鑰交換失敗，問題就不再是單純的路由。反過來，如果日誌完全沒有請求，應優先檢查命令是否使用了另一個 Git、另一個 shell、容器內的環境，或 SSH config 是否被其他 Host 匹配規則覆蓋。

DNS 也值得單獨確認。使用 fake-ip、TUN 或增強模式時，終端工具看到的解析結果可能與系統直連時不同；若某些公司內網名稱必須由企業 DNS 解析，卻被錯誤送到公共 DNS，就算代理節點正常也無法連入。建議把公開服務與內部服務分開測試，並確認 NO_PROXY、DNS 規則與 TUN 路由沒有互相矛盾。不要只以 ping 判斷 HTTPS 或 SSH 是否可用，因為許多服務會封鎖 ICMP，真正有意義的是對應協定的最小化測試。

在 CI、Docker 或遠端開發容器中，主機上的 Clash 也不一定能直接被容器使用。容器裡的 127.0.0.1指向容器自身，而不是宿主機；此時需要使用正確的宿主機位址、允許區域網路監聽的安全設定，並避免把代理埠暴露到不可信網路。企業環境還應確認防火牆、EDR 與網路政策是否允許這種轉送方式。對團隊而言，最好將代理設定透過安全的 CI Secret 或執行環境注入，而不是把固定 IP 與私人認證直接寫入 Dockerfile。

判斷原則：代理設定不是「加上一行環境變數」就結束，而是一條可觀測的工作流。每個工具都要能回答三個問題：它實際連到哪個主機、是否經過 Clash、最後命中了哪個策略。

從功能面來看，單純依賴系統代理的工具常無法完整覆蓋 SSH、容器與自訂下載器；只調整 Git 全域代理又容易遺漏 Homebrew 的套件 CDN，某些商業 VPN 則可能只接管瀏覽器或改寫 DNS，讓開發者很難追蹤真實路徑。Clash V.CORE 的優勢在於能以統一的本機入口承接 HTTP、HTTPS 與 SOCKS5 流量，配合規則、TUN 與連線日誌，把 Git、SSH、Homebrew 的差異放進同一套可觀察的策略框架；如果你希望少一點反覆猜測，多一點可驗證的開發環境控制，可以前往下載 Clash V.CORE，依照自己的 macOS 或 Windows 工作流逐步建立配置。