# 手动批量设置
export http_proxy= \
&& export https_proxy= \
&& export HTTP_PROXY= \
&& export HTTPS_PROXY= \
&& export no_proxy=",localhost,localaddress,,," \
&& export NO_PROXY=",localhost,localaddress,,,"

# 添加别名
echo "alias aproxy='http_proxy= https_proxy= HTTP_PROXY= HTTPS_PROXY='" >> ~/.bashrc
source ~/.bashrc

# 注意事项:
# 1. 命令前面添加 sudo 后的命令执行时的环境变量和当前用户可能不一样,建议先切到对应用户之后再执行 export 操作使环境变量生效

简要总结就是,如果大小写只能选一种,那就使用小写形式。因为 HTTP_PROXY 并不总是支持或推荐使用。还有就是客户端应如何处理这些变量还没有明确标准,也就导致各 Web 客户端支持这些变量的方式各不相同。

If you’ve used a Web proxy server before, you’re probably familiar with the environment variables http_proxy or HTTP_PROXY. You may be less familiar with no_proxy, which provides a way to exclude traffic destined to certain hosts from using the proxy. While HTTP is a well-defined standard, no standard exists for how clients should handle these variables. As a result, Web clients support these variables in subtly different ways. For one GitLab customer, these differences led to a weekend of troubleshooting that uncovered why certain services stopped communicating.
如果你以前使用过网络代理服务器,你可能对环境变量 http_proxy 或 HTTP_PROXY 比较熟悉。你可能对 no_proxy 不太熟悉,它提供了一种方法,可以让某些主机的流量不使用代理服务器。虽然 HTTP 是一个定义明确的标准,但对于客户端应如何处理这些变量却没有标准。因此,Web 客户端支持这些变量的方式各不相同。对于一位 GitLab 客户来说,这些差异导致了一个周末的故障排除,从而揭示了某些服务停止通信的原因。

It’s been over 25 years since the first Web proxy was released. While the basic mechanics of configuring a Web client via environment variables have not changed much, a number of subtleties have emerged across different implementations. We saw for one customer, erroneously defining conflicting no_proxy and NO_PROXY variables led to hours of troubleshooting due to the differences with which Ruby and Go parse these settings. We hope highlighting these differences will avoid future issues in your production stack, and we hope that Web client maintainers will standardize the behavior to avoid such issues in the first place.
自第一个网络代理发布以来,25 年过去了。虽然通过环境变量配置 Web 客户端的基本机制没有太大变化,但在不同的实现中出现了许多微妙之处。我们看到一位客户错误地定义了相互冲突的 no_proxy 和 NO_PROXY 变量,由于 Ruby 和 Go 在解析这些设置时存在差异,导致了数小时的故障排除。我们希望通过强调这些差异来避免今后在生产堆栈中出现问题,我们也希望 Web 客户端维护人员能够首先规范行为以避免此类问题。

HTTP_PROXYNoNoYes (warning)Yes (if REQUEST_METHOD not in env)Yes
Case precedencelowercaselowercase onlylowercaselowercaseUppercase

Case precedencelowercaselowercase onlylowercaselowercaseUppercase
Matches suffixes?YesYesYesYesYes
Strips leading .?YesNoYesYesNo
* matches all hosts?YesNoNoYesYes
Supports regexes?NoNoNoNoNo
Supports CIDR blocks?NoNoYesNoYes
Detects loopback IPs?NoNoNoNoYes

Today, most Web clients support connection to proxy servers via environment variables: 如今,大多数Web客户端支持通过环境变量连接到代理服务器:

  • http_proxy / HTTP_PROXY
  • https_proxy / HTTPS_PROXY
  • no_proxy / NO_PROXY

The lowest common denominator 最小公分母

I think we can all agree that one should never define inconsistent values with lowercase and uppercase proxy settings. However, if you ever have to manage a stack written in multiple languages, you might need to consider setting HTTP proxy configurations to the lowest common denominator: 我想大家都同意,绝不能用小写和大写的代理设置定义不一致的值。不过,如果您需要管理用多种语言编写的堆栈,您可能需要考虑将 HTTP 代理配置设置为最小公分母:

http_proxy 和 https_proxy

  • Use lowercase form. HTTP_PROXY is not always supported or recommended. 使用小写形式。因为 HTTP_PROXY 并不总是支持或推荐使用。
    • If you absolutely must use the uppercase form as well, be sure they share the same value. 如果您必须使用大写形式,请确保它们具有相同的值。


  1. Use lowercase form. 使用小写形式。
  2. Use comma-separated hostname:port values. 使用逗号分隔的 hostname:port 值。
  3. IP addresses are okay, but hostnames are never resolved. IP 地址没问题,但主机名却永远无法解析。
  4. Suffixes are always matched (e.g. will match 后缀总是匹配的(例如, 将匹配 )。
  5. If top-level domains need to be matched, avoid using a leading dot (.). 如果需要匹配顶级域,请避免使用前导点 (.)。
  6. Avoid using CIDR matching since only Go and Ruby support that. 避免使用 CIDR 匹配,因为只有 Go 和 Ruby 支持该功能。

How to use no_proxy on Linux machines – wildcards, leading dots

Set a network range in the no_proxy environment variable

8.1 Proxies

Chapter 23. Working with HTTP Proxies

Best way to specify domain and all sub-domains in NO_PROXY?

We need to talk: Can we standardize NO_PROXY? 我们需要谈谈:我们能将 NO_PROXY 标准化吗?





您的电子邮箱地址不会被公开。 必填项已用 * 标注