HTTP 与 HTTPS 代理

HTTP 代理接受浏览器或应用的 Web 请求，并代你连接目标。它可以承载普通 HTTP 流量；如果支持 CONNECT 方法，也可以承载加密的 HTTPS 流量。HTTPS 代理则为应用与代理本身之间的连接增加加密。

这是两个独立选择：应用如何连接代理，以及如何通过代理与网站通信。理解两者，有助于选择正确的连接设置。代理协议之间的整体选择，见SOCKS 与 HTTP 代理。

HTTP 代理如何处理 Web 请求

假设一个监控脚本请求 http://example.com/catalog。它不会直接连接网站，而是连接已配置的代理。使用 HTTP/1.1 时，请求中会发送完整目标 URL，让代理知道应访问哪个服务器和页面。代理向前转发请求，再把网站响应返回脚本。

在这种模式下，代理处理 HTTP 消息。它可以读取 GET 或 POST 等方法、请求地址、请求头和提交的数据。为相应用途配置的软件，可以应用访问规则、记录请求，或缓存符合条件的响应。缓存是可选功能，受响应缓存规则约束；购买 HTTP 代理访问权，并不意味着每个页面都会缓存。

网站收到的网络连接来自代理出口 IP。HTTP 这个术语并不说明 IP 来自哪里，或分配会保持多久。同一种连接协议，可以配合数据中心、ISP、住宅或移动地址，使用固定 IP 或轮换 IP 池。

HTTP 代理如何打开 HTTPS 网站

HTTPS 网站使用 TLS 保护应用与网站之间的交互。为了承载这种交互，HTTP 代理先创建隧道。请求 https://example.com/catalog 时，顺序如下：

1. 应用连接代理，请求打开到 example.com:443 的隧道，使用的方法是 CONNECT。请求指定目标主机和端口，不包含页面路径。
2. 代理检查访问和所请求目标是否获准，包括所需的代理身份验证。它建立到目标的连接，并确认隧道已就绪。
3. 应用通过隧道与网站进行 TLS 握手，并检查网站证书。
4. 应用在这条 TLS 连接内发送 Web 请求。代理双向转发加密字节。

代理无需读取页面即可传送它。应用和网站仍然是网站 TLS 连接的端点。CONNECT 提供隧道，TLS 提供加密，并防止交互内容遭到未被察觉的修改。

因此，即使代理地址以 http:// 开头，HTTP 代理也能打开 HTTPS 网站。网站的 HTTPS 保护在隧道内部生效，不依赖应用与代理之间是否使用 TLS。

HTTPS 代理增加了什么

使用 HTTPS 代理时，应用先与代理建立 TLS，并验证代理证书，然后在这条受保护连接内发送 HTTP 请求，或用于建立隧道的 CONNECT 请求。应用与代理之间的网络观察者无法读取这些请求。

对于 HTTPS 目标，应用维持两条独立 TLS 连接：一条与代理建立，另一条通过隧道与网站建立。代理移除发给自己的外层保护，但内部网站数据仍保持加密。它将这些字节转发给能够解密它们的网站。对于 HTTP 目标，没有内层 TLS 连接，只有到代理的连接受到保护。

本比较描述启用证书检查的普通代理转发，不包含 HTTPS 检查或独立 VPN。加密到代理的连接，并不会把 HTTP 网站升级为 HTTPS。

代理和网站能看到什么

对于 HTTPS 目标，转发代理无法读取 TLS 连接内的页面路径、查询参数、Cookie、表单数据或返回内容。但它仍知道连接到自己的客户端 IP、CONNECT 中请求的目标主机与端口，以及流量的时间和大小。到代理的 TLS 让该段网络上的观察者无法读取 CONNECT，但代理必须据此执行操作，因此对代理本身并不保密。

代理凭据与网站登录信息分开发送。Basic 代理身份验证使用 Base64 编码用户名和密码，无需密钥即可解码。在普通 HTTP 代理连接上，这不能防止网络观察者读取它们。网站的 HTTPS 连接在隧道内才开始，不涵盖更早的代理登录。到代理的 TLS 才能保护登录信息在传输过程中的安全。

另一端的网站接收来自出口 IP 的流量，并读取发给自己的请求。它可以识别账户、会话 Cookie 或应用发送的其他信息。选择 HTTPS 代理，不会移除这些标识，也不会自动提高网站对出口 IP 的接受程度。

HTTPS 检查是另一种配置，见于某些受管理网络和调试工具。应用信任由检查代理控制的证书颁发机构，代理便可在两侧分别维持 TLS 连接的同时读取流量。普通 CONNECT 转发不要求安装这类证书。信任 HTTPS 代理自身的服务器证书，与允许它冒充网站，是两回事。

