開發工具為何常常「瀏覽器正常，終端卻不通」

工程師日常連線不是單一的「開網站」：Git 可能透過 HTTPS 或 SSH 存取遠端儲存庫；SSH 需要建立到主機的 TCP 連線；Homebrew 安裝套件時則會查詢套件資訊、下載原始碼或預先編譯的 bottle，並可能呼叫 Git、curl 等工具。這些程式不一定會讀取瀏覽器的代理設定，也未必共用相同的 DNS 解析與系統代理狀態。因此，瀏覽器可以開啟 GitHub，並不能證明終端中的 git clone、ssh 或 brew install 也一定能連線。

使用 Clash 時，先判斷流量是由應用程式自己的代理設定送出、由系統代理接管，還是由 TUN 虛擬網路介面轉送。這三種方式不是同一件事：終端的 HTTPS_PROXY 只影響會讀取該環境變數的程式；系統代理通常供支援系統代理的應用程式使用；TUN 則可在網路層接管更多未設定代理的連線，但會牽涉權限、路由與 DNS。排查時若同時改動三處，連線突然恢復也很難知道真正原因。

建議先選一個穩定的 Clash 節點，確認客戶端正在執行、設定檔已載入，而且代理連接埠沒有被另一個客戶端占用。Mihomo 常見的 HTTP 與 SOCKS 監聽連接埠可能是 7890 和 7891，但實際數值應以目前設定檔或客戶端介面顯示為準。接著一次測試一個工具、一種協定，並在 Clash 的連線紀錄中確認實際命中的規則和策略組；如果日誌沒有出現目標主機，問題通常還在本機代理設定或流量接管範圍。

ℹ 先確認三件事：目前使用的代理連接埠、Git 遠端網址是 HTTPS 還是 SSH，以及該次連線是否出現在 Clash 日誌中。確認這三點後，再決定要調整環境變數、SSH 設定或 TUN。

選擇適合 Git、SSH 與 Homebrew 的代理方式

如果你只需要讓幾個支援 HTTP 代理的命令列工具連線，從應用程式層設定通常最容易理解，也較容易還原。若終端工具沒有提供可用的代理選項，或需要讓多種未設定代理的程式共用同一路徑，才考慮啟用 Clash 的 TUN 模式。TUN 能擴大接管範圍，但不是「開了就一定全部走代理」：路由規則、核心版本、系統權限、DNS 行為與網路介面都會影響結果。尤其是公司 VPN、容器網路或本機虛擬機同時運作時，請留意路由衝突與內部網域是否仍能直連。

macOS 上可在 Clash 客戶端確認系統代理是否已啟用，再開啟新的終端視窗檢查 shell 是否繼承相應設定；Windows 上則應分別確認客戶端的系統代理、終端程式與 WSL 的網路環境。Linux 使用者通常需要更明確地設定環境變數或路由。不同作業系統和 shell 的設定檔位置各異，請先在目前工作階段測試，確認代理可用後再決定是否寫入長期啟動檔。不要把一次性的測試命令直接塞進全域設定，否則停用 Clash 後，終端仍可能指向無人監聽的本機連接埠。

使用 TUN 時，可先用一個不含敏感資料的 HTTPS 網址驗證整條鏈路，再測 Git、SSH 和 Homebrew。若僅在 TUN 啟用時成功，表示相關程式可能沒有自行讀取 HTTP 代理；若只在環境變數生效時成功，則代表該程式支援代理，但 TUN 的規則或路由可能尚未涵蓋目標。這種比較比同時打開系統代理、設定變數並切換全域模式更能縮小問題範圍。

設定 Git：先分清 HTTPS 與 SSH 遠端

先在儲存庫目錄執行 git remote -v，檢查遠端網址的開頭。若是 https://，Git 通常會使用 HTTP(S) 傳輸；若是 git@ 或 ssh://，則會呼叫 SSH。兩者要分別設定與測試。常見誤區是只替 Git 設定 HTTP 代理，卻以 SSH 網址拉取程式碼，接著把逾時誤認為節點故障。反過來，SSH 已通也不代表 HTTPS 代理已生效，因為它們使用的設定入口和連線方式不同。

對 HTTPS 遠端，可先使用 Git 的本機設定指定代理，並以測試儲存庫確認結果。以下示例假設 Clash 的 HTTP 連接埠是 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 http.proxy

這類全域設定會套用至目前使用者的多個 Git 儲存庫。若只想代理特定工作環境，可在單一儲存庫內設定，或先於命令前暫時指定環境變數，確認行為後再選擇長期方案。停止使用代理時，記得檢查並移除自己新增的 Git 設定；否則即使 Clash 已關閉，Git 仍會嘗試連至本機代理埠。還要留意公司內部 Git 主機、localhost 和私有網段通常不應無條件送到外部代理；依環境需求保留直連，並透過日誌確認規則沒有誤將內部服務轉出。

