requests代理设置的外层协议http/https和底层协议

写法

复制代码

proxies = {
"http": "http://10.10.1.10:3128",  # 即使外层是 http，底层代理是 http
"https": "http://10.10.1.10:1080", # 即使外层是 https，底层代理是 http
}

在早期版本（如 2.2x 时代及以前）以及 2.3x 的初期，requests 允许不完整的代理 URL。

允许的写法：

复制代码

proxies = {
    "http": "10.10.1.10:3128",  # 缺失协议头
    "https": "user:pass@proxy.example.com", # 缺失协议头，仅有认证和域名
}

背后的逻辑： requests 会自动推断缺失的协议。通常它会默认你缺失的部分与 Key（字典的键）一致。如果 Key 是 http，它就假设 Proxy 也是 http://。

2.32.0版本开始必须完整声明协议，即使它看起来有些重复：

复制代码

proxies = {
    "http": "http://10.10.1.10:3128",
    "https": "http://10.10.1.10:1080", # 即使外层是 https，底层代理也可能是 http
}

不再猜测（No Guesses）： 如果你只写 10.10.1.10:3128，新版本可能会抛出 MissingSchema 异常，或者在某些边缘情况下因无法识别协议而导致代理失效。

简单来说，这描述的是一种**"两层封装"**的关系：

外层协议 (Key: "https") ：指的是你的最终目的地 。当你访问 https://google.com 时，数据在离开你的电脑前就已经被加密了。
底层协议 (Value: http://...) ：指的是你连接代理服务器的方式。

当你通过一个 HTTP 代理访问 HTTPS 网站时，会发生以下过程：

握手：你的 requests 库先给代理服务器发一个明文请求：CONNECT google.com:443 HTTP/1.1。
建立隧道 ：HTTP 代理服务器收到后，直接去连接目标网站的 443 端口。连接成功后，它给你的电脑回一个 HTTP/1.1 200 Connection Established。
透传：此时，代理服务器变成了一个"传声筒"。你和目标网站之间的 HTTPS 加密流量（TLS 握手等）直接通过这个已经建立好的"隧道"往返。

结论：即使代理服务器本身只支持普通的 HTTP 协议，它也能帮你转发加密的 HTTPS 流量。此时，代理服务器看不了你的加密数据，它只知道你在往哪个 IP 地址传数据。

场景	最终目标 (Key)	代理类型 (Value)	安全性说明
普通 HTTP 代理	`http`	`http://...`	全程明文，代理服务器能看到你访问的内容。
HTTPS Over HTTP	`https`	`http://...`	最常见。只有第一步 `CONNECT` 是明文，后续内容对代理服务器加密。
HTTPS Over HTTPS	`https`	`https://...`	双重加密。你到代理服务器之间也是加密的（防止局域网监听）。
SOCKS 代理	`http`/`https`	`socks5://...`	极高兼容性。代理服务器完全不解析 HTTP 内容，只做字节转发。