企业官网建设流程全解析

在 Ubuntu 上配置代理，最容易遇到的不是“完全不能用”，而是这种很别扭的状态：

• 浏览器访问正常。
• curl能通。
• git clone还是很慢。
• apt update仍然超时。
• Docker 拉镜像还是失败。

这时候很多人会怀疑：是不是代理软件坏了？是不是 Ubuntu 网络坏了？

大多数情况下不是。

更准确的说法是：你配置了代理，但没有配置到正在发起请求的那一层。

Ubuntu 并没有一个真正统一的“全局代理开关”。桌面应用、终端命令、Git、APT、Docker 都可能读不同的配置。理解这一点，排查就会清楚很多。

先记住一个判断原则

代理不生效时，不要先到处改配置。先问两个问题：

1. 现在是谁在发请求？
2. 它读取哪一种代理配置？

比如：

• 浏览器访问网页：通常读浏览器自身或桌面环境配置。
• curl：通常读 shell 环境变量。
• git clone：可能读 Git 自己的http.proxy配置，也可能读环境变量。
• apt update：更稳妥的是读 APT 专用配置。
• Docker 拉镜像：读 Docker daemon 的 systemd 配置，不等于当前终端环境变量。

所以“我明明设置了代理”这句话还不够，需要补一句：我设置的是哪一层的代理。

桌面代理：浏览器能用，不代表终端能用

如果你用的是 Ubuntu GNOME，可以在这里设置：

Settings -> Network -> Network Proxy

例如代理地址是：

127.0.0.1:7890

这个配置通常影响的是桌面应用，尤其是会读取系统代理设置的图形界面程序。

但它不一定影响：

• 当前终端里的命令。
• Git。
• APT。
• Docker。

所以浏览器能打开网页，只能说明“浏览器这一层可能配置好了”，不能说明命令行工具也已经走代理。

Shell 环境变量：解决 curl、wget 这类命令

终端里最常见的配置方式是环境变量：

export http_proxy=http://127.0.0.1:7890

export https_proxy=http://127.0.0.1:7890

export HTTP_PROXY=http://127.0.0.1:7890

export HTTPS_PROXY=http://127.0.0.1:7890

为什么大小写都写？

因为不同工具读取习惯不完全一样。实际工作里，为了少踩坑，大小写都配更省心。

配置后先验证：

echo $http_proxy

echo $https_proxy

curl -I https://www.google.com

curl -I https://github.com

如果只想让当前终端临时生效，直接执行上面的export就行。

如果希望每次打开终端都生效，可以写到 shell 配置文件里：

vim ~/.bashrc

写入后执行：

source ~/.bashrc

如果你用的是 zsh，则一般写到：

~/.zshrc

这里的关键点是：环境变量只对当前 shell 以及它启动的子进程生效。已经打开的另一个终端、systemd 服务、Docker daemon，不会自动继承你刚刚在这个终端里 export 的值。

Git 代理：建议单独配置

Git 可以读取环境变量，但更推荐给 Git 单独配置，尤其是在你经常访问 GitHub、Gitee 或公司 GitLab 的情况下。

配置 HTTP/HTTPS 代理：

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

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

查看当前配置：

git config --global --get http.proxy

git config --global --get https.proxy

git config --list --show-origin | grep -i proxy

验证方式可以直接拉一个小仓库，或者用：

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git.git HEAD

如果命令输出里能看到连接代理地址，说明 Git 这一层已经开始走代理。

取消 Git 代理：

git config --global --unset http.proxy

git config --global --unset https.proxy

一个常见坑是：你在终端里配了http_proxy，但 Git 全局配置里残留了旧代理地址。这个时候 Git 可能优先使用自己的旧配置，导致你怎么看都觉得“终端代理是对的，但 git 还是不对”。

所以 Git 出问题时，一定要检查：

git config --list --show-origin | grep -i proxy

APT 代理：不要只依赖环境变量

apt update、apt install这类命令，建议配置 APT 自己的代理文件。

