Windows 下讓 Git 與 GitHub CLI 走 Clash：HTTPS 克隆與憑證校準完整步驟（2026）

1. 典型症狀：為何瀏覽器正常，git／gh 卻異常

許多開發者遇到的畫面是：Microsoft Edge 或 Chrome 可以順利開啟 github.com，但在同一台電腦、同一條寬頻下，終端機執行 git clone https://github.com/... 卻長時間沒有進度，或直接報 連線重設、握手逾時。這類問題在 Windows 上特別常見，原因往往不是 Git 安裝包壞掉，而是 GUI 應用程式會讀取系統代理或使用自己的網路堆疊，而 命令列行程預設未必繼承你在 Clash 圖形介面裡勾選的「系統代理」行為，尤其是在混用 Git Bash、PowerShell 7 與 Windows Terminal 不同設定檔時，環境變數是否繼承、是否被公司腳本覆寫，都會造成「只有 Git 失敗」的錯覺。

另一種更具迷惑性的症狀，是 HTTPS 克隆偶爾成功，但推送或 fetch 時跳出驗證相關訊息，或在換節點後突然要求重新登入。此時除了檢查 PAT／Fine-grained token 是否過期，更要懷疑：Git Credential Manager 在背景取得權杖時所走的網路路徑，與你手動執行 git 時的路徑不一致。當 Clash 規則把 github.com 與 api.github.com 分到不同策略組，或其中一段流量誤判為 DIRECT 卻被區域網路阻擋，就會出現「網頁端 OAuth 正常、CLI 端 token 刷新失敗」的割裂現象。使用者真正想解的是：單一、可重現的出口策略，讓 git、gh 與憑證元件對同一組網域使用相同的代理決策。

2. HTTPS 與 SSH：你要對齊的是哪一條路

HTTPS 克隆會向 443 埠建立 TLS 連線，流量特徵與一般網頁類似，最易與 HTTP_PROXY／HTTPS_PROXY 這類慣例對齊；也是 Git Credential Manager 預設介入較深的路徑。SSH（[email protected]:...）則走 22 埠或自訂埠，代理方式通常要改用 ProxyCommand 或依賴 TUN 在更底層攔截，與本篇以「環境變數 + Clash 規則」為主的講法不完全相同。若你尚未決定協定，且希望步驟與 npm／pnpm 的 HTTP_PROXY 設定一致，優先採 HTTPS 遠端 URL 會最直覺。

若團隊規範強制 SSH，請另外在 ~/.ssh/config 設計好跳板或確認 TUN 真能涵蓋 ssh 行程；並留意公司防火牆是否擋 22。本篇後續預設遠端為 https://github.com/ 形式，並以此對齊 gh 的預設 API 端點。

3. 環境變數：HTTP_PROXY、HTTPS_PROXY 與 Git 設定

在 Windows 上，最單刀直入的方式是在你每日撰提交錄所用的 Shell 裡，把代理指到本機 Clash 監聽的 mixed-port（常見為 7890，實際請以你的設定為準）。格式通常為 http://127.0.0.1:PORT：Clash 會在該埠提供 HTTP CONNECT，讓 HTTPS 請求也能被轉發。

務必同時設定 HTTPS_PROXY；若只設 HTTP_PROXY，部分工具仍會嘗試對 443 直連，症狀會像「輕量測試成功、clone 大儲存庫仍失敗」。跨平台腳本若引用小寫的 http_proxy，在 PowerShell 亦建議一併對齊，或在團隊文件中明定「以 PowerShell 為標準 Shell」，避免複製貼上來源不一致。

# Session-only proxy for Git and gh in this window
$env:HTTP_PROXY   = "http://127.0.0.1:7890"
$env:HTTPS_PROXY  = "http://127.0.0.1:7890"
$env:NO_PROXY     = "localhost,127.0.0.1,::1"
git clone "https://github.com/octocat/Hello-World.git"

Git 另有 http.proxy／https.proxy 設定項；若與環境變數互相矛盾，會出現「同一指令在 A 視窗成功、B 視窗失敗」。建議用 git config --global --get-regexp proxy 做一次棚卸，必要時以 git config --global --unset 清掉過時值，改由環境變數統一管理，較容易與 gh、npm 等工具共用同一套語意。

NO_PROXY 應列出必須直連的本機或內網主機；請勿隨意把 github.com 放進略過清單，否則在本機需要代理才能連 GitHub 時，反而會讓流量撞上錯誤的出口。若你也跑 企業內網 GitLab，可把該網域加入 NO_PROXY，並在 Clash 規則裡對應 DIRECT，與公開 GitHub 分流並存。

4. GitHub CLI（gh）與 REST／GraphQL 流量

