最近要使用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 代理协议的。
感谢您的科普#(赞一个)