開發者 Clash 工作流實戰：穩定連線 GitHub、Git 與 SSH

先釐清開發工具的連線路徑

開發者使用 Clash 時，最容易遇到的問題不是節點完全不可用，而是瀏覽器可以開啟 GitHub，終端機中的 git clone 卻停在連線階段；或 GitHub 網頁正常，Copilot、npm、套件更新與 SSH 推送卻頻繁逾時。這是因為不同工具可能使用不同的代理入口、DNS 解析方式與傳輸協定，不能只用瀏覽器是否正常來判斷整台電腦的代理已經完成。

一個完整的開發工作流，通常包含四個連線層級：Clash 核心負責節點、規則與轉送；作業系統代理負責讓遵循系統設定的應用程式進入 Clash；終端機工具則可能依賴環境變數或自身設定；Git 與 SSH 還有各自的傳輸方式與設定檔。當其中一層沒有接上，表面上就會出現「GitHub 連不上」這種籠統錯誤。

1. 瀏覽器：通常讀取系統代理或瀏覽器自己的代理設定。
2. 終端機：常見做法是讀取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 環境變數。
3. Git over HTTPS：Git 可能使用自己的代理設定，也可能繼承系統環境變數。
4. Git over SSH：SSH 通常不會自動讀取 HTTP 代理，需要透過 ProxyCommand 或其他明確設定連接本機 SOCKS 入口。
5. npm 與其他套件工具：可能各自保存 registry、代理、憑證與逾時設定。

Clash 的連線清單與日誌是最重要的觀察入口。執行測試指令時，查看是否出現對應的網域，例如 GitHub API、原始碼下載網域、套件 registry 或 SSH 目標。如果終端機已回報錯誤，但 Clash 完全沒有新連線，優先檢查代理環境變數與工具自身設定，而不是立即切換節點。

Clash 基礎準備：固定連接埠與規則策略

在設定開發工具之前，先在 Clash Verge、Clash Verge Rev、Mihomo 或其他相容用戶端中確認目前設定已成功載入。至少要確認核心正在執行、訂閱中的策略群組有可用節點、規則模式沒有持續報錯，以及混合連接埠或 HTTP、SOCKS 連接埠的實際數值。文件中的 7890 只是常見範例，不能直接假定每個用戶端都使用相同連接埠。

開發工作流建議先採用規則模式。GitHub、套件 registry 與程式碼託管服務可依規則交由代理策略群組處理，其他本地服務與公司內網則保留直連。全域模式可以在短時間內協助判斷節點是否可用，但不適合長期取代規則模式，因為套件下載、內部 Git 伺服器與區域網路服務可能因此走錯路徑。

如果只希望讓本機應用程式使用代理，通常可以先開啟系統代理，再為終端機工具設定明確環境變數。若某些程式不遵循系統代理、需要 UDP，或必須接管沒有代理選項的應用程式，才考慮啟用 TUN。TUN 能涵蓋更廣泛的 IP 流量，但會加入虛擬介面、路由、DNS、防火牆與權限等變數，不宜在尚未確認一般代理可用時直接啟用。

終端機設定：讓命令列工具進入 Clash

終端機不一定會因為開啟系統代理而自動使用 Clash。跨平台最常見的做法，是在目前 Shell 工作階段設定代理環境變數。若 Clash 的混合連接埠支援 HTTP 與 SOCKS5，可以先使用它進行一般測試；如果用戶端分開提供 HTTP 與 SOCKS 入口，則應依實際介面填入正確連接埠。

# Bash / Zsh，僅套用於目前工作階段
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

# PowerShell，僅套用於目前工作階段
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7890"

這些環境變數會影響目前 Shell 啟動的程式，但不同程式對變數名稱的支援並不完全一致。有些工具只讀取大寫名稱，有些同時接受小寫名稱；在需要兼容多種工具的環境中，可以一併設定小寫版本。若代理連接埠沒有使用驗證資訊，不要自行加入帳號密碼。若本機代理確實設定了認證，則應避免把含有密碼的指令寫入公開腳本或 Shell 歷史記錄。

# 查看目前 Shell 是否已設定
env | grep -i proxy

# PowerShell
Get-ChildItem Env:*proxy*

# 清除目前工作階段的代理
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
# PowerShell
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY

