Windows 下让 Git 与 GitHub CLI 走 Clash：HTTPS 克隆与凭据校准完整步骤（2026）

1. 为何 Git 与 gh 比浏览器更难「自动跟代理」

浏览器通常会读取系统代理或由扩展接管；而 Git 与 gh 作为终端进程，除非显式配置 HTTP_PROXY、HTTPS_PROXY（或在 Git 里设置 http.proxy），否则往往直连出站。与此同时，Git Credential Manager可能在图形界面或后台进程里为你缓存了 GitHub 登录态：当你后来强制终端走本地 Clash 入站时，旧的令牌入口或交互路径可能不一致，表现为同一仓库「网页能开、clone 却 403／401」。要把链路理顺，需要同时看清三件事：TCP 连接有没有进到 mixed-port、TLS 主机名在规则里落到哪个策略组、以及凭据存储里是哪一把钥匙。

与包管理器场景对照阅读可大幅减少重复踩坑：Windows 上 npm／pnpm 走 Clash一文强调的是 HTTP_PROXY 与 NO_PROXY 对齐 registry；本文则在同类变量之上，专门补上 Git over HTTPS 与 gh 的 OAuth／PAT 行为。若你还在 IDE 里跑 MCP 并依赖 GitHub 传输链，可再看 MCP 与 npm、GitHub 分流，二者与本篇意图错位：那边面向协议工具链，本篇面向「裸终端里的 git／gh」。

2. Clash 侧：入站端口、系统代理与日志

请先在客户端里确认本机 mixed-port（或 HTTP 代理端口）监听在 127.0.0.1，且浏览器已能稳定访问 GitHub。若订阅本身拉取异常，请先完成 订阅导入与基础连接，不要把「节点不可用」误判为 Git 配置问题。

使用 Verge Rev 等发行版时，「系统代理」与内核实际监听端口可能只在 GUI 里对齐了一部分；建议对照 Windows 11 Verge Rev 系统代理与 TUN，确认 WinHTTP／系统代理与你准备在终端里写的 127.0.0.1:端口一致。TUN 模式下，部分进程会被内核旁路捕获，但 Git／gh 仍建议用显式代理变量做最小可复现实验：先变量打通，再决定是否只靠 TUN。

排障时请打开连接日志，观察 github.com、api.github.com、codeload.github.com 等主机是否出现、命中哪条规则。若主机名与你想像的不一致，应以日志里的真实解析结果为准补规则，而不是凭记忆写域名。

3. Windows 终端：HTTP_PROXY、HTTPS_PROXY 与 NO_PROXY

在 PowerShell 会话中（端口改为你的 mixed-port），典型写法如下：

# PowerShell: Git and gh honor standard proxy env vars toward local Clash
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY   = "http://127.0.0.1:7890"
$env:NO_PROXY    = "localhost,127.0.0.1,::1,.local"

HTTPS_PROXY 的值通常仍是 http://127.0.0.1:端口，含义是「通过本地 HTTP CONNECT 隧道访问远端 HTTPS」，并非要求 Clash 额外开设 HTTPS 监听。若误写成 https://127.0.0.1:... 而本地只有 HTTP 入站，往往在握手阶段即失败。

NO_PROXY 用于排除公司内网 Git、自建 Gitea／GitLab 等：不要把内网仓库主机漏进代理变量可达范围，否则请求会先钻进 Clash，再由规则送往海外节点，延迟与证书错误都会变得难以解释。若你还在 WSL2 里跑 Git，请参考 WSL2 与 Windows Clash；本文仅覆盖 Windows 本机终端。

持久化环境变量可通过「系统属性 → 环境变量」或 PowerShell Profile；团队文档里应写清「以 CMD／PowerShell／Git Bash 哪一套为准」，避免 IDE 内置终端与外层会话各有一套代理。

4. Git：http.proxy、GIT_SSL_NO_VERIFY 误区与 HTTPS 克隆

除环境变量外，可为 Git 单独指定代理（与会话无关、写入全局配置时对所有仓库生效）：

# Git global proxy pointing at Clash mixed-port
git config --global http.proxy  http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

