只为一个Git仓库使用代理

设置仓库本地HTTP代理，检查Git为远程URL选择的配置，并在不再需要时移除覆盖项。

不必因为一个项目需要不同的连接，就给Git设置全局代理。现有工作副本有自己的本地配置，可以把改动留在这个仓库中。

下面的示例使用当前的git config set/get/unset命令。项目目录、远程URL和文档示例IP都是占位值。若要在允许使用公共代理的情况下测试公共仓库，可从HTTP代理列表选择候选。

git -C project config set --local http.proxy http://203.0.113.10:8080
git -C project ls-remote origin

代理URL本身包含传输协议前缀。HTTPS远程地址也可以使用支持CONNECT的普通HTTP代理；远程地址使用HTTPS并不要求把代理URL改为HTTPS。

检查Git实际选择了什么

如果结果不符合预期，检查实际远程URL对应的配置值：

git -C project config get --show-origin \
  --url=https://example.com/team/project.git http.proxy

查询时使用真实的HTTPS远程地址。Git可能有系统、用户、仓库、命令行及URL专属设置。只看全局http.proxy值，可能漏掉更具体的规则。来源输出有助于找出决定结果的配置文件或命令行来源。

本地设置作用于这个仓库发起的HTTP访问，并非只针对某个分支。因此，仓库有多个HTTP远程地址时，可能不止最初测试的那个会使用它。需要进一步缩小匹配范围时，可以使用URL专属HTTP设置。

工作副本尚不存在时

首次克隆时，先决定覆盖项是否应持久保留；若只想限制在这一次Git调用中，使用：

git -c http.proxy=http://203.0.113.10:8080 \
  clone https://example.com/team/project.git

命令行覆盖不会自动成为新工作副本中的永久配置项。如果后续fetch也应使用这条路径，再设置本地值。

SSH远程地址是另一种情况

以git@host:或ssh://开头的远程地址使用SSH。Git的HTTP代理设置不会把它变成HTTP传输。不要仅因为SSH操作仍失败就更换一个正常的代理IP，应先检查远程地址的传输方式。

不再需要本地覆盖时，只移除这个键：

git -C project config unset --local http.proxy

移除后，其他来源中适用的配置会再次生效。这不是清空机器上所有代理设置的命令。

相关文章