浏览器开代理一切正常,git clone 却一直卡在连接阶段,或者推送到一半被断开——不少人的第一反应是代理IP出口质量差,马上换出口重试。git 真的在走代理IP吗?它的配置到底写在哪?答案往往不在出口,而在三处配置里。
git 为什么常常不读系统代理
git 是命令行程序,不读图形界面的系统代理设置,它按自己的顺序找代理:仓库级配置、全局配置、系统环境变量。哪一层都没写,它就直连,表现就是”系统代理开着,git 却没走代理”。先确认这一点,排查方向才不会跑偏。
走代理的 git 有哪几种配置
三种:一是把 http.proxy 与 https.proxy 写进 git config;二是通过环境变量给命令行进程传代理;三是通过 SSH 访问仓库时,在 ssh 配置里挂代理命令。网页访问正常、git 失败,多数是这三种里有一种没配齐,或者配了却没生效。
- 先确认 git 实际走的路径:打开详细日志,核对连接目标与代理IP出口是否一致,排除”根本没走代理”的可能
- 再查配置层:逐层查看 git 的 http.proxy 与 https.proxy,没写就补上,写错地址就改正
- 接着验环境变量:确认终端里代理变量对当前会话生效,别只设在图形界面那一层
- 最后看传输方式:走 HTTPS 的查 http.proxy,走 SSH 的查 ssh 代理命令,两条路分开验证
给 git 配好代理之后,验证也有一招:打开详细日志,看连接建立到哪个环节——是解析、连接,还是数据传输阶段断开。走代理IP时,连接建立慢一点是正常的,卡在同一位置反复重试才值得深挖。
常见报错怎么分
克隆超时,多半是连接层没走通,先查代理配置是否生效;推送被拒,要分清是认证失败还是网络中断;证书报错,先看系统时间与证书链,再考虑代理IP出口的证书环节;卡在 unable to access 这类提示,基本就是代理地址或端口写错了。报错分层,排查才有方向,出口质量只是众多可能之一。
把 git 的代理配置固化进配置文件,而不是每次临时敲环境变量,换机器、重装系统之后,git 相关的代理问题能少一半。
团队多人共用一套 git 工作流时,还可以把代理配置整理成共享模板,新人加入直接应用,避免每个人各配一遍、各踩一遍坑;同时注意,git 的代理配置里不要出现明文凭据,必要时交给专门的凭据管理工具保存。
那么,git 连不上,到底是代理IP的错还是配置的错?先花两分钟把这三处配置查完——多数时候,答案都在配置里,和出口质量无关。