設定完成後，可先用簡單的 HTTPS 請求測試，而不要立即執行大型複製或套件安裝。測試時觀察 Clash 連線清單是否出現目標網域。如果請求回傳代理連線錯誤，可能是連接埠類型填錯，例如把 SOCKS 入口當成一般 HTTP 代理使用；如果請求完全沒有進入 Clash，則可能是工具忽略了環境變數或目前 Shell 沒有繼承設定。

Git over HTTPS：處理 clone、fetch 與 push

Git over HTTPS 通常比較容易與 Clash 配合，因為 Git 可以透過 HTTP 代理建立到遠端 HTTPS 服務的連線。Git 的代理可以設定為全域，也可以只對特定主機生效。若日常同時使用公開程式碼平台與公司內部 Git 伺服器，不建議不加區分地設定全域代理；更安全的方式是針對需要代理的主機建立條件式設定。

# 查看目前 Git 代理設定
git config --global --get http.proxy
git config --global --get https.proxy

# 設定全域 HTTPS 代理，範例連接埠需依 Clash 實際設定調整
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 --unset http.proxy
git config --global --unset https.proxy

設定 Git 代理後，可使用設定檢視指令確認最後生效的來源。Git 設定可能來自系統層級、使用者層級、目前儲存庫層級與環境變數；儲存庫內的設定可能覆蓋全域值。當「明明設定了代理卻沒有生效」時，先查看目前儲存庫是否有 .git/config 中的 http.proxy，以及是否存在額外的環境變數。

# 檢視所有 Git 設定及來源檔案
git config --list --show-origin

# 只對特定主機套用代理
git config --global http.https://github.com.proxy http://127.0.0.1:7890

如果 git clone 卡住，先區分卡在 DNS、建立代理連線、TLS 握手，還是下載物件。增加 Git 的低層偵錯輸出可以協助查看請求階段，但輸出可能包含遠端主機名稱與認證相關資訊，不宜直接貼到公開討論區。若 HTTPS 代理已通過而仍然在傳輸中斷，還要檢查節點負載、遠端服務狀態、儲存庫大小與本地磁碟空間。

不要以關閉 TLS 驗證作為一般排障手段。設定 http.sslVerify=false 會降低傳輸安全性，不能解決正常的代理路由問題。若公司環境使用受信任的企業憑證，應依管理員提供的 CA 憑證方式設定，而不是永久停用憑證驗證。

Git over SSH：用 ProxyCommand 連接本機代理

SSH 與 Git over HTTPS 的最大差異，是 SSH 本身通常不理解 HTTP 代理環境變數。直接設定 HTTP_PROXY 後，git@主機:帳號/專案.git 形式的 SSH 連線仍可能繞過 Clash。要讓 SSH 流量經過本機代理，需要在 SSH 設定檔中指定轉接命令，將 SSH 連線交給能夠連接 SOCKS 或 HTTP 代理的工具。

若作業系統已提供 nc 且支援 SOCKS5，可以在 ~/.ssh/config 中加入類似設定。主機名稱、連接埠與參數需依作業系統版本和工具實作調整；部分 Windows 環境使用的 netcat 參數可能不同，不能直接照抄所有 Unix 範例。

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

上例表示 SSH 先呼叫本機的 SOCKS5 代理，再由 Clash 轉送到目標主機的 SSH 連接埠。若 Clash 只提供 HTTP 代理，則需要使用支援 HTTP CONNECT 的轉接工具；不要把 HTTP 代理網址直接填入 ProxyCommand 後期待 SSH 自動理解。也可以為不同主機建立不同 Host 區段，避免公司內部 Git 伺服器與公開服務共用同一套路由。

SSH 金鑰驗證與代理路由是兩個獨立問題。即使 SSH 已經成功通過 Clash 到達遠端，金鑰檔案權限錯誤、使用者名稱不正確、遠端沒有登錄公鑰，仍會出現驗證失敗。反過來，金鑰完全正確，但 Clash 沒有接管 22 連接埠，也可能在 TCP 連線階段逾時。

# 測試 SSH 連線並查看詳細階段
ssh -vT [email protected]

# 只測試使用指定設定檔
ssh -F ~/.ssh/config -vT [email protected]

npm 與套件工具：分開處理 registry、代理與憑證

npm 的下載來源由 registry 決定，代理設定則控制 npm 如何連線到該來源。兩者不是同一件事。即使 Clash 已經能讓瀏覽器開啟套件網站，npm 仍可能因為自身保存了錯誤 registry、過期代理或不適用的憑證設定而失敗。先查看目前值，再依需求修改，避免把暫時排障設定永久寫入所有專案。