如果遠端網址使用 SSH，請檢查 SSH 本身的代理設定，而不是期待 Git 的 HTTP 代理代替它工作。SSH 不會自動把一般 HTTP 代理當成 SOCKS 代理；常見做法是使用支援 SOCKS5 的 nc，並在 SSH 設定檔為特定主機指定 ProxyCommand。macOS 的 nc 選項會受版本影響，執行前可查看 nc -h 確認是否支援 -X 與 -x。例如，Mihomo SOCKS5 監聽埠為 7891 時，可在 ~/.ssh/config 為目標主機加入類似設定： 

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

儲存前確認主機名稱、連接埠及本機 nc 語法與環境相符。若使用多個 Git 服務，可為不同主機建立各自的 Host 區段，不必將所有 SSH 連線都指向同一代理。改完後先用 ssh -T [email protected] 測試，再執行 git ls-remote 或小型 clone。若 SSH 回報主機金鑰變更、金鑰權限錯誤或帳戶沒有倉庫權限，那是認證或信任問題，不應靠更換代理節點來處理；也不要為了消除提示而停用主機金鑰驗證。

Homebrew 下載套件時的代理與流量分流

Homebrew 的一次安裝可能包含多個步驟：更新或讀取套件資料、抓取 bottle、下載原始碼、執行建置，以及呼叫 Git 或其他外部工具。實際涉及的主機會隨套件、版本和下載來源改變，因此不宜只憑一份過期網域清單就假設所有下載都已涵蓋。先使用 brew update 或一個你熟悉的套件作測試，同時觀察 Clash 連線紀錄；若更新成功、安裝卡在下載，便要進一步辨認失敗的是哪個 URL、哪個程序，以及它命中了什麼規則。

Homebrew 所使用的 curl 通常能讀取常見的 HTTP 代理環境變數，但子程序與不同下載工具的行為不一定完全相同。可在目前終端工作階段暫時設定代理測試，不必一開始就改動 shell 啟動檔： 

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7891

請依照你目前使用的 Clash 監聽設定選擇相符的代理種類，並確認客戶端確實提供該連接埠。設好後可用 env 檢查變數是否存在，再以 curl -I 測試一個可公開存取的 HTTPS 網址，最後才重試 Homebrew。ALL_PROXY 與 HTTP(S) 代理變數可能同時存在；各工具採用哪一個變數會因實作而異，若結果不明，先暫時移除多餘變數，一次保留一種設定來測試。使用完畢可在該終端執行 unset，避免代理變數意外影響其他開發工具或部署指令。

規則分流方面，建議依「用途」而非猜測每個套件的固定下載網域來管理。可先把經常使用的 Git 服務與套件來源歸入一個清楚命名的策略組，再由連線日誌逐步補上實際出現的主機名；對不確定的網域，先觀察再增加規則。過寬的網域後綴可能將不相關服務一併送往代理，也可能增加延遲。反之，若規則集只包含 Git 網頁主站，實際的認證、附件或套件下載端點仍可能落在其他主機。保持規則精簡並可回溯，比一次貼入大量來源不明的規則更容易維護。

逐段測試連線並排除常見錯誤

排障最好遵循「本機代理、DNS、TCP、應用程式認證」的順序。先確認 Clash 核心仍在執行，並確認目標代理埠有程式監聽；再測試終端是否能連到該埠。如果命令回報連線遭拒，通常應先修正客戶端狀態、埠號或本機防火牆，而不是調整遠端 Git 服務設定。若本機代理可用，再觀察目標網域的解析結果及 Clash 日誌：日誌中沒有請求，應回頭檢查工具的代理設定或 TUN；有請求但規則不符，才調整規則或策略組。

如果錯誤訊息涉及 TLS 憑證，先確認系統日期時間正確、憑證鏈可信，並查看公司端點防護或 TLS 檢查設備是否介入。不要以關閉憑證驗證作為長期修復方式。若只有一個節點失敗，可在相同規則下比較另一個可用節點；若不同節點都在相同主機失敗，則更應檢查 DNS、規則順序、遠端服務狀態或本機程式設定。每次只變更一個因素，並保留原始設定副本，才能把偶然恢復與真正修正區分開來。

開發環境還需要把安全性納入設定。不要將代理帳密、訂閱網址、存取權杖或 SSH 私鑰貼進公開日誌，也不要把含有憑證的環境變數寫入共享腳本或提交至 Git。若使用團隊電腦或公司網路，請依組織的資安政策與網路使用規範設定代理；私人 Git、內部套件庫和部署主機也應按其存取要求保留適當路由。完成測試後，記錄實際有效的代理埠、規則用途及還原方法，日後更換客戶端或核心時便能快速重新驗證。

相較於只替瀏覽器設定系統代理，這套做法把 Git 的 HTTPS、SSH 的 SOCKS 代理與 Homebrew 子程序分開處理，能更精準地找到失敗環節；只依賴全域 TUN 又可能讓內網路由與其他 VPN 更難管理。若你希望在同一介面檢查策略、調整分流並測試不同代理模式，Clash V.CORE 可作為日常開發連線的管理選項；可前往下載頁選擇合適版本，再依本文步驟逐項驗證 Git、SSH 與 Homebrew 的實際連線。