git配置代理怎么设置？git代理配置方法

git 配置代理的本质是区分 HTTP(S) 协议与 SSH 协议的流量转发路径，只要在 git 全局配置中正确写入代理地址，或为 SSH 单独指定 ProxyCommand 通道，即可彻底解决克隆缓慢、连接超时与推送失败三大核心痛点，配置完成后无需重启任何服务，立即生效。

为什么你的 git 总是卡住或失败

git 连接远程仓库时，默认走系统直连路由，当网络环境存在防火墙限制或跨运营商访问时，TCP 握手阶段就会超时。很多开发者误以为加大 git 的 timeout 参数就能解决，实际上握手失败根本无法触发超时重试机制,必须从网络出口层面解决。

另一个高频误区是只配置了 http.proxy 而忽略 SSH 协议流量，git 使用 SSH 协议连接 GitHub 或自建 GitLab 时，走的是 22 端口，与 HTTPS 的 443 端口完全独立。只配 HTTP 代理不配 SSH 代理，等于只修好了一条路，另一条路依然是断头路。

HTTP/HTTPS 协议下的代理配置方案

全局代理配置（推荐）

执行以下命令，将代理服务器地址写入 git 全局配置文件 ~/.gitconfig：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

关键点在于代理地址的写法，如果本地代理软件同时支持 SOCKS5 协议，更推荐使用 SOCKS5 方式，因为 SOCKS5 在传输层转发，对 git 的智能 HTTP 协议兼容性更好：

git config --global http.proxy socks5://127.0.0.1:7890
git config --global https.proxy socks5://127.0.0.1:7890

单仓库代理配置

如果你只需要让某个特定仓库走代理，去掉 --global 参数，在仓库目录内执行同样的命令即可。

这个方案特别适合公司内网仓库与 GitHub 仓库混用的场景,避免内网流量也绕行代理导致速度反而变慢。

环境变量方式

在 ~/.bashrc 或 ~/.zshrc 中添加：

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

此方案影响范围更大，不仅 git 生效，curl、wget 等命令行工具同样会走代理。如果你的代理服务对某些域名做了白名单分流，建议优先使用 git config 方式，控制粒度更细。

SSH 协议下的代理配置方案

SSH 协议不读取 git 的 http.proxy 配置，必须在 ~/.ssh/config 文件中单独设置。

Host github.com
    HostName github.com
    User git
    Port 22
    ProxyCommand nc -X connect -x 127.0.0.1:7890 %h %p

上面的配置使用 nc 命令（netcat）将 SSH 流量转发到本地代理端口。macOS 系统自带的是 BSD 版 nc，参数稍有差异,需要改为：

ProxyCommand nc -X 5 -x 127.0.0.1:7890 %h %p

-X 5 表示使用 SOCKS5 协议，Linux 用户如果不想依赖 nc，也可以使用 connect-proxy 工具：

ProxyCommand connect -S 127.0.0.1:7890 %h %p

配置完成后，执行 ssh -T git@github.com 测试连接，出现 Hi username! 即代表 SSH 代理配置成功。

取消代理与白名单分流

配置代理后，如果访问内网 git 仓库出现卡顿，需要按域名取消代理，git 支持 no_proxy 环境变量和 http.<url>.proxy 的 URL 匹配语法。

推荐做法是只让指定域名走代理，其他直连

，在 ~/.gitconfig 中添加：

[http "https://github.com/"]
    proxy = http://127.0.0.1:7890
[http "https://gitlab.com/"]
    proxy = http://127.0.0.1:7890

这样 git clone 公司内网地址时自动直连，访问 GitHub 时自动走代理，无需频繁切换配置,取消全部代理配置则执行：

git config --global --unset http.proxy
git config --global --unset https.proxy

经验案例：酷番云服务器上的代理部署实践

在使用酷番云云服务器搭建 CI/CD 流水线时，我们遇到一个典型场景：构建服务器需要从 GitHub 拉取依赖仓库，但服务器所在机房访问 GitHub 的 HTTPS 连接延迟高达 800ms 以上,构建超时频发。

我们的解决方案是分阶段代理，在酷番云服务器上部署轻量级代理客户端，只对 git 命令生效，不动系统全局网络配置,具体做法是：

1. 创建独立部署用户，避免代理配置污染 root 环境
2. 在该用户下执行 git config --global http.proxy http://127.0.0.1:1080
3. SSH 代理则通过 ~/.ssh/config 单独配置 ProxyCommand
4. 构建脚本中增加 git config --list | grep proxy 的日志输出，方便排查

这套方案在酷番云服务器上稳定运行数月，核心经验是：代理配置必须按用户隔离，不能直接改 /etc/profile 全局变量，否则会影响服务器上其他业务的网络请求，酷番云控制台的防火墙策略需要放行代理软件监听端口,避免外部请求被拦截。

常见问题排查与性能验证

配置完成后,用以下命令验证代理是否真正生效：

git config --get http.proxy
GIT_TRACE=1 git clone https://github.com/example/repo.git

开启 GIT_TRACE 后，输出日志中会出现 http.proxy 的相关信息，如果代理配置有误，通常会报 Failed to connect to 127.0.0.1 port 7890 错误,此时检查代理软件是否监听对应端口：

netstat -an | grep 7890

还有一个容易忽略的坑是 git 版本过旧，git 2.0 以下版本对 socks5 协议支持不完善，建议升级到 2.30 以上版本，使用 git --version 查看当前版本，如果过旧,使用包管理器更新。

相关问答

问：配置代理后 git clone 速度依然很慢，是什么原因？

答：首先确认代理软件本身的上游节点速度，可以用 curl -x http://127.0.0.1:7890 https://github.com -I 测试代理出口速度，curl 快而 git 慢，检查是否同时配置了 HTTP 和 HTTPS 代理，某些代理软件对两种协议处理机制不同，其次检查 http.postBuffer 参数，git 默认 1MB，对于大仓库可以适当调大：git config --global http.postBuffer 524288000，如果代理软件开启了规则分流，确认 GitHub 域名没有误入直连规则。

问：git 配置代理后，公司内部仓库无法克隆，如何只让 GitHub 走代理？

答：不要使用全局代理配置，改用 URL 匹配方式，在 ~/.gitconfig 中只配置 GitHub 域名的代理，其他域名保持直连，具体做法是使用 git config --global http.https://github.com/.proxy http://127.0.0.1:7890 命令，这样 git 会精确匹配 github.com 前缀的 URL 才走代理，公司内网地址不受影响，SSH 协议同理，在 ~/.ssh/config 中单独为 github.com 主机配置 ProxyCommand,其他主机不配置即可。