在 Ubuntu 上配置代理最容易遇到的不是“完全不能用”而是这种很别扭的状态浏览器访问正常。curl能通。git clone还是很慢。apt update仍然超时。Docker 拉镜像还是失败。这时候很多人会怀疑是不是代理软件坏了是不是 Ubuntu 网络坏了大多数情况下不是。更准确的说法是你配置了代理但没有配置到正在发起请求的那一层。Ubuntu 并没有一个真正统一的“全局代理开关”。桌面应用、终端命令、Git、APT、Docker 都可能读不同的配置。理解这一点排查就会清楚很多。先记住一个判断原则代理不生效时不要先到处改配置。先问两个问题现在是谁在发请求它读取哪一种代理配置比如浏览器访问网页通常读浏览器自身或桌面环境配置。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_proxyhttp://127.0.0.1:7890export https_proxyhttp://127.0.0.1:7890export HTTP_PROXYhttp://127.0.0.1:7890export HTTPS_PROXYhttp://127.0.0.1:7890为什么大小写都写因为不同工具读取习惯不完全一样。实际工作里为了少踩坑大小写都配更省心。配置后先验证echo $http_proxyecho $https_proxycurl -I https://www.google.comcurl -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:7890git config --global https.proxy http://127.0.0.1:7890查看当前配置git config --global --get http.proxygit config --global --get https.proxygit config --list --show-origin | grep -i proxy验证方式可以直接拉一个小仓库或者用GIT_CURL_VERBOSE1 git ls-remote https://github.com/git/git.git HEAD如果命令输出里能看到连接代理地址说明 Git 这一层已经开始走代理。取消 Git 代理git config --global --unset http.proxygit config --global --unset https.proxy一个常见坑是你在终端里配了http_proxy但 Git 全局配置里残留了旧代理地址。这个时候 Git 可能优先使用自己的旧配置导致你怎么看都觉得“终端代理是对的但 git 还是不对”。所以 Git 出问题时一定要检查git config --list --show-origin | grep -i proxyAPT 代理不要只依赖环境变量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::httptrue 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.confsudo apt updateDocker 代理配置的是 daemon不是当前终端Docker 是最容易让人误判的一层。你在终端里执行了export https_proxyhttp://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]EnvironmentHTTP_PROXYhttp://127.0.0.1:7890EnvironmentHTTPS_PROXYhttp://127.0.0.1:7890EnvironmentNO_PROXYlocalhost,127.0.0.1重新加载并重启 Dockersudo systemctl daemon-reloadsudo systemctl restart docker验证 Docker daemon 是否读到了代理systemctl show --propertyEnvironment 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 proxycat /etc/apt/apt.conf.d/proxy.conf第五步确认 Docker daemon 是否读到了代理systemctl show --propertyEnvironment 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 代理有没有配好”而要问“当前这个程序到底读哪份代理配置”。这句话想清楚大部分代理问题就能定位到具体层级了。