GitHub CLI（gh）預設會呼叫 api.github.com 等端點；在大多數安裝情境下，它會尊重標準的 HTTPS_PROXY 環境變數。若你已在 Shell 設定代理，但 gh auth login 仍無法完成瀏覽器或 token 流程，請交叉確認：① 該視窗是否真的繼承變數；② Clash 日誌是否出現對 api.github.com 的連線；③ 是否有額外的 GH_HOST 或 Enterprise 設定把流量導向自架網域卻未納入規則。

與純 git 不同的是，gh 亦會處理 Issue、PR、Workflow 等高階 API；若你的規則集僅涵蓋 github.com 而漏掉 api.github.com，容易出現「網頁能開、gh pr list 卻報錯」的落差。實務上建議把常見 GitHub 維運網域收斂到同一策略組，再在該組選擇穩定節點，比起在多個策略組之間跳動更符合終端機工具的預期。

5. Git Credential Manager 與代理／直連混用

Git Credential Manager（常見縮寫 GCM）負責在 Windows 上儲存與刷新 GitHub 憑證；其運行時可能以獨立進程與 OAuth 端點通訊。若你的互動式 Shell 已設好 HTTP_PROXY，但 GCM 啟動的程式沒有繼承同一環境，可能出現「clone 第一次成功、稍後 fetch 要求重新登入」或 token 刷新逾時。排查時可優先確認：全系統或使用者層級是否另有代理設定、是否有安全軟體攔截本機回呼 URL。

另一常見陷阱是長期在全球模式與規則模式之間切換，導致既有憑證快取與實際出口地區不一致；不一定會立刻報錯，但在觸發 GitHub 風控或 IP 信號變化時，使用者會誤以為是「帳號被封」。較穩健的做法是：為開發工作階段固定一種分流策略，並以 Clash 連線日誌確認 GCM 相關請求與 git 主行程命中同一策略組。

若你希望完全改走 PAT 並降低瀏覽器 OAuth 依賴，可依官方文件設定個人存取權杖；但仍要注意 PAT 請求同樣會經過 TLS，代理與 DNS 模式必須一致，否則錯誤訊息依然會指向「驗證失敗」而非網路層。遇到棘手案例時，暫時清除與 GitHub 相關的儲存憑證後，在已確認代理生效的單一視窗內重新登入，往往能縮小變因。

6. Clash／mihomo 規則與相關網域

Clash（含 mihomo 核心）匹配規則時，通常依由上而下第一個命中決定策略。為讓 Git／gh 穩定，建議將 github.com、api.github.com、codeload.github.com、objects.githubusercontent.com 等與克隆與 LFS 相關的網域，收斂到你為開發者保留的策略組；並把公司內網、本機服務維持 DIRECT 於更前段，避免誤傷。

若你使用 Fake-IP 或 Sniffer，規則看到的是還原後的網域名稱或解析結果，與瀏覽器網址列不一定同一層資訊；當規則「寫了卻像沒生效」，請先用連線日誌確認 實際 SNI 與策略組命中順序。下列片段僅為結構示意，策略組名稱請替換為你設定檔中的實際名稱。

# Example — replace policy group label with yours
rules:
  - DOMAIN-SUFFIX,internal.corp,DIRECT
  - DOMAIN-SUFFIX,github.com,🔰 GitHub
  - DOMAIN-SUFFIX,api.github.com,🔰 GitHub
  - DOMAIN-SUFFIX,codeload.github.com,🔰 GitHub
  - DOMAIN-SUFFIX,objects.githubusercontent.com,🔰 GitHub

若你的設定與訂閱尚未匯入完成，可先依 訂閱匯入教學 建立基礎策略組與 DNS，再回頭微調 GitHub 相關網域。若指令實際跑在 WSL2，請改參考 WSL2 走 Windows Clash，因為其中的 127.0.0.1 指向的是 Linux 子系統，而非宿主機上的 Clash 埠。

7. 驗證指令與除錯清單

建議依序檢查：① Clash mixed-port 在本機是否可連、日誌是否出現對 GitHub 的 CONNECT；② 目前 Shell 的 HTTP_PROXY／HTTPS_PROXY（PowerShell 可用 Get-ChildItem Env:HTTP_PROXY）；③ git config 是否殘留舊的 http.proxy；④ gh auth status 是否指向預期主機；⑤ 規則順序是否讓 GitHub 網域確實命中代理策略組而非早先的 DIRECT／REJECT。

常見錯誤訊息包含：Failed to connect、SSL certificate problem、403 或 rate limit 提示。請先區分是TCP 連不上、TLS 憑證不被信任，還是HTTP 層被拒絕；第一類多與代理／規則／DNS 有關，第二類在公司根憑證或自簽環境需另行處理，第三類則可能與 token 權限或 API 限制有關，不宜一味加大代理強度。