HTTPS 如何工作？

Scrapeless Proxies 支持将 HTTPS 请求通过由你的应用程序配置的代理连接进行路由。

HTTPS 是在安全传输之上承载的 HTTP，该安全传输会对预期的端点进行认证，并保护传输中的数据。TLS 提供 HTTPS 使用的加密保护。应用程序仍然在交换 HTTP 请求和响应，但网络观察者通常无法在不被发现的情况下读取或修改受保护的内容。

这种保护有一个明确的边界。终止 TLS 连接的服务可以读取其收到的 HTTP 消息。如果 CDN 终止公共连接并向源站服务器打开另一条连接，就会有多条独立的连接需要评估。浏览器的安全连接指示器并不会描述公共端点后面的每一个内部跳数。

HTTPS 保护什么？

HTTPS 保护安全连接内数据的机密性和完整性，并对客户端所期望的服务器身份进行认证。 TLS 协议规范 定义了建立这些属性的握手和受保护记录交换。

机密性防止普通中间方读取受保护的 HTTP 头和主体。完整性使通信双方能够检测对受保护数据的修改。认证帮助客户端基于证书和客户端的信任配置确认对端已被授权使用正在访问的主机名。

HTTPS 并不证明某个企业诚实可信，也不保证页面上的声明是正确的。它同样不会消除端点应用内部的安全问题。服务可以接受通过安全传输送达的请求，却在解密后错误处理数据。请将传输保护与对应用的信任区分开来。

在 HTTP 请求之前会发生什么？

新的 HTTPS 连接会在正常的受保护 HTTP 交换之前建立安全传输。客户端首先需要到达目标的网络路径，通常使用 DNS 获取地址。然后通过 TLS 协商连接参数并对对端进行认证。

简化后的 TLS 握手从客户端声明其支持的参数和密钥共享信息开始。服务器选择兼容的设置，并根据握手要求提供认证材料。双方在使用这些密钥保护应用数据之前，会先推导出通信密钥并验证整个交换过程。

这是一种概念性描述，而不是每个连接都固定不变的数据包序列。会话恢复和协商出的协议版本会改变交换流程。已有连接也可以承载额外请求，而无需为每个请求完全重新执行一次握手。

证书的公钥并不是简单地用来加密网页的每一个字节。现代 TLS 将认证和密钥协商与对称流量保护结合起来。这种分工使连接既能认证对端，又能高效保护后续数据交换。

证书验证如何工作？

证书验证会检查在客户端信任策略下，所呈现的身份对于目标服务是否可接受。客户端会评估证书链、有效性约束以及主机名身份。不同主机名的证书不会因为服务器可以通过同一个 IP 地址访问就自动变为有效。

“ HTTPS 身份和证书规则 ”将所请求的源与预期的安全端点关联起来。这就是为什么即使数值地址指向正确的基础设施，仅仅把域名替换为数字地址也可能失败：客户端的身份期望已经发生了变化。

证书链通常会通过中间证书把服务器证书连接到客户端认可的信任锚。不同操作系统、运行时和受管环境的信任存储可能不同。在一个浏览器中可用的连接，可能在证书配置不同的容器中失败。

当验证失败时，请检查主机名、证书链、信任存储以及系统时间。关闭验证会移除建立对端身份的检查。不应将其当作数据采集器中解决连接问题的常规手段来推荐。

加密内容之外还有哪些信息是可见的？

HTTPS 并不会隐藏网络连接的所有属性。网络中间方通常可以观察到目标地址以及流量的时间和体积特征。域名是否可见取决于 DNS 传输方式和 TLS 特性，因此仅凭 HTTPS 就声称在所有环境中都能隐藏所请求主机名是不准确的。

URL 路径、查询字符串和普通 HTTP 头都在 TLS 连接内受到保护。它们对解密请求的端点仍然可见。如果查询字符串包含敏感信息，它在解密后仍可能出现在端点日志、浏览器历史记录或应用监控中。

在合适的位置放置凭据并有意识地管理日志。在途加密并不意味着可以放心地把机密信息嵌入任意 URL，或将整个请求头复制到诊断报告中。数据的生命周期会在网络传输结束后继续。

HTTPS 如何通过 HTTP 代理传输？