# 查看 npm 目前設定
npm config get registry
npm config get proxy
npm config get https-proxy

# 使用目前使用者層級的 HTTP 代理
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# 排障完成後移除 npm 代理設定
npm config delete proxy
npm config delete https-proxy

如果使用私有 registry，應確認它是否需要直連、公司 VPN 或內部 DNS。把所有 registry 都送入外部代理，可能導致內部網域無法解析，或觸發企業安全政策。較穩妥的做法是先確認公開 registry 的連線，再依專案或組織規範設定私有來源，不要因為一次逾時就把 registry 永久切換成不明鏡像。

npm 安裝出現憑證錯誤時，先區分代理連線失敗與 TLS 憑證驗證失敗。不要以 strict-ssl=false 作為常規解法，因為這會放寬套件下載的憑證驗證。若網路環境確實需要企業 CA，應將正確 CA 憑證交由 npm 或作業系統信任庫管理，並確認代理沒有被錯誤設定為需要帳號密碼卻未提供認證。

Copilot 或其他編輯器擴充功能也可能使用編輯器自身的網路層，不一定完全繼承終端機中的 npm 或 Git 設定。遇到擴充功能逾時時，先查看編輯器的代理選項、輸出面板與登入狀態，再檢查 Clash 是否出現對應連線。不要只修改 Git 設定，因為 Git 代理不會自動套用到所有桌面應用程式。

動手操作：建立一條可重複的排查流程

以下流程適合在 GitHub、Git SSH 或 npm 同時出現問題時使用。每一步只修改一個變數，並記下結果。如此可以避免同時更換節點、模式、DNS、代理連接埠與 Git 設定，最後卻無法判斷是哪個變更真正解決問題。

1. 確認核心：在 Clash 用戶端確認目前設定已啟用，策略群組中有可用節點，模式暫時保持 Rule。
2. 確認入口：記下 HTTP、SOCKS 或 mixed-port 的實際數值，不要直接沿用其他電腦的設定。
3. 測試終端機：在目前 Shell 設定環境變數，執行簡單 HTTPS 請求，觀察 Clash 是否出現連線。
4. 測試 Git HTTPS：確認 Git 的代理設定來源，再對小型公開儲存庫執行讀取測試。
5. 測試 SSH：加入最小化的 Host 設定，使用詳細模式檢查是否經過 ProxyCommand。
6. 測試套件工具：查看 npm registry、proxy 與 https-proxy，確認它們沒有殘留無效值。
7. 回看連線：對照目標網域、命中規則、策略群組、節點與錯誤時間，判斷故障位於哪一層。
8. 清理暫存設定：測試結束後移除不再需要的全域代理，避免內部服務被錯誤轉送。

可以使用下表快速對照現象與優先檢查方向：

若只有某一個網域逾時，先不要把結論擴大到整個 Clash。可能是規則將該網域分配到 DIRECT、策略群組選到故障節點、DNS 回應不適合目前路徑，或遠端服務正在限流。短時間切換到 Global 可以協助確認規則問題，但測試後應恢復 Rule，並將正確的分流邏輯放回覆寫設定或規則提供者中。

安全與維護：代理設定不要變成新的風險

開發環境中的代理設定可能包含敏感資訊。訂閱網址通常帶有可識別帳戶或流量權限的憑證，SSH 私鑰、npm token、Git 認證與企業 CA 也不應出現在截圖、公開儲存庫或除錯貼文中。分享日誌前，先移除完整網址、Authorization 標頭、使用者名稱、內部主機名稱與本地路徑。

本機代理監聽位址也需要注意。若 Clash 只監聽 127.0.0.1，通常只有本機程式可以使用；若設定為允許區域網路存取，則應同時檢查防火牆、存取控制與 Wi-Fi 網路可信度。不要為了讓另一台裝置方便連線，就在不需要時開放代理入口到所有介面。

設定全域 Git 或 npm 代理後，記得考慮公司內網、localhost、私有 Git 服務與區域網路 registry。可以使用工具提供的主機條件設定、NO_PROXY 或專案層級設定進行分流，但不同程式對 NO_PROXY 的網域、通配符與 IP 寫法支援不完全一致。完成設定後，應分別測試公開服務與內部服務，而不是只確認其中一邊。

常見問題：GitHub、Git 與 SSH 連線