Git 设置代理：http.proxy、作用域与取消代理

给 Git 设置代理时，如果远程仓库走 HTTP 或 HTTPS，先用只对一条命令生效的 http.proxy 试一下。写成永久配置之前，还要检查远程仓库的传输方式，以及有没有按 URL 或按 remote 配置的代理。只清掉通用设置的话，更具体的代理配置可能还在生效。

文中的地址均为示例。可下载的实验只用回环地址、虚构的凭据和一个临时仓库，全部十项检查于 2026 年 10 月 12 日在 Git 2.50.1（Apple Git-155）、Python 3.14.8 和 macOS 15.7.4 上运行。它验证的是路由和仓库内容，不评测代理服务商，也不测试 HTTPS、SSH 或 push。

确认远程仓库走 HTTP(S) 还是 SSH

在已有的仓库里，先在本地查看 remote 地址：

git remote get-url origin

https:// 或 http:// 开头的 URL 走 Git 的 HTTP 传输协议；git@github.com:OWNER/REPO.git 或 ssh://git@HOST/REPO.git 这样的 remote 走 SSH。http.proxy 对 SSH 连接不起作用，SSH 的路由请按公司或团队的说明来配置。如果是新克隆，就检查你准备克隆的那个 URL。URL 里嵌入的凭据不要出现在要分享的输出里。参见 Git 命令与 SSH 文档。

Git 设置代理：先只对一条命令生效

先在环境变量里设好 GIT_PROXY_URL 和 GIT_REPO_URL。GIT_REPO_URL 是一个你有权访问的 HTTP/HTTPS remote；GIT_PROXY_URL 填服务商文档里给出的网关地址，例如 http://proxy.example:8080：

git -c http.proxy="$GIT_PROXY_URL" \
    -c http.lowSpeedLimit=1 -c http.lowSpeedTime=20 \
    ls-remote "$GIT_REPO_URL"

这样不会在任何配置文件里留下代理设置。两个低速选项限制的是传输停滞的时间，不是整条命令的总时限。返回了 refs，说明仓库确实响应了，但单凭命令成功，并不能确定请求走的是哪条路由。要克隆的话，把 ls-remote 换成 clone，并指定一个新的目标目录。

HTTPS remote 可以走 HTTP 网关：代理 URL 的协议（scheme）描述的是到网关的那段连接。只有网关支持 TLS 时，才使用 https:// 网关。参见 Git HTTP 选项、libcurl 代理协议。

代理凭据和仓库凭据是两回事。按 Git 文档的说法，代理 URL 里只有用户名、没有密码时，Git 会通过它的凭据机制获取密码。认证方式以网关支持的为准。带真实凭据的 URL 不要写进共享的配置，诊断输出要先脱敏。参见 Git 凭据。

用 git config 保存代理：按需选最小作用域

临时检查通过后，从下面选一种配置。这些命令用的是不带凭据的示例网关：

仓库级（local）配置要求仓库已经存在；首次克隆时，可以用只对单条命令生效的设置，或者在用户级配置里按 URL 设置。URL 匹配和普通的配置优先级是分开判断的，remote 级的设置还会再覆盖一层。参见 Git 配置作用域、remote 代理选项。

路由实验测出了什么

实验脚本会创建一个裸仓库、一个 HTTP 仓库服务器和一个需要认证的转发代理。clone/fetch 成功的用例会核对 commit 是否符合预期、文件内容是否完全一致；直连用例要求代理一次请求都没收到。记录的结果保留了命令、请求、失败信息和版本。

十个用例全部符合各自的验收标准，包括故意让认证失败的那个用例。九次 clone/fetch 操作成功，并校验了仓库内容。这些观察结果适用于记录下来的这套本地 Git/libcurl 环境。

把脚本和 README 下载到一个新目录，然后运行：

python3 git_proxy_lab.py > local-results.json

实验需要支持 GIT_CONFIG_GLOBAL 的 Git（Git 2.32 引入）和带 ThreadingHTTPServer 的 Python（Python 3.7 引入），不需要安装第三方 Python 包。这两项要求出自文档；实际只在记录的 Git 2.50.1 / Python 3.14.8 环境中运行过。参见 Git 2.32 发布说明和 Python HTTP 服务器文档。实验使用 IPv4 回环地址和专用的 Git 配置文件，基线环境清除了继承的代理变量，结束后删除临时仓库。它用的是哑 HTTP 协议（dumb HTTP），不测试智能 HTTP（smart HTTP）、CONNECT、证书、SOCKS、生产环境的认证系统或 SSH。下文关于证书的建议来自文档。我们对照的是 Git 2.56.0 源码里的文档，实际运行的是 Apple Git 2.50.1。

取消 Git 代理：找到并删除生效的那一项

请在本地查看（配置值里可能含有凭据）：

git config --show-origin --show-scope --get-regexp \
  '^(http\..*proxy|remote\..*\.proxy)$'
git config --get-urlmatch http.proxy "$GIT_REPO_URL"

第一条命令会列出通用的、按 URL 的和按 remote 的代理条目。第二条报告 HTTP 的 URL 匹配结果；它不考虑 remote 级的设置，也证明不了实际走的网络路径。另外，参照代理环境变量指南，检查实际运行的进程里的代理和绕过变量。

只删除你想删的那个键，并且只在对应的作用域里删。以示例中的主机条目为例：

git config --global --unset-all 'http.https://github.com/.proxy'

示例中的 remote 条目，要在它所在的仓库里删除：

git config --local --unset-all remote.origin.proxy

用户级的通用条目，用 git config --global --unset-all http.proxy 删除。键不存在时，命令会返回非零退出码。删掉一项后，可能会露出另一项仍在生效的设置，所以要再查一遍，并重新做路由检查。上面的实验演示了这一点：只清掉 http.proxy，匹配的 URL 条目仍可能生效。

判断是哪一层出了问题

如果公司使用经批准的 TLS 拦截 CA，Git 对应的选项是 http.sslCAInfo；连接 HTTPS 代理那一段的 TLS 则用单独的 http.proxySSLCAInfo。受信任的 CA 证书向管理员索取，并保持证书校验开启。这是两条不同的连接，而这个 HTTP 实验两者都没有测试。Windows 上的 Schannel 可能使用系统的证书存储，而不是你提供的 CA 文件；请遵循该平台的相应策略。参见 Git TLS 选项。

要在 Git 之外给网关做基线测试，可以用设了时限的 curl 检查。curl 请求成功，并不能说明 Git 会选哪条路由。

遇到超时，先找出卡在哪个阶段，再考虑调大时限；参见代理超时排查。

ipvolt 销售移动代理和住宅代理，住宅代理每 GB $0.60 起：查看价格。