前言：為什麼開發工具需要獨立代理

對開發者來說，瀏覽器能正常開啟網頁，並不代表整台電腦的開發工具都已經套用代理。你可能會遇到 GitHub 頁面可以載入，但執行 git clone 時速度極慢；瀏覽器能連線，SSH 卻在 Connecting 階段逾時；甚至只是執行 brew update，終端機就長時間停在下載索引的畫面。這些現象通常不是專案或套件本身故障，而是不同程式採用不同的網路連線方式。

Clash 的系統代理、TUN 模式與終端機環境變數並不完全等價。Git 會讀取自己的代理設定，OpenSSH 主要依賴 ~/.ssh/config，Homebrew 則會受到 Git、Curl、環境變數及其下載工具影響。因此，開發者需要把程式碼庫、SSH 遠端連線、套件管理器與容器映像檔視為幾條獨立的流量路徑，分別確認它們是否真的經過 Clash。

本文目標

使用 Clash 建立清晰、可撤銷且容易排查的開發代理設定，讓 Git、SSH、Homebrew 與常見容器工具各自使用合適的連線方式。

1先確認 Clash 的代理入口

開始修改 Git 或 SSH 之前，先在 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 或 Mihomo 客戶端中確認目前使用的混合代理埠。常見設定是 7890，但實際數值可能因客戶端或自訂設定而不同。請以 Clash 控制面板顯示的 HTTP、HTTPS 或 SOCKS5 入口為準，不要直接複製其他文章中的埠號。

檢查 HTTP 與 SOCKS5 入口

如果終端機工具主要支援 HTTP 代理，通常可以使用 http://127.0.0.1:7890。需要 SOCKS5 的程式則可使用 socks5://127.0.0.1:7891。有些 Clash 配置會將兩者合併成 mixed port，因此同一個埠可以同時接受 HTTP 與 SOCKS5 請求。若你開啟了 TUN 模式，部分應用程式可以直接被接管，但命令列工具仍建議明確設定代理，這樣更容易判斷問題來源。

終端機連線測試

將下方埠號替換成你的 Clash 實際設定，先測試代理是否能正常建立 HTTPS 連線：

curl -I -x http://127.0.0.1:7890 https://github.com
curl --proxy socks5h://127.0.0.1:7891 https://api.github.com

使用 socks5h 而不是單純的 socks5，可以讓網域解析也交給代理處理，減少本機 DNS 解析造成的失敗。若指令回傳 HTTP 標頭，代表代理入口至少可以連線；若出現 Connection refused，應先檢查 Clash 是否正在執行或埠號是否正確。

安全提醒

不要把 Clash 的外部控制器或代理埠公開綁定到區域網路，除非你清楚設定了驗證密碼與防火牆規則。開發機上的代理入口原則上應只監聽 127.0.0.1。

2GitHub 與 Git 的代理設定

Git 支援以 HTTP 代理存取 HTTPS 遠端，也可以為特定網域單獨指定代理。若你的遠端網址是 https://github.com/帳號/專案.git，最直接的做法是設定 Git 的全域代理。這項設定會影響目前使用者下的大多數 Git 專案，但不會自動影響 SSH 遠端。

設定 HTTPS clone、pull 與 push

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 config --global --get https.proxy

設定完成後，建議先用一個公開且較小的 GitHub 專案測試 git ls-remote 或 git clone。不要一開始就用數 GB 的大型倉庫，因為下載時間過長會把節點速度、磁碟效能與 Git LFS 問題混在一起。

只代理 GitHub 網域

如果你希望公司內部 Git 服務或區域網路倉庫維持直連，可以不要設定全域代理，而只針對 GitHub 設定：

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

這種寫法適合同時使用 GitHub 與內部 GitLab 的情境。若代理之後不再需要，請清除相關設定，避免日後在沒有開啟 Clash 時看到難以理解的連線錯誤：

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

小撇步

若 clone 速度忽快忽慢，先確認 Clash 策略組沒有頻繁切換節點，再檢查 GitHub 大檔案是否使用 Git LFS。代理只能改善網路路徑，無法解決 LFS 儲存庫權限或配額問題。

3SSH clone 與 push 的 ProxyCommand 配置

許多開發者將 GitHub 遠端改成 [email protected]:帳號/專案.git，這時 Git 不會使用前面設定的 HTTP 或 HTTPS 代理。OpenSSH 會直接連線到 TCP 22 埠，而這個埠在某些網路環境中可能被阻擋或不穩定。更可靠的方式，是在 SSH 設定中使用 Clash 的 SOCKS5 入口，並以 ProxyCommand 將 SSH 流量轉交給代理。

編輯 ~/.ssh/config

在 macOS 或 Linux 中，可以建立或編輯 ~/.ssh/config；Windows 使用者則可在使用者目錄的 .ssh/config 中加入相同內容：

Host github.com
    HostName github.com
    User git
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

這裡的 nc 必須支援 SOCKS5 代理參數。部分 macOS、Linux 發行版與 Windows 環境內建的 Netcat 參數並不一致。如果執行時出現 invalid option，可改用 Ncat、connect-proxy 或客戶端附帶的代理工具，並依其說明調整命令。另一個常見選擇是讓 SSH 連到 GitHub 的 443 埠：

Host github.com
    HostName ssh.github.com
    User git
    Port 443
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -x 127.0.0.1:7891 -X 5 %h %p

設定好後，使用詳細模式測試：

