前言：為什麼開發者需要終端代理
對程式開發者來說，網路問題往往不是單純的「網頁打不開」。你可能會遇到 GitHub clone 長時間停在某個百分比、git push 突然逾時、npm 或 pnpm 下載套件失敗、Docker 拉取映像檔速度極慢，甚至是 SSH 連線建立後頻繁中斷。這些問題會直接打斷編碼、測試、部署與團隊協作流程。
Clash 的價值不只是讓瀏覽器通過代理連線，更重要的是能按照網域、程序或連線類型分流，讓 Git、套件管理工具、容器工具與 AI 編程服務使用合適的路徑。國內服務可以維持 DIRECT，需要代理的開發平台則交給穩定節點處理，避免全域代理造成不必要的延遲。
本文以 Windows、macOS 與 Linux 常見的終端工作流為主，示範如何確認 Clash 監聽埠、設定 shell 環境變數、為 Git 與 SSH 配置代理，並處理 npm、pnpm、pip、Docker 及 AI 工具的連線問題。文中的指令可直接套用，但請依照你的 Clash 客戶端、核心版本與實際埠號調整。
本篇的工作目標
建立可切換、可檢查、可撤銷的開發者代理環境；Git、套件管理器與 AI 服務走代理，區域服務與內部網域則維持直連。
1Clash 終端代理的基礎設定
開始前，先在 Clash 客戶端確認目前使用的混合埠（Mixed Port）或 HTTP、SOCKS5 監聽埠。許多桌面客戶端預設使用 7890 作為 HTTP 與 SOCKS 混合埠，但這並不是固定值；如果你曾經修改設定，請以「設定」、「一般」或「外部控制」頁面顯示的數值為準。
終端工具通常不會自動讀取 Clash 的系統代理設定，因此需要透過環境變數告訴它代理位置。HTTP 型工具可使用 HTTP_PROXY 與 HTTPS_PROXY，支援 SOCKS5 的工具則可以使用 ALL_PROXY。在本機使用時，代理地址通常是 127.0.0.1 或 localhost。
以下設定只對目前的 PowerShell 工作階段有效，適合先測試代理是否正常：
如果確認沒有問題，再使用系統環境變數或 PowerShell 設定檔永久保存。不要把代理帳號、密碼或訂閱連結直接寫入公開的腳本與版本庫。
在 Bash、Zsh 或相容 shell 中，可以先執行以下指令：
若要每次開啟終端機都載入，可將設定加入 ~/.zshrc 或 ~/.bashrc。不過，建議先以臨時變數驗證，避免某些內部服務、資料庫或公司 VPN 因錯誤代理而無法連線。
先確認代理真的有生效
不要只看命令是否返回結果，還要檢查請求是否經過預期路徑。可以使用 curl -I 測試 GitHub，使用 curl -v 觀察連線階段，也可以在 Clash 的連線頁查看是否出現對應網域。若終端完全沒有流量紀錄，通常代表工具不讀取該環境變數、變數名稱拼寫錯誤，或目前埠號與 Clash 實際監聽埠不一致。
安全提醒
不要在不信任的腳本中使用全域代理變數，也不要把帶有認證資訊的代理 URL 寫入 Git。完成測試後，可用 unset HTTP_PROXY HTTPS_PROXY ALL_PROXY 清除目前 shell 的設定。
2Git、HTTPS 與 SSH 的代理設定
Git 常見的遠端連線方式有 HTTPS 與 SSH，兩者的代理設定方法不同。HTTPS 遠端通常會沿用 Git 的 http.proxy 設定；SSH 則需要透過 OpenSSH 的 ProxyCommand 將連線導向 SOCKS5 代理。先用 git remote -v 查看目前專案採用哪一種方式，再選擇對應方案。
Git HTTPS 遠端
如果遠端網址是 https://github.com/...，可以設定全域代理：
最後一行維持 TLS 憑證驗證，不應為了繞過錯誤而關閉。若只有某一個專案需要代理，建議進入該專案目錄後移除 --global，讓設定只寫入專案的本地 Git 設定。這對公司內部 Git 伺服器尤其重要，因為內部網域可能必須直連。
Git SSH 遠端
若遠端網址是 [email protected]:owner/repository.git，Git 會呼叫 SSH，而 SSH 不會直接使用 http.proxy。在 macOS 或 Linux，可編輯 ~/.ssh/config，加入以下設定：
其中 nc 需要支援 SOCKS5。部分 Linux 發行版的 OpenBSD netcat 參數不同，如果執行 ssh -T [email protected] 時出現參數錯誤，可以改用 connect、ncat 或 Clash 文件建議的代理工具。Windows 內建 OpenSSH 也能讀取 %USERPROFILE%\.ssh\config，但命令工具的參數支援可能依版本不同，應先以 ssh -vT [email protected] 查看詳細輸出。
測試、切換與撤銷
- 測試 SSH 金鑰與代理：
ssh -T [email protected]。 - 查看 Git 目前代理：
git config --global --get-regexp 'http.*proxy'。 - 移除全域 HTTPS 代理：
git config --global --unset http.proxy及git config --global --unset https.proxy。 - 查看實際遠端：
git remote -v，避免把測試推送到錯誤的倉庫。
小撇步
SSH 的 ProxyCommand 只應套用到需要代理的主機。不要把所有 Host * 都導向代理，否則連線公司 Git、跳板機或區域伺服器時，可能出現繞路與權限問題。
3套件管理器、容器與 AI 編程服務
開發者工具的代理設定各自獨立，不能假設只設定 shell 變數就全部生效。npm 會讀取自己的設定檔，pnpm 通常沿用 npm 設定；pip、Composer、Docker 及各種 AI CLI 則可能有不同的環境變數或設定位置。建議每次只修改一個工具，立即測試並記錄結果。
npm、pnpm 與 yarn
以 npm 為例，可以設定代理與註冊表：
若套件下載仍然失敗，先確認是否為 DNS、憑證、權限或註冊表本身的問題。企業環境可能要求使用內部 npm registry，此時不要直接改成公共 registry，而應將內部網域加入 Clash 的直連規則。完成工作後，可使用 npm config delete proxy 與 npm config delete https-proxy 撤銷設定。pnpm 和 yarn 若有自己的全域設定，也要分別查看。
pip、Composer 與 Docker
Python 的 pip 可在命令中指定代理，或透過 HTTP_PROXY、HTTPS_PROXY 環境變數使用。Docker 則分成兩個情境：終端機執行 docker pull 時的用戶端代理，以及 Docker daemon 存取 registry 時的 daemon 代理。後者通常需要修改服務設定並重新啟動，不能只在 shell 中 export 變數。
如果 Docker 使用的是虛擬機或 WSL，127.0.0.1 不一定指向 Windows 主機上的 Clash。此時要確認虛擬環境能否存取主機代理地址，並在 Clash 中允許區域網路連線；同時避免把管理埠暴露到公共網路。
AI 編程服務的穩定使用
AI 編程服務可能同時使用 API、登入頁面、模型下載、WebSocket 與內容分發網域。只代理單一主網域，常會出現登入成功但模型請求失敗、補全停頓或工作階段頻繁重連的情況。應根據服務官方文件整理必要網域，為它們建立獨立策略組，並固定使用同一地區、品質穩定的節點。
對 API 工具而言，優先檢查官方 SDK 的 HTTP_PROXY 支援、API endpoint、TLS 憑證與系統時間。不要把 API key 放入 Clash 設定檔、命令歷史或公開日誌；若使用共享節點，也要理解請求仍會經過代理供應商，敏感程式碼與機密資料應遵循公司安全政策。
4動手建立一套可維護的工作流
下面是一個建議的實作順序。它不會一次改動所有工具，方便你在出現問題時快速定位原因。
- 在 Clash 中確認節點可用，查看 Mixed Port 或 HTTP 埠，並確認模式為規則模式。
- 先用
curl -I https://github.com測試終端是否能經過代理連線。 - 執行
git ls-remote https://github.com/owner/repository.git，測試 Git HTTPS，不要一開始就推送正式分支。 - 若使用 SSH，再執行
ssh -vT [email protected]，從輸出確認是否套用ProxyCommand。 - 最後逐一測試
npm ping、pip或docker pull，並把成功的設定記錄在個人文件中。
常見錯誤的判斷方式
- Connection refused：通常是 Clash 沒有啟動、埠號錯誤，或終端連不到代理地址。
- Could not resolve host：優先檢查 DNS、TUN 模式與代理端 DNS 設定，不要立即反覆更換 Git 設定。
- Operation timed out：可能是節點品質、TCP 連線、SSH 埠 22 被限制，或規則把流量分到錯誤策略組。
- SSL certificate problem：檢查系統時間、根憑證與公司 HTTPS 檢查政策，切勿以關閉 SSL 驗證作為永久解法。
- 登入成功但 API 失敗：查看服務是否使用不同 API 網域、WebSocket 或額外的 CDN 網域。
若 SSH 的 22 埠在目前網路受限，可以依照 Git 服務官方支援方式改用 HTTPS，或使用其提供的替代 SSH 端點。不要隨意把 SSH 流量改到陌生主機，也不要因為「能連上」就忽略主機指紋驗證。第一次連線時應核對官方公布的指紋，避免遭遇中間人攻擊。
建議的分流原則
GitHub、套件公共 registry 與 AI 服務使用穩定代理；公司 Git、內部 registry、資料庫、VPN 與本機開發服務使用直連；規則越具體越容易排查。
常見問題
為什麼瀏覽器可以開 GitHub，但終端機仍然無法 clone？
瀏覽器可能使用系統代理或 Clash 的擴充功能，而終端機不會自動繼承。請先檢查 HTTP_PROXY、HTTPS_PROXY 是否存在，再用 curl 測試。若遠端是 SSH，還要另外設定 ~/.ssh/config，因為 Git 的 HTTPS 代理不會套用到 SSH。
應該使用 HTTP 代理還是 SOCKS5 代理？
Git HTTPS、npm 與多數命令列工具對 HTTP 代理支援較完整，適合作為預設選擇。SSH 和需要較底層轉發的工具則可使用 SOCKS5。若工具同時支援兩者，優先選擇 Clash 當前混合埠，並以實際連線紀錄確認流量是否正確分流。
全域設定代理會不會影響公司內部服務？
會。全域環境變數或 Git 全域代理可能把內部 Git、私有 registry、資料庫管理介面送往外部節點。建議使用 Clash 的 DOMAIN-SUFFIX 直連規則，並以專案級 Git 設定取代盲目全域設定；處理敏感專案時更應遵循公司 IT 與資安政策。
為什麼換節點後 SSH 或 AI 工作階段會中斷？
長連線建立後通常會綁定原本的出口 IP。頻繁切換節點會造成 TCP、SSH 或 WebSocket 重連，也可能觸發服務的風險控制。建議為開發服務建立固定策略組，測試期間不要使用頻繁變更節點的自動負載均衡，並透過 Clash 連線頁觀察重連原因。