HTTP 522 连接超时（Cloudflare）

Scrapeless Web Unlocker 为需要区分源站连接失败与可用结果的工作流获取公共页面内容。

HTTP 522 连接超时 是 Cloudflare 在联系源站 Web 服务器时发生超时的错误。即使 Cloudflare 无法与其后端服务器完成所需的连接交换，你的浏览器也可能已成功连接到 Cloudflare。因此，修复通常由网站运营方或托管服务提供商负责。

请求路径中 522 发生的位置

522 发生在请求路径中 Cloudflare 到源站的那一部分。访问者首先与 Cloudflare 通信；随后 Cloudflare 需要与为站点提供服务的源站通信。第二部分中的失败可能会生成一个正常返回给访问者的错误页面。收到该页面证明访问者收到了一个 HTTP 响应，但并不能证明源站处理了所请求的操作。

该 Cloudflare 522 定义 标识了两个相关情形：在建立 TCP 连接之前发生超时，以及在连接建立之后缺少确认。这些是传输层层面的观察。不要将第二种情形解读为“应用仅仅是花了太久时间才生成完整响应”；确认与应用完成是不同的事件。

如果请求从未到达应用层，应用访问日志中可能没有任何匹配条目。只有结合其他证据时，这种缺失才有意义。它可能表明连接失败、日志记录缺口，或请求被发送到了不同的源站。在决定适用哪种解释之前，请检查目标地址与日志覆盖情况。

522 与相近错误的区别

HTTP 状态与本地异常描述的是不同的边界。 HTTP 语义标准 定义了一般性的网关和服务器状态，而 522 是 Cloudflare 特定的诊断代码。在事件记录中保持这种区分有助于将问题路由给正确的负责人。

单个故障事件可能会产生不止一种症状。具有较短等待时限的采集客户端，可能会在 Cloudflare 返回 522 之前停止等待；而另一个等待时限更长的客户端，则可能收到该错误文档。这些观测可以描述同一底层故障，但它们并不属于同一个错误类别。

在调整容量之前先检查源站地址

配置的源站地址必须与当前被部署来处理该网站的服务器一致。对比 Cloudflare 的 DNS 配置与托管服务商当前地址以及期望的环境。最近的一次迁移、实例替换或 DNS 修改，可能会让流量仍被指向旧的目标。

确认源站期望的主机名和端口。如果缺少所需的监听器，或未提供预期的虚拟主机，那么仅仅服务器在线还不够。在进行授权的直连源站检查时，务必保留正确的主机名和 TLS 期望；仅用 IP 测试可能会访问到不同的虚拟主机，从而产生误导性的证据。

保持排查范围聚焦。如果一个主机名失败而另一个正常，请比较它们的源站映射和路由配置，而不是假定整个托管平台不可用。如果同一源站上若干互不相关的网站同时故障，共享网络或资源方面的证据会更加重要。

检查防火墙与托管网络控制项

防火墙检查应确定 Cloudflare 的连接是否到达源站并收到预期的回复。请审查主机防火墙、安全组、托管过滤器以及路径中的任何自动阻断系统。处于外层网络的控制项可能会在操作系统记录应用请求之前就丢弃流量。

在架构需要 Cloudflare 到源站访问的情况下，验证当前 Cloudflare 地址范围已由预期的策略处理。不要以不受限制的公共访问替换特定策略作为诊断捷径。要求托管服务提供商标识相关丢弃行为的来源、目的地、动作和时间戳。

将配置历史与首次故障发生的时间区间进行对比。与宕机关联在一起的规则更新只是线索，而不是证据。查找日志或数据包中的匹配流量，然后测试最小且合理的修正。记录该规则存在的原因，以免后续清理时再次引入这一限制。

调查一个正在运行但无响应的源站

即使运行中的源站，在其资源或网络路径受限时，仍可能无法及时接受或确认连接。检查连接数、监听器健康状况、CPU 压力、内存压力以及托管服务提供商对网络的观测。核实故障是否影响新建连接、现有连接，或只是部分路径。

仅依赖应用程序指标可能会忽略问题。一个请求吞吐量较低的仪表板，可能意味着应用程序仍有空余容量，也可能意味着请求根本没有到达应用程序。将应用程序遥测与传输层和主机指标结合起来，这样就不会把低吞吐量误认为是服务健康。

保持连接（keep-alive）配置是另一项值得根据部署需求进行核查的源站端细节。避免同时更改多个传输设置。范围更窄且经过测试的变更会产生可解释的证据，而同时更改 DNS、防火墙规则和服务器容量则会使难以判断究竟是什么修复了连接路径。

使用时间线连接浏览器和源站证据

时间线应显示访问者何时开始导航、Cloudflare 何时返回错误，以及在此期间源站观测到的情况。浏览器计时和服务器计时描述的是不同的视角。 导航计时模型 有助于区分导航阶段，但仅靠浏览器端的计时无法揭示 Cloudflare 与源站之间的每一次交互。

在事故系统中记录带有时区的时间戳。在可用时，将错误页面的请求标识符与相关的主机名和源日志进行关联。如果各设备的时钟未对齐，要明确说明这一点，而不是声称在不同机器上发生的事件之间存在精确匹配。

在相同路由配置下，将失败的时间区间与已知的成功时间区间进行比较。注意目标地址、连接是否成功以及主机健康状况的变化。一次孤立的成功页面加载并不能证明源站在整个受影响期间始终保持健康，尤其是在涉及多个源站或多条地理路径的情况下。

访客和数据收集者应当保留的内容

访客应保留足够的证据，以便站点运营者调查问题的来源路径。包括受影响的地址、错误编号、大致时间以及页面上显示的请求标识符。报告问题是影响整个站点还是特定操作，同时不要暴露私有查询参数或认证细节。

数据收集者应将 522 结果保留在目标数据集之外。若任务是收集产品价格，则带有 Cloudflare 品牌标识、看起来有效的 HTML 文档并不能满足该任务。应存储一次被分类的失败，并保留任何较早的价格及其最初的采集时间。这样可以区分当前数据缺失与价格实际未变。

The Cloudflare 内容验证工作流 与此接受边界相关。在传输完成后检查页面标识和所需字段。仅当下游使用方能够区分缺失的观测值和已接受的记录时，采集时的错误处理才有用。

Web Unlocker 不会修复源站服务器

Web Unlocker 可以为公共页面工作流提供托管内容检索，但无法修正网站的 DNS 映射、重新打开其防火墙或恢复其源站容量。这些控制权属于运营方。它在 522 排查中的角色仅限于检索路径以及从该请求中可获得的证据。

审查 Web Unlocker 介绍 在决定渲染检索是否适合该收集任务之前，并使用当前 Scrapeless 定价 用于工作负载规划。当响应契约区分服务级结果和目标站点结果时，务必将二者分开。已完成的 API 交互并不自动意味着成功收集到目标页面。

当源不可用时，为采集定义一个停止条件。继续针对受损的源接收更多工作会浪费资源，并掩盖最早出现的有用证据。只有在责任所有者确认该源能够承载预期流量之后，且根据你的运行策略，才恢复正常采集。

结论

HTTP 522 的调查从源站连接路径开始。确认目标地址，检查网络控制，并将传输证据与主机健康状况进行关联。访问者和收集者应提供简明的事件记录，并准确保留无法获取的观测信息；站点运营方和托管服务提供商必须修复底层的源站通信问题。