ssh -T -v [email protected]

輸出中若能看到代理命令被執行，並最後出現 GitHub 的驗證提示，通常代表 SSH 路徑已建立。請注意，GitHub 不會提供一般 Shell 登入；看到「successfully authenticated」一類訊息即可。若仍然失敗，依序檢查私鑰權限、SSH agent、GitHub 公鑰，以及 Clash 是否允許該節點連線到 SSH 或 443 端口。

不要混用兩套代理

SSH 已經透過 ProxyCommand 轉送時，不需要再把 HTTPS_PROXY 強行套到 SSH。重複代理可能造成連線逾時、握手失敗或難以判斷的認證錯誤。

4Homebrew、Curl 與容器工具的環境變數

Homebrew 會下載公式索引、預編譯套件與原始碼，過程中可能呼叫 Git、Curl 或其他下載工具。最容易維護的方式，是在需要時於目前終端機工作階段設定代理，而不是永久修改所有系統服務。

暫時套用代理

Homebrew / 命令列步驟

確認 Clash 正在執行，並記下 HTTP 代理埠，例如 7890。
在目前的終端機匯出代理環境變數。
先執行 brew update，再安裝或升級套件。
工作完成後取消環境變數，避免內部服務也被送往代理。

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

brew update
brew install wget
brew upgrade

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

在大小寫敏感的工具中，通常同時設定大寫與小寫變數較穩妥：

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"

如果你使用 Docker、Podman 或其他容器工具，主機上的 127.0.0.1 對容器來說通常指向容器自己，而不是主機。因此，不能直接把主機的 localhost 代理地址當成容器內代理。Linux 上可考慮使用主機閘道地址；Docker Desktop 則常見使用 host.docker.internal，但仍須確認 Clash 是否允許來自該介面的連線。

docker run --rm \
  -e HTTP_PROXY=http://host.docker.internal:7890 \
  -e HTTPS_PROXY=http://host.docker.internal:7890 \
  alpine:latest wget -qO- https://dl-cdn.alpinelinux.org

容器建置時還要注意 Dockerfile 的代理參數、建置快取與套件來源設定。代理只應在建置階段使用，避免把含有內部位址或認證資訊的環境變數寫入最終映像檔。若公司網路有私有 Registry，應為它設定直連或內部 DNS 規則，不要讓所有映像檔下載都經過同一個外部節點。

5分流規則、驗證方法與常見故障

開發代理不宜只追求「全部走代理」。更好的做法是讓 GitHub、套件來源與需要的映像檔走穩定節點，內部 GitLab、公司網域、區域網路主機與本機服務則維持直連。你可以在 Clash 的規則中為常用服務建立獨立策略組，並把規則放在較寬泛的規則之前。

rules:
  - DOMAIN-SUFFIX,github.com,Developer
  - DOMAIN-SUFFIX,githubusercontent.com,Developer
  - DOMAIN-SUFFIX,githubassets.com,Developer
  - DOMAIN-SUFFIX,ghcr.io,Developer
  - DOMAIN-SUFFIX,公司內部網域,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

上面的策略組名稱必須與你的 proxy-groups 實際名稱一致。不要盲目加入大量關鍵字規則，否則可能把一般程式碼託管服務、內部鏡像站或登入請求分到錯誤節點。對 SSH 而言，Clash 通常只能根據目的網域或 IP 分流，真正的代理轉送仍由 SSH 的 ProxyCommand 負責。

按照順序排查問題

先測試 Clash 入口： 使用 curl -I -x 確認代理埠有回應。
再測試 DNS： 若網域解析到錯誤地址，改用 socks5h 或檢查 Mihomo 的 DNS、Fake-IP 與 TUN 設定。
檢查 Git 設定： 執行 git config --global --list，確認沒有殘留失效代理。
檢查 SSH 詳細輸出： 使用 ssh -vT，分辨是代理連線、金鑰認證還是遠端端口問題。
確認節點穩定性： 固定一個延遲低、連線穩定的節點，不要在 clone 或 push 過程中頻繁切換。
檢查 Git LFS 與套件鏡像： 大型檔案和套件下載可能使用不同網域，不能只測試主 GitHub 網頁。

當所有工具都能連線後，仍建議觀察 Clash 的連線日誌。日誌可以顯示請求實際命中的規則、使用的策略組與目標地址，這比單純反覆切換節點更有效率。若日誌完全沒有出現請求，代表程式可能未使用系統代理、環境變數未生效，或 SSH、容器正在使用自己的網路命名空間。

完成檢查

理想狀態是：HTTPS Git 能正常 clone，SSH 能通過驗證，Homebrew 可完成更新，容器能拉取必要映像檔，同時公司內部服務仍可保持直連。

結語：建立可控的開發網路

Clash 並不是只要開啟系統代理就能自動解決所有開發網路問題。Git 的 HTTP 代理、SSH 的 ProxyCommand、Homebrew 的環境變數，以及容器內部的主機地址，各自有不同的設定層級。將它們拆開理解，再配合明確的分流規則與逐步測試，就能避免「瀏覽器正常、終端機失效」這類反覆出現的問題。

建議把設定記錄在自己的開發環境文件中，註明 Clash 代理埠、SSH 使用的工具、哪些網域走代理，以及如何一鍵取消代理。當你更換客戶端、節點或工作場所時，只需逐項驗證，不必重新摸索整套流程。

開發者必學的 Clash Git、SSH 與 Homebrew 代理設定