新建或编辑：

sudo vim /etc/apt/apt.conf.d/proxy.conf

写入：

Acquire::http::Proxy "http://127.0.0.1:7890";

Acquire::https::Proxy "http://127.0.0.1:7890";

然后验证：

sudo apt update

如果想临时排查，也可以打开调试信息：

sudo apt -o Debug::Acquire::http=true update

这里有一个容易忽略的点：sudo可能不会保留你当前用户的环境变量。也就是说，你普通用户下echo $http_proxy有值，不代表sudo apt update一定能读取到。

因此 APT 长期使用代理时，写/etc/apt/apt.conf.d/proxy.conf通常更稳定。

取消 APT 代理也很简单：

sudo rm /etc/apt/apt.conf.d/proxy.conf

sudo apt update

Docker 代理：配置的是 daemon，不是当前终端

Docker 是最容易让人误判的一层。

你在终端里执行了：

export https_proxy=http://127.0.0.1:7890

这对当前 shell 有效，但 Docker 拉镜像时真正发请求的是 Docker daemon。daemon 是 systemd 管理的服务，它不一定知道你当前终端里的环境变量。

创建目录：

sudo mkdir -p /etc/systemd/system/docker.service.d

创建配置文件：

sudo vim /etc/systemd/system/docker.service.d/http-proxy.conf

写入：

[Service]

Environment="HTTP_PROXY=http://127.0.0.1:7890"

Environment="HTTPS_PROXY=http://127.0.0.1:7890"

Environment="NO_PROXY=localhost,127.0.0.1"

重新加载并重启 Docker：

sudo systemctl daemon-reload

sudo systemctl restart docker

验证 Docker daemon 是否读到了代理：

systemctl show --property=Environment docker

再测试拉镜像：

docker pull hello-world

如果是 Docker Desktop、WSL2、公司内网环境，配置方式还可能不同。但核心原则不变：谁发请求，就给谁配置代理。

一套实用排查顺序

遇到“代理不生效”时，可以按这个顺序查。

第一步，确认代理服务本身是否可用：

curl -x http://127.0.0.1:7890 -I https://github.com

如果这一步都失败，先别改 Git、APT、Docker，先检查代理软件是否启动、端口是否正确。

第二步，确认当前 shell 有没有代理变量：

env | grep -i proxy

第三步，确认 Git 有没有自己的代理配置：

git config --list --show-origin | grep -i proxy

第四步，确认 APT 是否有专用配置：

ls /etc/apt/apt.conf.d/ | grep -i proxy

cat /etc/apt/apt.conf.d/proxy.conf

第五步，确认 Docker daemon 是否读到了代理：

systemctl show --property=Environment docker

这个顺序的好处是：你不会把一个 Git 问题误判成系统代理问题，也不会把 Docker daemon 的问题误判成终端环境变量问题。

常见现象怎么判断

如果浏览器能访问，但curl不行，优先检查 shell 环境变量。

如果curl能访问，但git clone不行，优先检查 Git 自己的代理配置，以及是否残留旧代理。

如果 Git 能访问，但apt update不行，优先检查/etc/apt/apt.conf.d/proxy.conf。

如果前面都正常，但docker pull不行，优先检查 Docker daemon 的 systemd 代理配置。

如果只有sudo后不生效，要考虑环境变量没有被 sudo 继承，APT 和 Docker 尤其常见。

总结

Ubuntu 上代理“不生效”，很多时候不是代理软件坏了，而是配置没有作用到对应组件。

可以把它理解成五层：

• 桌面代理：主要影响图形界面程序。
• Shell 环境变量：主要影响curl、wget这类命令行工具。
• Git 配置：影响git clone、git fetch、git push。
• APT 配置：影响apt update、apt install。
• Docker daemon 配置：影响docker pull、容器镜像下载。

排查时不要问“Ubuntu 代理有没有配好”，而要问“当前这个程序到底读哪份代理配置”。

这句话想清楚，大部分代理问题就能定位到具体层级了。