最近要使用vcpkg,其中不少repo都是从github上拉取的,由于众所周知的原因,Github在大陆网络环境下变得越来越难以访问,包括高校系统下CN2链路也是如此。
兜兜转转找了一大圈,我自己内网使用了SOCK5的代理模式,HTTP代理只是听过,更费解的是HTTPS代理听上去完全不符合逻辑(莫名其妙的想到MITM)。
后来发现,根本不要求HTTPS_PROXY的代理一定是HTTPS的 ,也不要求HTTP_PROXY的代理一定是HTTP的。
对于CURL而言,就算你给他一个https://
开头的代理,CURL依然使用明文的方式向代理发起请求。
所以最终,不加前缀头,直接填上SOCK5的地址就完事。
2021年4月25日 更新:
有一位网友评论内容讲的比较详细,读者可以翻阅向下看一下。在此也感谢这位网友Ai Ohto
。
本文标题:HTTP_Proxy&HTTPS_Proxy的坑
本文连接:https://blog.dextercai.com/archives/107.html
除另行说明,本站文字内容采用创作共用版权 CC-BY-NC-ND 4.0 许可协议,版权归本人所有。
除另行说明,本站图片内容版权归本人所有,任何形式的使用需提前联系。
http_proxy 是 访问 http:// 使用的代理;https_proxy 是访问 https:// 使用的代理。同理 ftp_proxy 。
还有一个 all_proxy 和 no_proxy 分别表示 全部协议的代理 和 不使用代理的域名/主机 。但支持的应用不多。
有的应用会识别 HTTP_PROXY 而不是小写的环境变量,有的则反过来,有的都可以。
它的格式没有标准定义。通常是个 URL 。不同的应用程序对这个 URL 的协议有不同的支持程度。例如 curl(包含所有用 libcurl 的应用) 支持 http, https(仅限 https_proxy), socks ;golang 编译的(通过标准库通信的)程序支持 http; https; socks5 ;wget 支持 http 但不支持 socks5。
export https_proxy=http://127.0.0.1:8080 表示当访问 https:// 的地址时使用 127.0.0.1:8080 的代理,该代理使用 HTTP 协议。但全链路仍然是受 TLS 端到端保护的。抓包 你和代理之间 或 代理和服务器之间 的流量,或两者都抓,都不能获得除域名端口外你实际通信的内容。除非你的客户端和代理同时错误的实现了 HTTP 代理,在这种情况下抓你和代理之间的流量可以获得通信内容。
使用 http_proxy 和 https_proxy 并配置 http 协议的代理是目前最通用可移植的选项。
如果是某 姓 T 的前一个字母 的代理工具。它的 Windows 客户端暴露的本地代理接口是同时支持 HTTP 代理协议和 SOCKS5 代理协议的。
感谢您的科普#(赞一个)