如何理解连接设置

代理设置需要地址、端口、连接协议，以及所需身份验证。代理 URL 中的协议适用于代理；目标 URL 中的协议适用于网站。

以下 curl 命令通过两种不同代理连接，请求同一个 HTTPS 网站。请将代理主机名和端口替换为所选连接方式提供的值：

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

第一条命令通过 HTTP 连接代理，然后创建 CONNECT 隧道及到网站的 TLS。第二条先与 HTTPS 代理建立 TLS，再通过它承载独立的网站 TLS 连接。两种情况都还需要提供代理服务要求的身份验证。

仅将 http:// 改成 https://，不会把仅支持 HTTP 的端口变成 TLS 端点。如果服务为 HTTPS 访问提供主机名，应使用该主机名：替换成 IP 可能导致证书名称不匹配。

应用中的标签同样需要仔细理解。名为“HTTPS 代理”的字段，可能只是为 HTTPS 网站选择代理，连接代理时仍使用普通 HTTP。在 curl 中，变量 HTTPS_PROXY 同样用于选择 HTTPS 目标的代理，其值以 http:// 开头也完全正确。标签说明哪些请求使用该设置，代理 URL 的协议方案则说明如何建立连接。

DNS 与经过代理的流量

HTTP 客户端提供目标主机名时，代理通常查询其 IP 并建立连接。如果需要通过代理自身的主机名找到代理，客户端会单独查询。浏览器也可能为预测或其他功能发出 DNS 查询。这些是不同查询；设置 Web 代理，并不会让每个 DNS 请求都经过它。

设置仅适用于应用实际发送到代理的流量。另一个程序可能仍然直接连接，例外列表也可能让选定网站绕过代理。例如，让 API 脚本经过代理，不会改变无关浏览器使用的路由。应在真正执行任务的应用和配置中检查出口地址。

到网站的 HTTP/2 与到代理的 HTTP/2

HTTP/2 允许多次交互通过独立流共享一条连接。使用代理时，需要明确是哪一段连接支持它。应用可以与网站协商 HTTP/2，这可以在使用 HTTP/1.1 CONNECT 创建的隧道内部进行。代理转发加密字节，无需理解网站的 HTTP/2 消息。

应用与代理之间的 HTTP/2 是另一项独立能力。每个 CONNECT 隧道使用自己的 HTTP/2 流，因此多个隧道可以共用一条到代理的连接。例如，通往两个不同网站的隧道可以使用该连接，同时保持独立的目标连接和网站 TLS 会话。这减少了额外建立客户端到代理连接的需求，但代理仍无法读取加密的网站请求内容。

两端都必须支持所选模式。HTTPS 本身并不意味着 HTTP/2：HTTPS 代理也可以使用 HTTP/1.1。性能还取决于客户端、网络路由、服务器负载和连接复用。HTTP/2 标签不保证每项任务都会提速。

如果应用和代理允许，普通 CONNECT 隧道也可以承载其他基于 TCP 的协议，不过目标端口可能受限。它不会转发 UDP。HTTP/3 使用基于 UDP 的 QUIC，因此不能以同样方式经过这个 TCP 隧道。基于 HTTP 的 UDP 转发使用 CONNECT-UDP 等附加机制，需要兼容实现。仅支持 HTTPS 或 HTTP/2，并不能证明支持这些机制。

HTTP 和 HTTPS 代理访问适用于哪些场景

对于浏览和网站测试，支持 CONNECT 的 HTTP 代理，为 HTTP 和 HTTPS 目标提供统一连接方式。团队可以从代理网络查看网站，同时仍由浏览器负责页面渲染、Cookie 和网站登录。

对于爬虫、API 客户端和定时监控程序，HTTP 客户端可以保持目标 URL 不变，通过所选出口 IP 发送请求。应用仍负责准备请求和处理响应。在 HTTPS 隧道内，代理承载这些交互，无需解析每个页面或 API 调用。

如果到代理的连接也需要保护，包括代理登录和目标请求，使用受 TLS 保护的 HTTPS 代理就有价值。当连接经过你无法控制的网络时，这一点很重要。客户端必须支持到代理本身的 TLS；仅能打开 HTTPS 网站还不够。

理解连接错误

故障可能发生在连接代理、打开隧道或与网站通信时。所处阶段比单独的错误码更能说明问题。

隧道建立及 TLS 握手完成，说明连接路径可以工作。但它们不保证网站接受特定账户、出口 IP 或请求。因此，即使代理正常运行，登录验证、CAPTCHA 或请求限制仍可能需要在网站或应用层面处理。