企业官网建设流程全解析

你是不是也遇到过这种情况：明明在终端里export了HTTP_PROXY，git clone却还是几十 KB/s，甚至直接卡住；换一台机器什么都没配，克隆速度快得飞起。更迷惑的是，有人信誓旦旦说 Git 根本不走代理，也有人坚持说 Git 支持代理配置。其实两边都没说全。Git 的 HTTP 传输基于 libcurl，所以它确实会读代理环境变量，但读哪几个、怎么读、什么时候读，规则比你想的细很多。

这篇文章就围绕“HTTP_PROXY 影响 Git 吗”这个灵魂拷问，把http_proxy、https_proxy、all_proxy、no_proxy这几个变量的分工、Git 配置优先级、常见无效原因和排查手段一次性讲清楚。适合刚开始配代理的前后端同学，也适合被公司内网 Git 服务折腾过的运维和 SRE。后面所有配置都以常见的http://127.0.0.1:8080为例，换成你自己的代理地址即可。

1. 先说结论：Git 到底读不读 HTTP_PROXY

1.1 结论：读，但不是你想的那种读法

直接回答标题的问题：Git 会读取 HTTP_PROXY 环境变量，但有很大前提限制。

Git 做 HTTP/HTTPS 协议传输时，底层用的是 libcurl 这个网络库，而 libcurl 本身支持通过环境变量配置代理。所以严格来说，不是“Git 认识 HTTP_PROXY”，而是“Git 借用的 libcurl 认识 HTTP_PROXY”。这也解释了为什么很多和 curl 相关的代理经验，可以直接套到 Git 身上。

但你要记住这句话：HTTP_PROXY只对http://开头的 URL 生效。如果你执行的是git clone https://...，哪怕你设置了HTTP_PROXY，Git 也大概率不用它。真正起作用的是HTTPS_PROXY或小写的https_proxy。很多“配置了代理但没用”的案例，根源就是这一条。

1.2 Git 对代理变量的大小写敏感吗

这里有个容易踩坑的细节。在大多数 Linux shell 环境里，环境变量本身区分大小写，libcurl 在处理代理变量时也有自己的规则。为了保险，我习惯在配置时把大小写都写一遍：

export http_proxy=http://127.0.0.1:8080 export HTTP_PROXY=http://127.0.0.1:8080 export https_proxy=http://127.0.0.1:8080 export HTTPS_PROXY=http://127.0.0.1:8080

为什么这么啰嗦？因为某些 CGI 环境下，libcurl 出于安全考虑会忽略大写的HTTP_PROXY，防止代理头注入类问题；但在普通终端里，大写的又可能被其他工具识别。与其赌每个环境的具体行为，不如都写上。在 Windows 上环境变量不区分大小写，但在 Git Bash 和 WSL 里，依然建议沿用 Linux 那套双写习惯。

1.3 变量优先级：git config 比环境变量更“强势”

如果你同时配置了环境变量和 Git 自带的http.proxy配置项，Git 会优先使用git config里的值。

这既是好事也是坑。好的一面是，团队里可以通过配置文件统一代理；坑的一面是，如果你全局配置里写了一个已经失效的http.proxy，环境变量设得再对也没用，Git 还是连那个失效地址。排查无效问题时，第一件事就是看：

git config --global --get-regexp 'http.*'

如果这里出现了代理地址，不管环境变量长什么样，都以这里的值为准。

2. 几个代理环境变量的分工，别搞混

2.1 http_proxy 和 https_proxy 是两套东西

很多人以为设了HTTP_PROXY就万事大吉，其实http://和https://在现代 Git 操作里完全是两个世界。现在新建的仓库，remote 地址大多是https://开头，所以真正需要关心的往往是HTTPS_PROXY。

从协议层面看，HTTP 请求走普通代理比较直接，代理能看到你请求的具体 URL 和内容；而 HTTPS 请求走的是 HTTP CONNECT 隧道，代理只负责建立一条透明转发通道，TLS 加密内容代理是看不到的。所以从性能和安全角度，为 HTTPS 单独设置代理是完全合理的。Git 的 libcurl 层面也是分开处理，别把HTTP_PROXY当万能钥匙。

2.2 all_proxy 是兜底方案，但管不到 Git 的所有协议

all_proxy的字面意思是“所有协议都走这个代理”，在 curl 语境里，确实可以作为http_proxy、https_proxy都没设置时的兜底。但 Git 场景下要清醒一点：all_proxy只对 libcurl 负责的那些协议有效，也就是http://和https://这类 URL 请求。

如果你用git://协议，或者通过ssh://克隆，all_proxy起不了任何作用。因为git://走的是 Git 自己的 daemon 协议，ssh://走的是 SSH 通道，这两个都不经过 libcurl。我之前见过一个同事，把ALL_PROXY配得很完整，结果git clone git://...还是失败，他以为是代理问题，其实是 Git 协议根本不读这个变量。

