浏览器能访问，curl 和 Git 为什么仍然连接失败

浏览器能访问而 curl、Git 仍失败，应先核对命令行实际采用的连接设置。使用本地代理时，重点看代理类型、端口、变量和排除项；使用整机 VPN 时，也要检查是否残留失效的应用代理。浏览器成功只能作为对照，不能证明两个工具走了同一路径。

目标网址协议与代理协议分开看

curl 的变量说明介绍，http_proxy 与 https_proxy 按目标网址的协议选择代理。因此，变量名包含 HTTPS，不等于它的值必须以 https:// 开头。

curl 手册说明，代理地址前缀用于指定代理类型，省略前缀默认按 HTTP 代理处理。填写时，应与客户端实际提供的 HTTP 或 SOCKS 入口对应，核对监听地址和端口；不能把两种入口当成只有端口数字不同的同一服务。

curl 文档指出，协议专用变量优先于 ALL_PROXY；NO_PROXY 列出的目标则不使用相应应用代理。若它被设为单独的星号，就会匹配全部目标。这里的“绕过代理”不等于绕过仍在工作的系统 VPN。

复制配置时，还应留意大小写。curl 手册将 http_proxy 列为小写例外，同时注明 Windows 等系统不区分环境变量名大小写。排查跨平台脚本时，以文档写法统一命名，比假设所有系统行为相同更可靠。

Git 配置文档说明，http.proxy 可覆盖通常由环境变量提供的代理，远程仓库还可以配置专用代理。远程专用值为空字符串时，会对该远程禁用相应代理。

因此，curl 正常而某个仓库失败时，应检查 Git 实际读取的设置和配置来源。还要看仓库地址是否使用 HTTP、HTTPS 或 SSH；上述 HTTP 代理设置不能直接当作 SSH 连接的通用配置。

先记录目标地址、使用的工具、代理入口及错误阶段。不要只记“超时”，应区分无法连接本地代理、无法到达目标，还是认证等后续步骤失败。

对照时尽量使用同一目标服务，并记录主机名。浏览器打开一个首页，不能替代对另一下载地址的检查；若连目标都不同，先把比较条件对齐，再判断差异是否来自代理设置。

固定网络和节点，在同一次终端会话中核对设置，再按工具文档做一次明确指定代理的对照；同时检查排除项，避免把“指定了代理”误认为必然使用。反馈时只保留必要地址与脱敏错误。

若临时设置有效，再找出原配置中的冲突，而不是一次性修改所有终端、仓库和系统设置。完成后恢复临时改动，保留真正需要的配置。