Cloudflare 520：检查 HTTP/2 回源的兼容性

网站经过 Cloudflare 间歇返回 520，源站直接访问却正常时，可以检查 Cloudflare 到源站这一段的 HTTP/2 连接。只有故障与回源协议存在对应证据，才适合沿这条线处理；520 还可能来自空响应、应用崩溃、异常响应头或连接提前关闭。

浏览器到 Cloudflare 使用 HTTP/2 或 HTTP/3，与 Cloudflare 到源站协商的协议是两回事。浏览器开发者工具里显示 h2，不能证明源站已经正确处理 HTTP/2。

把一次 520 对应到源站日志

保存失败 URL、时间与时区、Ray ID、请求方法，并查找同一时间的 Web 服务、应用及中间代理日志。对 POST 或管理操作，要核对响应是否丢失但操作已经执行，避免反复提交产生重复修改。

若有 Cloudflare 请求日志，比较边缘状态和源站状态。OriginResponseStatus = 0 不能单独说明源站返回了错误：缓存命中时可能根本没有回源，也可能是回源尝试没有得到可解析的 HTTP 响应。需要结合 CacheStatus、请求时间和源站记录判断。

重点检查源站是否实际协商 h2，协商后有没有流重置、协议错误或提前关闭连接。源站返回正常状态而 Cloudflare 仍给客户端 520 时，也要检查完整响应头和连接结束方式，不能只看应用访问日志中的 200。

比较同一个源站的 HTTP/1.1 与 HTTP/2

在有权限直连的环境中，固定相同域名、地址和请求路径做对照。下列示例使用不会修改业务数据的 GET 请求，地址需替换为实际源站：

curl -v --http1.1 --resolve example.com:443:203.0.113.10 \
  https://example.com/health
curl -v --http2 --resolve example.com:443:203.0.113.10 \
  https://example.com/health

确认所用 curl 支持 HTTP/2，并检查第二次实际协商到的协议；--http2 并不保证服务器一定选择 HTTP/2。测试时保留 TLS 证书验证，不能用直接请求 IP 或 -k 的结果证明域名和证书配置正常。

源站只允许 Cloudflare 地址、启用了客户端证书验证，或使用 Cloudflare Origin CA 时，本机直连可能不满足访问与信任条件。应在授权网络和正确 CA 配置下诊断，不要为测试长期开放源站或降低 SSL/TLS 安全模式。

单次直连也无法模拟 Cloudflare 的持久连接与并发请求。若简单 GET 两种协议均正常，但原业务仍间歇失败，要继续对照原请求、负载和连接日志，不能凭这个检查排除回源协议问题。

有对应证据时暂时关闭 HTTP/2 回源

Cloudflare 会对通过 ALPN 宣告支持 HTTP/2 的源站尝试该协议。如果源站接受协商后未正确处理 HTTP/2，可能出现 520；完全不支持 HTTP/2 的源站则会使用 HTTP/1.1，不是所有 HTTP/1.1 服务都需要修改。

若对照与日志持续指向这条连接，可以在站点的 Speed、Settings、Protocol Optimization 中临时关闭 HTTP/2 to Origin，记录原设置和变更时间。该开关影响回源协议，不能用浏览器协议显示来判断是否生效。

保留 Full (strict) 等预期 TLS 模式及源站访问限制。修改后重复原来会失败的请求，观察 520 比例、源站错误、连接数和资源使用；回到 HTTP/1.1 可能改变源站的连接负担。错误未改善时，应恢复原设置并继续检查其他原因。

修复后重新核对原故障场景

检查源站和中间代理的 HTTP/2 配置、已知问题及对应版本，经过受控更新后再恢复回源 HTTP/2，验证原请求和相应负载。不要只凭软件名称或版本号承诺修复，也不要把重建 Cloudflare 区域作为这类故障的处理步骤。

关闭开关后不再出现 520，只能说明这个变更与观察到的恢复有关。它尚不能确定具体是哪一层的协议实现、并发处理或连接复用出了问题；持续保留能够关联失败请求的日志，才有条件进一步定位。