若某台内网远程必须直连，可为该远程单独取消代理或使用条件配置（例如按 URL 拆 http.*）；不要把「全局关闭校验」当成代理故障的默认解。**不建议**长期开启 GIT_SSL_NO_VERIFY：它会掩盖中间人与证书链问题，在安全环境里更应修复信任链或公司根证书导入。

HTTPS 克隆路径上，Git 会访问 github.com、codeload.github.com 等；若你只给 github.com 做了规则而遗漏打包下载域名，会出现「元数据能谈、objects 拉不下来」的假死。下一步应回到 Clash 日志核对失败请求的真实主机名。

5. Git Credential Manager：令牌、清除与代理混排错

Windows 版 Git 通常 bundled Git Credential Manager（GCM）。首次 clone 私有仓库时，GCM 可能唤起浏览器完成 OAuth，或提示输入 PAT；凭据写入 Windows Credential Locker 后，后续请求不再重复交互。若你曾在直连环境登录过，后来又改为全局走代理，偶尔会遇到权限足够却仍 403 的情况：优先怀疑缓存条目指向了错误的令牌类型或过期 PAT。

处理步骤建议顺序如下：先在当前终端确认 git config --global credential.helper 输出包含 manager；再用 Git 自带的凭据拒绝／擦除命令清理 GitHub 主机条目（具体子命令随 GCM 版本略有差异，请以官方文档为准）；最后在不关闭代理的前提下重新执行一次 git ls-remote https://github.com/...，观察是否重新弹出登录或 PAT 输入。清理旧条目往往比反复切换节点更有效。

对企业 CA 或 HTTPS 扫描设备环境，TLS 错误可能与代理无关；但若叠加 GCM 的代理检测逻辑，日志会更嘈杂。此时可用最小化命令（如对单一 URL 的 curl -v）对照证书链，避免把证书问题误判为「Clash 规则不全」。

6. gh：环境变量、gh auth login 与 api.github.com

gh 客户端默认走 HTTPS 访问 api.github.com 与相关主机，同样读取标准代理环境变量。确保同一终端会话里已导出上一节的 HTTP_PROXY／HTTPS_PROXY 后，执行 gh auth status 查看当前登录身份与主机连通性。

自动化场景可使用 GH_TOKEN（或兼容的 GITHUB_TOKEN）提供 PAT，注意令牌权限范围需覆盖你要调用的子命令（repo、workflow、packages 等）。交互场景下 gh auth login 支持浏览器与 PAT 两种路径：若浏览器在内网策略下无法打开回调地址，可改用 PAT 并粘贴到终端。

gh 与 Git 的凭据存储不一定共用同一套：可能出现「git 已能 push，gh pr 仍报未登录」或相反。分别用 git credential-manager diagnose（若可用）与 gh auth status 对照，避免只修一侧。

7. mihomo 分流：GitHub 常见主机名成组

当你已在终端设置 HTTP_PROXY 指向本机 Clash 时，连接会先进入内核，再由 rules 决定从哪个策略组出站。下面是一段示意性 mihomo 片段（将 PROXY 换成你的代理策略组名），用于把常见 GitHub 主机名归组，减少遗漏：

# Example: group GitHub hosts into one outbound policy
rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,githubassets.com,PROXY
  - DOMAIN-SUFFIX,github.io,PROXY
  - DOMAIN-SUFFIX,api.github.com,PROXY
  - DOMAIN-SUFFIX,codeload.github.com,PROXY
  - DOMAIN-SUFFIX,objects.githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,pkg.github.com,PROXY
  - DOMAIN-SUFFIX,ghcr.io,PROXY

实务上你可能还需要按日志补上 gist.github.com、上传附件相关主机名或企业 GitHub Enterprise 的独立域名。规则顺序仍遵循「从上到下命中即停」：不要把过于宽泛的 DOMAIN-SUFFIX 放在细粒度规则之上，以免开发者 CDN 误匹配。若同一策略组内节点延迟抖动大，可结合站内关于 url-test／fallback 的文章优化组内选路。

8. 排查清单