Cloudflare Error 524 表示已经连接源站但未及时收到响应；应对齐 Ray ID、Nginx 上游耗时和应用日志，再优化慢请求或改为异步任务。
Cloudflare 页面显示 Error 524 时，先不要反复刷新，也不要只调大 Nginx 超时。这个错误表示 Cloudflare 已经连上源站，但源站没有在 Cloudflare 当前默认的代理读取时限内返回 HTTP 响应。先在 Cloudflare 记录报错网址、时间、时区和 Ray ID，再到宝塔“网站 → 对应站点 → 日志”或 SSH 检查同一时刻的 Nginx、PHP、应用和数据库耗时。
查看日志、负载和慢请求通常不额外收费，也不会修改数据。真正有风险的是重复提交导出、支付、建站安装等写入请求，或者在不知道事务状态时直接杀掉数据库查询：前者可能造成重复任务，后者可能触发回滚、锁等待或业务数据不一致。默认选择是先保存现场并区分单个慢接口还是整站资源不足，再优化请求或改成后台任务；不要把“调大超时”当成根因修复。
先分清 524、522 和源站 504
Cloudflare 官方当前说明，524 发生在 Cloudflare 与源站已经建立连接，但源站迟迟没有给出响应时。522 更偏向 Cloudflare 无法及时和源站完成连接或请求确认；504 可能由源站 Nginx、上游应用或 Cloudflare 返回。错误页面相似，处理入口却不同。
| 现场 | 更可能卡在哪里 | 先做什么 |
|---|---|---|
| 只有导出、备份、搜索等长请求报 524 | 应用或数据库处理超过 Cloudflare 时限 | 查该 URL 的源站总耗时和上游耗时 |
| 全站很快出现 522 | 连接、防火墙、源站负载或网络链路 | 先按连接层检查，不调应用执行时间 |
| 源站直连也返回 Nginx 504 | Nginx 等待 PHP、Node 或其他上游超时 | 查 Nginx 错误日志和对应上游服务 |
| 源站很快，Cloudflare 仍在固定时间报 524 | 测试对象、缓存、域名或回源目标可能不一致 | 核对 Host、源站 IP、响应头和 Ray ID |
| 上传过程中报 524 | 请求体向源站写入超时或源站处理过慢 | 保留上传大小、持续时间和源站日志，不盲目重传 |
如果现场其实是 521 或 522，可先参考Cloudflare 521/522 源站连接排查；如果是源站 Nginx 明确返回 504，则转到Nginx 504 上游超时排查。不要因为三个错误都含“超时”就混用配置。
第一步：记录报错时间、网址和 Ray ID
先复制完整 URL，记录发生时间和时区，并保存 Cloudflare 错误页底部的 Ray ID。若只有登录后的管理接口失败，还要记录动作名称、文件大小或查询范围，但不要把 Cookie、令牌、用户数据和完整日志发到公开群组。
Cloudflare 控制台选择对应域名后，从“分析和日志”中的 HTTP 流量或错误分析查看 524 的 URL、时间和节点信息。不同套餐可见字段可能不同；看不到明细时，仍可用 Ray ID、时间和 URL 对齐源站日志。Cloudflare 的错误分析是抽样数据，不能把图表数量当成源站全部请求数。
第二步：比较经过 Cloudflare 与直接源站的耗时
在不会触发写入的公开页面或专用健康检查地址上做对比。下面命令中的域名、源站 IP 和路径必须换成实际值；不要对付款、安装、提交表单或批量导出接口重复执行。
curl -sS -o /dev/null \
-w 'cdn code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' \
https://www.example.com/health
curl -sS -o /dev/null \
--resolve www.example.com:443:203.0.113.10 \
-w 'origin code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' \
https://www.example.com/health
203.0.113.10 是文档示例地址，不能直接使用。time_starttransfer 表示收到首字节前的时间。若直连源站同样很慢，继续查源站应用；若直连很快而 Cloudflare 路径异常，核对测试是否命中同一源站、同一 Host、同一请求条件。源站 IP 属于敏感运维信息，对外截图前必须遮挡。
第三步：在 Nginx 里定位慢的是整次请求还是上游
先查看当前访问日志是否已经包含请求总耗时 $request_time 和上游响应时间 $upstream_response_time。宝塔站点日志通常能直接看到 URL 和状态，但不一定记录耗时。先用 nginx -T 确认真实生效配置和日志路径。
sudo nginx -T 2>&1 | grep -nE 'server_name|access_log|error_log|log_format|proxy_pass|fastcgi_pass'
sudo tail -n 200 /path/to/site-access.log
sudo tail -n 200 /path/to/site-error.log
把日志路径换成生效配置中的真实值。nginx -T 可能显示内网地址、证书路径和上游信息，分享前要脱敏。若日志没有耗时字段，可以在备份配置后为目标站点增加临时带耗时的日志格式；修改前先确认不会与面板自动生成配置冲突，保存后必须通过 nginx -t 才能平滑重载。
log_format timed '$remote_addr $time_iso8601 "$request" '
'status=$status rt=$request_time '
'urt=$upstream_response_time ustatus=$upstream_status';
access_log /path/to/site-timed.log timed;
rt 很高、urt 也很高，通常是 PHP、Node、Java 或数据库链路慢；rt 高但没有上游时间，检查 Nginx 本地文件、请求体接收和内部重定向；多个 urt 值则可能发生了上游重试。不要只凭一条日志就重启服务，先看同一 URL 是否稳定复现。
第四步：检查 PHP、应用和数据库是否真正卡住
如果 524 只出现在 WordPress 导入、备份、报表、搜索或大型 API，先查应用日志和服务状态。以下都是只读检查；服务名、日志单元和进程名要按环境替换。
systemctl --no-pager --full status php-fpm nginx
journalctl -u php-fpm --since '15 minutes ago' --no-pager | tail -n 200
free -h
vmstat 1 5
ps -eo pid,ppid,stat,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20
有些系统的服务名是 php8.2-fpm、php8.3-fpm 或面板自定义名称。若 PHP-FPM 工作进程已满，先找慢脚本、外部 API 或数据库等待；若 CPU、内存和 I/O 都紧张，应先止住并发任务。日志里出现数据库锁等待时，先保存线程、事务和业务时间点，再由了解数据影响的人处理，不要执行来源不明的批量杀查询脚本。
第五步：按请求类型修复，而不是统一增加超时
普通页面或 API：优先缩小查询范围、增加必要索引、移除串行外部调用、启用安全缓存，或把非必要工作移出同步请求。目标是让用户请求尽快返回，不是让浏览器一直等待。
导出、备份、生成报告：把任务改为后台队列，前端先获得任务 ID，再轮询进度和下载结果。这样即使任务执行几分钟，也不必让一条 HTTP 连接持续占用。任务必须设计幂等或防重复提交，否则用户刷新会启动多份任务。
确实需要长连接的企业业务：Cloudflare 当前文档显示代理读取超时默认是 125 秒，只有 Enterprise 区域可在允许范围内调整。普通套餐不能靠 Nginx 的 proxy_read_timeout 300s 绕过 Cloudflare 更早结束的连接。即使套餐允许调高，也应先确认长请求不会占满 PHP-FPM、连接池或数据库会话。
临时改为 DNS only：只适合独立、受控的后台任务子域名。灰云会绕过 Cloudflare 的代理、缓存和部分安全能力，并暴露源站访问入口；切换前要有源站防火墙、TLS、认证和访问控制，不能把主站整体切走来掩盖慢请求。
修复后怎样验收
先在源站验证目标请求能在预期时间完成，再从 Cloudflare 公网路径验证。至少检查一次成功请求、一次受控失败、并发下的资源余量，以及写入任务是否重复。记录 Nginx 的 rt、urt、应用耗时和数据库耗时，确认瓶颈真的下降，而不是只把报错推迟。
curl -sS -D /tmp/headers.txt -o /dev/null \
-w 'code=%{http_code} start=%{time_starttransfer} total=%{time_total}\n' \
https://www.example.com/health
grep -iE 'server:|cf-ray:|content-type:' /tmp/headers.txt
只对无副作用的地址执行。若使用缓存，还要分别验证首次 MISS 和后续 HIT；若是后台任务，要确认任务状态、最终文件、权限和重复提交保护。Cloudflare SSL 故障不是 524 的同一分支，可参考Cloudflare 525/526 源站 TLS 排查。
怎样回退
如果新增日志格式或调整 Nginx 后站点异常，恢复配置备份，执行 nginx -t，成功后再平滑重载。若刚上线的异步任务有重复执行或权限问题，先停止新任务入口，保留队列、任务 ID 和审计日志，由业务侧确认哪些任务可重试；不要删除未知任务或产物。若临时启用了 DNS only，确认源站和 Cloudflare 代理配置都恢复后，再清理只为临时直连开放的防火墙规则。
联系 Telegram 客服 