git代理配置必须严格匹配协议：https仓库需单独设https.proxy，socks5须用socks5://（非socks://），且http.proxy与https.proxy需分别配置；全局与局部作用域不可混用，验证须结合git config --get和网络流量日志。
Git 设置代理不是“配了就能用”，关键在协议匹配、端口正确、作用域明确。直接套命令容易 clone 失败或 push 超时，尤其是 HTTPS 仓库走 HTTP 代理、SOCKS5 代理写成 socks://（少个 5）这类低级错误，几乎必挂。
git config --global http.proxy 和 https.proxy 必须分开设
很多人以为设了 http.proxy 就自动管 HTTPS，其实 Git 对 https:// 协议的请求只认 https.proxy 配置项。GitHub 默认用 HTTPS，不设 https.proxy 就等于没配代理。
-
git config --global http.proxy socks5://127.0.0.1:1080只影响http://地址（极少用） -
git config --global https.proxy socks5://127.0.0.1:1080才真正加速https://github.com/xxx - HTTP 代理同理：两个都要写，
http://127.0.0.1:7890和https://127.0.0.1:7890不可互换 - 如果代理只监听 HTTP 协议（比如 Clash 的 HTTP 端口），就别给
https.proxy填https://—— 那是无效 URL，应填http://
SOCKS5 代理必须用 socks5://，不是 socks:// 或 http://
常见错误是把 socks5:// 写成 socks://（缺 5）或误用 http:// 前缀。Git 会静默忽略错误协议，导致请求直连失败，报错像 Failed to connect to github.com port 443: Connection refused，但你根本看不出是代理配错了。
- 正确写法：
socks5://127.0.0.1:1080、socks5://localhost:7891 - 错误写法：
socks://127.0.0.1:1080（Git 不识别）、http://127.0.0.1:1080（协议不匹配） - 带认证的 SOCKS5（如
user:pass@127.0.0.1:1080）Git 原生不支持，得换工具或走 SSH
全局代理和局部代理别混用，优先用 --local
全局代理（--global）写进 ~/.gitconfig，所有仓库都走代理；但你可能只想让 GitHub 仓库走，公司内网 GitLab 却要直连——这时全局配置反而坏事。
- 进到目标仓库目录后，用
git config --local http.proxy ...，只改当前.git/config - 检查是否生效：
git config --get http.proxy和git config --get https.proxy，分别看值 - 如果
--local和--global同时存在，local 优先级更高 - 删配置也得对应：想清局部就用
--unset http.proxy加--local，否则删的是 global
验证代理是否真起作用，别只看 git clone 是否成功
clone 成功不代表代理在跑——有可能是缓存、DNS 预解析或偶然直连成功。真实验证得看流量路径。
- 运行
git ls-remote -h https://github.com/torvalds/linux.git，观察响应时间是否明显缩短（毫秒级变秒级基本没走代理） - 开代理客户端的流量日志（如 Clash Dashboard、Surge 的实时连接列表），执行上述命令，确认出现
github.com:443出站记录 - 临时关掉代理服务，再跑一次
git ls-remote，应该立刻报Connection timed out或Failed to connect - 注意：某些代理工具（如 Windows 上的某些 GUI 客户端）默认不监听
127.0.0.1，而只监听localhost或具体网卡 IP，此时用127.0.0.1可能连不上
最容易被忽略的是代理端口实际是否在监听，以及 Git 是否真的用了你设的那个配置项——它不会报错，只会安静地直连。每次配完，务必用 git config --get-all https.proxy 看输出，再用网络工具抓一眼真实连接去向。
