核心思路是按域名定向代理而非全局代理，仅对github.com配置HTTP代理，其余域名直连；需确保本地代理软件开启HTTP服务、允许局域网访问，并验证代理连通性及DNS解析正常。
核心思路不是“强行加速”，而是让 Git 请求精准走代理、其余流量完全不干扰——关键在按域名定向代理，而非全局一刀切。
只给 GitHub 配代理，国内仓库照常飞快
全局代理会让访问 Gitee、GitLab.cn、公司内网 Git 也绕路，反而更慢。正确做法是为 github.com 单独设规则：
- 执行命令（端口替换成你本地代理的实际端口，比如 7890 或 1080）：
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.com 的 HTTPS 请求走代理，其他域名（如 gitee.com、coding.net）完全直连，零延迟、零干扰
- 验证是否生效：运行
git config --global --get http.https://github.com.proxy，应输出你的代理地址
确认代理服务本身已就绪
Git 代理只是“转发指令”，前提是你的本地代理工具（Clash、Shadowrocket、V2RayN 等）正在运行且端口开放：
github-repo-analyzer
下载
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
- 打开代理软件，确保状态为“已连接”，并记下它的HTTP/S 代理端口（不是 SOCKS5 端口，除非你明确配置支持）
- 在终端执行：
curl -I https://github.com -x http://127.0.0.1:7890，若返回 HTTP 200，说明代理通；若超时或报错，则先排查代理服务 - 常见错误：代理开了但没开启“允许来自局域网”或“HTTP 代理服务未启用”，需进软件设置里勾选
避免 DNS 污染导致的“假超时”
有时 git clone 卡在“解析 github.com”阶段，根本没发请求出去。这时即使代理正常也白搭：
- 临时用 IP 克隆测试是否 DNS 问题：
先查 github.com 当前 IP（如dig github.com +short或访问 githubstatus.com 查推荐 IP），再试：git clone https://<strong>20.205.243.166</strong>/microsoft/vcpkg.git（IP 仅示例，请替换为真实可用 IP） - 若 IP 方式成功，说明 DNS 被污染，建议：
• 修改系统 DNS 为 223.5.5.5（阿里）或 114.114.114.114
• 或在~/.gitconfig中加一行：[url "https://20.205.243.166/"] insteadOf = https://github.com/
进阶：WSL / Docker 环境下别漏掉网络桥接
如果你在 WSL2 或容器里用 git clone，代理地址不能写 127.0.0.1 —— 那是指 WSL 自己的回环，不是 Windows 主机：
- Windows 主机上查本机 IPv4 地址（如
ipconfig中的“无线局域网适配器 WLAN”下 IPv4 地址） - 在 WSL 里配置时，把
127.0.0.1换成那个真实 IP，例如：git config --global https.https://github.com.proxy http://192.168.1.100:7890 - 同时确认 Windows 防火墙放行了该端口（入站规则），否则 WSL 请求会被拦截