传统 HTTP 代理可以创建一个隧道，客户端在该隧道内与目标建立 TLS 连接。客户端使用 CONNECT 方法请求代理连接到某个主机和端口。一旦隧道建立，加密流量就可以穿过代理，而无需由代理终止目标的 TLS 会话。

这里有两个不同的问题：客户端如何连接到代理，以及它如何保护目标流量。使用 HTTP 协议的代理 URL 仍然可以通过隧道承载 HTTPS 目标。相反，与代理建立加密连接并不会自动决定之后每一跳是如何受到保护的。

检查代理通过终止并重新建立 TLS 连接来更改模型。此类部署依赖显式的信任配置，并且可以检查解密后的内容。不要假设所有代理都会检查 HTTPS，或假设所有代理都无法检查它；应识别实际使用的是哪种架构。

当 CDN 终止 TLS 时，会发生哪些变化？

终止 TLS 的 CDN 是客户端连接的安全终端，并且可能对源站使用单独的连接。CDN 可以处理解密后的 HTTP 请求，应用路由或缓存规则，并在必要时从源站获取内容。

源站连接有其自身的协议和验证设置。安全的客户端到 CDN 连接并不能证明 CDN 到源站的连接使用了同等程度的保护。网站运营方应根据应用的需求配置并验证这两个边界。

这种架构也会影响观测结果。客户端看到的证书描述的是公共 TLS 端点。HTTP 响应可能是从边缘缓存中提供的，而不是在那一刻由源站生成的。仅凭任一观测都无法确定源站应用的位置或当前状态。

HTTP 版本与 HTTPS 有何关系？

HTTP 版本定义了消息传输行为，而 HTTPS 描述了安全源和传输要求。HTTP/1.1 和 HTTP/2 通常通过基于 TCP 的 TLS 进行传输。HTTP/3 使用 QUIC，它将基于 TLS 的安全性集成到其传输层中。

The HTTP/3 映射 更改了连接机制，但保留了诸如方法、状态码和字段等 HTTP 概念。应用程序不应假定每个 HTTPS 连接都遵循相同的 TCP 建立顺序。

协商取决于客户端和服务器的功能以及可用的网络路径。在客户端启用对某个协议的支持并不保证特定目标会使用该协议。如果协商出的协议与性能或兼容性调查相关，请记录下来。

为什么仅靠重定向并不能构成完整的 HTTPS 策略

HTTP 到 HTTPS 的重定向是在客户端已经到达 HTTP 端点之后才对请求进行升级，而 HSTS 则是在其存储的策略下指示支持的浏览器使用 HTTPS。 HTTP 严格传输安全机制 有助于防止随后对已受保护主机发起的不安全连接尝试。

在没有现有策略的情况下进行的首次访问，与具有已存储或预加载策略的访问有着不同的特性。在解释为何重定向和 HSTS 策略是互补关系时，这一区别非常重要。两者都不应被描述为能够证明每个嵌入资源或内部服务都已正确配置。

对于一个 API 客户端，需要检查该客户端实际实现了哪些浏览器策略。Python 库并不会自动受制于与桌面浏览器相同的已存储 HSTS 状态。请直接配置预期使用的 HTTPS URL，并保留证书验证。

如何按阶段诊断 HTTPS 故障

通过确定失败的阶段来诊断 HTTPS 故障：名称解析、连接、代理隧道、TLS 验证或 HTTP 交换。每个阶段都会产生不同的证据。从目标接收到的 HTTP 状态码意味着连接的进展比证书验证失败要更进一步。

对于代理流量，要区分对代理的身份验证和对目标服务器的身份验证。目前 无爬取代理连接工作流程 说明如何获取正确的通道设置。不要将代理密码作为应用凭据发送到目标端。

The SSL 和 TLS 代理架构 讨论为隧道和终止行为提供了相关背景。在评估时 无爬取代理解决方案，验证客户端所需的协议、信任模型和会话行为。审查 所选产品的定价 独立于其传输配置。

最后，检查返回的表示形式。有效的 TLS 连接和成功的 HTTP 状态可能会返回登录页面或意外的文档。传输检查用来确定字节是如何到达的；内容检查用来确定这些字节是否满足采集任务的要求。

结论

HTTPS 在经过验证的安全连接中保护 HTTP。了解 TLS 在何处终止，保持证书验证处于启用状态，并按阶段诊断故障。对于代理和 CDN 路径，记录每个连接边界，以确保安全声明与实际架构相匹配。