2.3 no_proxy 才是最容易让你怀疑人生的那个

no_proxy是用来声明“哪些地址不走代理”的。常见配置是：

export no_proxy=localhost,127.0.0.1,::1,.internal.example.com

注意匹配规则在不同工具、不同版本里并不完全一致。有的实现里写.example.com才会匹配sub.example.com，写example.com则只匹配精确域名；也有反过来的情况。所以你在生产环境里做配置时，别依赖模糊的“想当然”，要么查清楚当前环境里 curl 版本的 no_proxy 语义，要么干脆把主域名和带点后缀都写上。

no_proxy还有一个非常隐蔽的坑：如果值里出现通配符*，那相当于所有请求都不走代理。有些开发者在本地调环境变量时为了省事写了个*，之后忘了删，导致 Git 始终直连，速度自然感人。

2.4 系统代理不等于 Git 代理

Windows 用户在“设置”里开的系统代理，或者 macOS 上网络设置里的全局代理，Git 是不会自动认的。Git 本身不读 WinINET 这类系统代理配置，它只认环境变量或git config。所以你在 Windows 图形界面里开了代理，打开 Git Bash 执行 clone 却发现没加速，一点都不奇怪。

3. 让 Git 走代理的几种正规姿势

3.1 临时环境变量：适合单次操作

最轻量的方式，是只对当前这一条命令生效。注意，export会把变量写进当前 shell，如果你不想污染后续命令，可以这样写：

https_proxy=http://127.0.0.1:8080 git clone https://example.com/repo.git

这种VAR=value command的写法，变量只在这条命令的子进程里存在，跑完就消失，非常适合临时验证“是不是代理问题”。如果你已经export了，也可以直接在当前 shell 里 clone 完再unset https_proxy。

3.2 用 git config 做持久化配置

我更推荐用 Git 自己的配置，而不是堆一大堆环境变量。原因很简单：环境变量会影响 curl、wget 以及其他所有读代理变量的工具，但git config只影响 Git，影响面可控得多。

全局配置写入：

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

查看配置：

git config --global --get-regexp 'http.*'

取消配置：

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

这套配置会写进你的~/.gitconfig，以后所有 Git 操作都自动生效。

3.3 只对特定域名生效：URL 级配置

很多时候我不想让所有 Git 请求都走代理，尤其是访问公司内网 Git 服务时，走代理反而连不上。Git 支持按 URL 前缀配置代理，这个功能非常实用。

比如只想让 GitHub 相关请求走代理：

git config --global http.https://github.com/.proxy http://127.0.0.1:8080

这条命令的效果是：所有以https://github.com/开头的 Git 请求都使用该代理，其他地址不受影响。如果你想对 GitHub 的 SSH 地址也单独处理，那是另一个维度，需要改 SSH 配置，后面会讲。

3.4 代理需要认证时怎么办

如果代理服务器要求用户名密码，可以在 URL 里带认证信息：

git config --global http.proxy http://user:pass@127.0.0.1:8080

但我必须提醒一句：这样密码会明文存在 .gitconfig 文件里。如果机器上还有别人，或者配置被同步到某个托管平台，密码就等于泄露了。更稳妥的做法是用代理程序提供的认证机制，或者配置http.proxyAuthMethod指定认证方式，再配合凭据管理，尽量不要把密码塞进 URL。

3.5 SSH 协议下的代理：HTTP_PROXY 管不着

如果你用 SSH 方式连接 Git 服务器，前面所有 HTTP 代理变量全部失效。SSH 自带通道不需要 libcurl，需要在~/.ssh/config里单独配置ProxyCommand：

Host example.com ProxyCommand nc -X connect -x 127.0.0.1:8080 %h %p

nc -X connect表示用 HTTP CONNECT 方式连接代理，-x后面跟代理地址。这行配置的意思是：连example.com这个 SSH 服务器时，先经过本地 8080 代理再连目标。不同系统上nc的版本差异很大，有些不支持-X参数，那就需要装connect之类的辅助工具。这个坑不常见，但一旦遇到，很难从 Git 层面排查出来。

4. 常见场景复盘：设置后无效、变慢、失败

4.1 只设了 HTTP_PROXY，请求却是 HTTPS

这是最大冤案。Git 默认 remote 地址是 HTTPS，执行git clone https://...时，Git 在 libcurl 层只查https_proxy或HTTPS_PROXY，你辛苦设置的HTTP_PROXY它看都不看。解决方案很简单：把https_proxy和HTTPS_PROXY也设上。

