Linux 上的移动代理配置

环境变量及其作用范围

Linux 没有其他操作系统所指的那种系统级代理设置。取而代之的是一种约定：大多数软件会读取 http_proxy 和 https_proxy 环境变量，并尊重 no_proxy 设置，以绕过对这些主机的代理。 这一惯例覆盖了相当广泛的范围——包括 curl、wget、git、pip、npm 以及大多数编程语言的运行时环境——但这终究只是一种惯例而非硬性规则，而本指南真正要探讨的正是那些例外情况。

export http_proxy="http://user123:[email protected]:8000"
export https_proxy="$http_proxy"
export no_proxy="localhost,127.0.0.1,::1,.internal.example.com,10.0.0.0/8"

# Some tools read only the upper-case names
export HTTP_PROXY="$http_proxy"
export NO_PROXY="$no_proxy"

请务必将 no_proxy 设置为特定值，切勿留空。 如果不设置该参数，发往 localhost 和内部主机名的请求会被发送到代理服务器，而代理服务器无法访问这些地址——因此，五分钟前还能正常运行的数据库连接或健康检查，此刻却会因看似与代理无关的原因开始超时。参数以逗号分隔、不包含空格，且开头带点可匹配子域名。

请注意，https_proxy 接受 http:// 这种方案。该方案指定了如何连接到代理，而非目标服务器使用的协议；客户端会建立一条隧道，而 TLS 协议则在隧道内端到端运行。 对于 SOCKS5，建议使用 socks5h 格式，其末尾的 h 表示 DNS 解析也将通过代理进行——如果没有这个 h，您的机器会本地解析每个主机名，并将您访问的全部域名列表泄露到您所在的网络中。

桌面代理设置及其涵盖的内容

GNOME、KDE 及其他桌面环境都提供了网络代理设置，这看起来像是 Linux 原本所缺乏的全局控制功能。但事实并非如此。该设置只是写入了一个桌面配置键，只有刻意读取该键的应用程序才会受到影响——实际上，只有 GNOME Web 以及少数几个 GNOME 应用程序会受到影响。

你的终端无法读取它，从终端启动的任何程序也无法读取。设置桌面代理后却疑惑为什么 curl 会返回你的真实地址，这大概是 Linux 代理设置中最常见的错误，而犯下这个错误也是完全可以理解的：界面中没有任何提示说明其作用范围如此狭窄。

apt、sudo 以及需要单独配置文件的工具

有两件事肯定会导致原本正常运行的 Linux 代理配置失效，这两者都与环境无法跨越边界有关。

首先是 sudo。出于安全考虑，sudo 在运行命令前会清除大多数环境变量，因此您精心导出的代理设置便不复存在了。 临时解决方法是要求 sudo 保留环境变量；要永久解决，则需将代理变量添加到 sudoers 文件中的 env_keep 列表中，该文件应使用 visudo 进行编辑，而非直接编辑。

第二种方法很合适，它设计上就忽略了环境变量，而是希望使用自己的配置。虽然每次通过 sudo 传递变量也能行得通，但配置文件更可靠，因为无论谁以何种方式运行该命令，它都会生效。

# apt -- write /etc/apt/apt.conf.d/95proxies
Acquire::http::Proxy "http://user123:[email protected]:8000";
Acquire::https::Proxy "http://user123:[email protected]:8000";

# sudo -- preserve the environment for one command
sudo -E some-command

# sudo -- permanently, via `sudo visudo`
Defaults env_keep += "http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY"

# git, which keeps its own config
git config --global http.proxy "http://user123:[email protected]:8000"

Docker 值得单独提一下，因为它存在两个名称相同的独立问题。 守护进程需要一个代理来拉取镜像，该配置通过 systemd 即插即用文件进行设置；而容器则需要通过构建参数或环境变量传递代理。对其中一方的配置对另一方毫无作用，这便导致了大家熟悉的情况：镜像可以正常拉取，但其中的应用程序却无法访问任何资源。

对于完全不支持代理的软件——例如某些较旧的网络实用程序和少数闭源工具——proxychains 是标准解决方案。 它会预加载一个库，该库会拦截程序的网络调用，并将其通过其配置文件中定义的代理进行路由，同时支持 SOCKS5 和 HTTP 协议。但对于静态链接的二进制文件，它无法提供帮助，因为此时没有任何内容可被拦截。

查明某个命令实际使用的代理服务器

由于每个工具都是独立配置的，因此真正有意义的问题从来不是“代理是否正常工作”，而是“该命令正在读取哪套配置”。应直接询问该命令本身，而非检查设置。

env | grep -i proxy
curl -v https://api.ipify.org 2>&1 | head -20

curl https://api.ipify.org ; echo               # through whatever env says
curl --noproxy '*' https://api.ipify.org ; echo # deliberately direct
sudo -E env | grep -i proxy                     # does sudo keep them?

如果你想确认的是端点本身，而不是你的配置，那么 免费的 PXM2 代理检测工具 通过浏览器进行测试，并报告检测到的代理类型和出口国家。

为 Linux 获取移动代理

PXM2 实时节点位置——选择您需要出口 IP 的国家/地区，并按照本页的步骤进行配置：

常见问题解答

相关移动代理指南

如果您的 Linux 机器是服务器而非桌面电脑，IP 白名单通常是更好的身份验证选择——设置概述中介绍了何时应优先采用该方法。

设置指南

核心移动代理指南