Git拉取代码超时，先不要急着执行一条全局代理命令。第一步应查看远程地址：https://...使用HTTP网络栈，git@host:...或ssh://...走SSH。两类远程的代理入口不同，配置错层级会出现“命令成功执行，但流量完全没变化”。
一、先查看远程协议
在仓库中运行git remote -v，确认fetch和push地址。HTTPS远程通常可由Git的http.proxy或相关环境变量控制；SSH远程则要查看SSH配置、ProxyCommand或跳板机。不要因为平台网页是HTTPS，就假定Git远程也是HTTPS。
二、Git代理有哪些配置层级
| 层级 | 典型用途 | 风险 |
|---|---|---|
| system | 整台机器统一策略 | 影响范围大，需管理员管理 |
| global | 当前用户的所有仓库 | 内网仓库也可能被错误代理 |
| local | 当前仓库 | 迁移目录后容易忘记 |
| 按URL配置 | 只针对特定服务 | 规则匹配需验证 |
| 环境变量 | 临时终端或CI任务 | 子进程和服务环境可能不同 |
只需为当前仓库配置时，可在仓库目录使用不带--global的git config http.proxy http://proxy.example:8080。需要用户级统一设置时再考虑--global。执行前后都应查看配置来源。
三、如何检查旧代理藏在哪里
使用能够显示配置来源的Git配置查询，分别检查系统、用户和仓库文件，再查看HTTP_PROXY、HTTPS_PROXY、ALL_PROXY与绕过变量。图形化IDE和CI Runner还可能以服务账号运行，读取另一份用户目录。
在自托管自动化环境中，可参考GitHub Actions Runner代理排查。
四、按目标URL设置有什么价值
如果公共代码托管需要代理，而公司内部Git应直连，可以使用Git支持的URL相关HTTP配置缩小作用范围。规则要与实际远程主机和协议一致，并通过一次fetch验证。不要用过宽的全局绕过或代理规则掩盖DNS与路由问题。
五、SSH远程为什么不受http.proxy控制
SSH有自己的连接过程和配置文件。需要通过SOCKS5代理或跳板机时，应使用OpenSSH支持的方式，并保留主机密钥验证。不要把未知脚本放进ProxyCommand，也不要因代理接入而关闭StrictHostKeyChecking。
SSH代理与跳板机区别见SSH通过SOCKS5连接指南。
六、代理凭据不要直接拼进命令历史
把用户名和密码写成http://user:pass@host:port可能进入Shell历史、配置文件、进程参数、截图或工单。优先使用受支持的凭据机制或秘密变量，并限制配置文件权限。若凭据含特殊字符，手工URL编码也容易产生误判。
七、证书错误应该怎样处理
HTTPS远程经代理后出现证书不受信任，要确认系统时间、Git使用的TLS后端、CA文件、企业根证书与目标域名。不要长期设置http.sslVerify false，否则会削弱服务端身份验证。证书链排查可参考TLS与SNI故障检查。
八、常见故障与定位方向
- Could not resolve host：检查DNS和远程主机拼写；
- Connection timed out：检查代理地址、路由和防火墙；
- 407：检查代理认证方式与凭据；
- 401/403：检查代码托管平台的令牌或权限；
- 证书错误：检查CA、时间、域名和TLS检查；
- 网页能开但Git失败：比较浏览器与Git的代理、账号和证书环境。
九、修改后如何验证
- 记录当前远程URL和Git版本；
- 查看代理配置值及来源；
- 使用不含敏感信息的详细日志定位连接阶段；
- 对一个授权仓库执行只读fetch；
- 确认目标域名、代理状态和证书链；
- 验证内网仓库仍按预期直连；
- 删除临时代理并再次查询配置。
十、怎样清理代理配置
排障结束后，应在设置它的同一层级执行取消操作。例如用户级配置和仓库级配置必须分别删除。仅设置一个空值，可能与真正移除配置产生不同结果。清理后重新列出配置来源，并打开新终端验证环境变量也已更新。
十一、结论
Git代理配置的核心是先识别HTTPS还是SSH，再选择合适的作用范围。能用单仓库或按URL配置解决的问题，不必扩大到全局；无论哪种方式，都要保护凭据、保留证书验证，并在完成后检查是否遗留旧代理。