很多 Shell 脚本里习惯只写一条export http_proxy=...，导致从 HTTP 代理模式切到 HTTPS 仓库时莫名其妙变慢。我建议写配置的时候，HTTP/HTTPS 两条都写，避免漏网之鱼。

4.2 NO_PROXY 误伤内网域名

某次排查，代码里明明设置了代理，但内网 Git 服务就是连不上。最后发现是no_proxy里的内网域名拼写和实际域名不一致，比如写成了internal，实际域名是git.internal.example.com，匹配规则又只支持精确段匹配，就绕过了代理保护直接走直连，结果被公司防火墙拦了。

反过来也有问题：no_proxy该写的没写，内网域名也被丢进代理，代理服务器访问不到内网地址，同样失败。处理内网 Git 服务时，第一反应应该是检查no_proxy是否包含这个内网域名。

4.3 localhost 也被代理的尴尬

git clone http://127.0.0.1:3000/project.git这种本地调试场景，如果配置了全局代理却没设no_proxy，Git 会把127.0.0.1也丢给代理。代理再尝试连回你的本地端口，要么超时，要么无限循环。所以本地开发环境，no_proxy至少要包含：

export no_proxy=127.0.0.1,localhost,::1

4.4 环境变量被 sudo 或脚本吃掉了

执行sudo git clone时，当前终端里export的环境变量默认不会被 sudo 继承，这是 Linux 的安全策略。你明明看到echo $https_proxy有值，但 Git 进程里根本没有这个变量。

解决办法是sudo -E git clone ...表示保留环境变量，或者在/etc/sudoers里通过Defaults env_keep设置保留项。但更推荐的做法是：不要在sudo场景里依赖环境变量，而是用git config --global http.proxy写在 Git 配置层面，这样 sudo 用户也能读到配置。

4.5 代理地址写错，报错信息也没提示

如果代理服务器端口写错，比如写成8081，Git 通常会报Failed to connect to proxy或Could not resolve proxy。但有些代理程序本身没开，Git 会表现为长时间卡住后才报超时，容易被误判成网络问题。

排查时可以开 Git 的 curl 调试输出：

GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ls-remote https://example.com/repo.git

输出里会明确显示Connected to proxy或者HTTP proxy相关信息。这一步是定位代理问题的黄金命令，建议条件反射般用起来。

5. 不同系统的配置建议速查

5.1 Linux / macOS：环境变量写进 Shell 配置

如果希望每次打开终端都生效，可以把环境变量写进~/.bashrc或~/.zshrc：

export http_proxy=http://127.0.0.1:8080 export https_proxy=http://127.0.0.1:8080 export no_proxy=localhost,127.0.0.1,::1

但这类全局环境变量会影响所有命令行工具，包括 curl、wget、yarn、npm 等。如果你只需要 Git 走代理，建议优先用git config --global http.proxy而不是 Shell 环境变量。

macOS 上还多一个细节：如果你在“系统偏好设置”里开代理，终端里的命令行工具默认是不认的，必须在终端里额外设置环境变量。这和前面说的 Windows 情况一样，都属于系统代理和 Git 代理的脱节。

5.2 Windows：Git Bash、PowerShell、CMD 各写各的

Windows 下配置 Git 代理，要先看你用哪个终端。

Git Bash 里沿用 Linux 语法：

export https_proxy=http://127.0.0.1:8080

PowerShell 里要用：

$env:https_proxy="http://127.0.0.1:8080"

CMD 里要用：

set HTTPS_PROXY=http://127.0.0.1:8080

三个终端语法完全不同，很容易搞混。而且 Windows 上如果你只是打开了图形界面的“代理设置”，Git 依然不会读取。最省心的方式还是git config --global http.proxy，跟终端类型无关。

5.3 团队开发环境推荐配置

如果是团队协作，我建议在.gitconfig里做 URL 级配置，不要全员统一全局代理。一个比较稳的组合是：

# 外部仓库走代理 git config --global http.https://github.com/.proxy http://127.0.0.1:8080 # 内网仓库直连 git config --global http.https://git.internal.example.com/.proxy ""

注意第二条把代理设成空字符串，会让匹配该前缀的请求直连，这比在no_proxy里凑域名更明确。这种配置方式的好处是，不需要每个人都理解no_proxy的匹配规则，只需要维护几条 URL 规则就行。

6. 典型故障速查表

我个人踩过最多次的坑，是把代理变量写进 Shell 配置文件之后，忘了自己在容器里跑 Git。容器里的 Git 不会读宿主机上的环境变量，很多 CI 构建问题就是这么来的。现在我的习惯是：任何代理相关改动，先跑一条GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ls-remote验证，确认确实走了代理，再继续查别的问题。希望这份解析能帮你少走弯路——至少下次看到HTTP_PROXY和 Git 这两个词一起出现的时候，你知道先去看HTTPS_PROXY和NO_PROXY。