为什么git、curl之类的工具不能使用系统网络代理?

为什么git、curl之类的工具不能使用系统网络代理?

我的操作系统:MacOSX

git、curl 可以使用http_proxyhttps_proxy环境变量。这样他们就可以在运行时使用它们并通过我的代理服务器访问目标服务器。

为什么git、curl等工具无法使用系统WIFI网络代理设置?

他们最后不是都通过我的 wifi 网络发送请求吗?

调试详情:

WIFI HTTP代理设置:

在此输入图像描述

⚡  curl google.com    
curl: (7) Failed to connect to google.com port 80: Operation timed out

清除 WIFI HTTP 代理设置:

在此输入图像描述

设置http_proxy, https_proxy,all_proxy环境变量。

⚡  export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890
⚡  echo $http_proxyhttp://127.0.0.1:7890
http://127.0.0.1:7890
⚡  curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

卷曲可以访问该google.com网站。

答案1

对于诸如等的命令行工具curl,“系统代理设置”正是您在第二个示例中设置的内容 - 即变量$http_proxy等。您用于设置“系统代理设置”的 GUI 工具是否为终端会话设置这些变量?如果没有,那么您就知道为什么不使用这些设置了。只是您的 GUI 代理设置应用程序与命令行工具不兼容。

$http_proxy等等环境变量是*nix命令行标准。无论谁编写 GUI 应用程序来设置代理并希望该设置适用于命令行工具,都需要遵守该标准。反之亦然,因为图形 DE 存储代理信息的方式有无数种,而命令行工具无法知道所有这些方式(这也没有意义,因为根据定义,命令行工具可以运行 - 并且通常是运行 - 没有任何图形 DE 运行)。假设您有相同的curl代码在 GNOME、KDE、XFCE、众多其他 Linux DE、Windows 本机 DE、MacOS 本机 DE 下运行,或者在没有任何 DE 的简单文本模式 ssh 会话中运行...

任何 GUI 工具中的代理设置应该导致$http_proxy终端会话等变量的后续设置。如果没有,那么 GUI 工具就很糟糕。

答案2

您此处使用的环境变量是标准 Unix 方式,用于在普通 Unix 工具(包括命令行工具)中表达代理设置。这种设计有几个好处:

  • 它允许您自定义每个程序要使用的代理或是否使用代理。
  • 它允许代理设置具有很大的特异性,包括通过协议。
  • 它以可移植的方式在所有 Unix 系统上工作。从 macOS 读取设置可能需要可移植程序链接特定于 macOS 的其他代码,可能是用 Objective C 编写的代码。

人们常常会想,“为什么供应商不能提供一个可移植的库来访问代理设置?”但不幸的是没有人这样做过,而且不同的环境(GNOME、KDE、MATE、macOS)做事完全不同。 Apple 还经常避免做与其他 Unix 系统类似的事情(例如,用 Metal 代替 OpenGL 和 Vulkan;Mach-O 代替 ELF),因此即使其他 Unix 系统提出标准工具,Apple 也不太可能发布这样的库原生地。

相关内容