似乎很多程序都被设计为读取这些环境变量，以决定通过哪个代理来连接到互联网上的资源。这些程序可能也有自己的单独代理设置，但如果没有设置，它们会很乐意使用这些环境变量...
- HTTP_代理
- HTTPS_代理
- 无代理
我只是想知道：
- 这些环境变量是标准的吗？
- 是否有书面规范（可能是由操作系统制造商制定的？）建议使用这些环境变量？
答案1
我同意 BillThor 的说法这更像是一种惯例，而不是标准。
我不知道这些变量的来源，但在 *nix 上的 HTTP 中，许多约定似乎源自库HTTP 库和 curl 命令行程序。
在https://curl.haxx.se/docs/manual.html这里有一些与使用 HTTP 代理相关的环境变量的描述，libcurl/curl 可以理解：
环境变量
Curl 读取并理解以下环境变量：
http_proxy, HTTPS_PROXY, FTP_PROXY它们应该针对特定协议的代理进行设置。一般代理应该设置为
ALL_PROXY设置不应通过任何代理的主机名的逗号分隔列表（仅星号，“*”匹配所有主机）
NO_PROXY如果主机名与其中一个字符串匹配，或者主机位于其中一个字符串的域内，则不会代理与该节点的交易。
请注意，http_proxy这些变量中只有 是小写的。有些库/程序会查找这些变量的小写名称，而其他库/程序则会查找大写名称。安全的应该定义每个变量的小写和大写版本。
另一个问题是，关于主机名如何匹配的描述NO_PROXY并不准确，并且没有回答以下问题：
- 价值观是否应该完全限定域名 (FQDN)因此以点结尾，喜欢
foo.example.com.还是不喜欢？ - 应该
foo.example.com只匹配这一个域还是也应该匹配任何子域，例如bar.foo.example.com？如果是后者，那么它是否还应该匹配任何子域中的任何子域，例如bar.baz.foo.example.com？ - 是否
.foo.example.com允许（以点开头）？如果允许，那么它应该匹配什么？ - 星号 (
*) 是否允许作为值的一部分 (*.example.com,*example.com)，如果可以，那么如何处理？
缺乏正式规范会导致混乱和错误。这里必须提一下库代理库旨在为代理配置提供正确且一致的支持。来自项目主页页：
libproxy 的存在是为了回答这个问题：给定一个网络资源，我如何访问它？它处理所有细节，使您能够重新进行编程。
进一步阅读：
- 我对 curl 提出的问题 –请记录 NO_PROXY 环境变量的语法和语义。
- Python 的问题 –urllib：以点开头的 no_proxy 变量值未得到正确处理以及相关的问题 –Python 2.7.13 不遵守 NO_PROXY，导致 urllib2.urlopen() 出现错误“隧道连接失败：403 禁止”
答案2
没有真正的标准。
不同的工具对这些变量的解释类似，但又略有不同。例如案件已识别的环境变量和案例优先在不同工具curl和wgetRuby、Python、Go 等语言之间有所差异：（此表取自优秀文章我们需要讨论：我们可以标准化 NO_PROXY 吗？）
curl |
wget |
红宝石 | Python | 去 | |
|---|---|---|---|---|---|
http_proxy（小写） |
是的 | 是的 | 是的 | 是的 | 是的 |
HTTP_PROXY（大写） |
不 | 不 | 是（警告） | 是（如果 REQUEST_METHOD 不在环境中） | 是的 |
https_proxy（小写） |
是的 | 是的 | 是的 | 是的 | 是的 |
HTTPS_PROXY（大写） |
是的 | 不 | 是的 | 是的 | 是的 |
no_proxy （小写） |
是的 | 是的 | 是的 | 是的 | 是的 |
NO_PROXY （大写） |
是的 | 不 | 是的 | 是的 | 是的 |
| 案例优先 | 小写 | 仅限小写 | 小写 | 小写 | 大写 |
有关更多详细信息（特别是有关 NO_PROXY 变量）和一些历史记录，请参阅上述完整文章。
答案3
这更像是一种惯例，而不是标准。它可能得到一个或多个实际建立连接的协议处理程序库的支持。Java 在其协议库中使用了类似的属性。
理解和使用通用约定可使开发变得简单得多。它还有助于实现最小意外原则，并使程序更有可能just work。