504 Gateway Time-out是CDN加速场景下非常典型的一类错误，表现形式是用户访问页面时长时间转圈，最终浏览器返回一个超时提示页。与502 Bad Gateway不同，504意味着CDN边缘节点成功连上了源站，但源站在CDN等待的时间窗口内没有返回完整的响应。换句话说，问题大概率不在CDN本身，而在源站的响应速度上，其中脚本执行超时和慢SQL是最常见的两大元凶。
一、先搞清楚504的产生机制与判定链路
当用户请求到达CDN边缘节点后，如果缓存未命中，CDN会向源站发起回源请求。绝大多数CDN对回源请求都设置了等待超时，常见默认值在30秒到60秒之间。一旦源站在这段时间内没有把响应头和响应体回给CDN，CDN就会断开连接，向用户返回504。理解这个机制很重要，因为它直接决定了排查方向：与其怀疑CDN，不如去源站找响应慢的原因。
典型的链路是CDN到Nginx反向代理，再到PHP-FPM或Tomcat等应用服务，最后连接数据库。任何一环变慢都可能触发504，但经验上80%以上的案例集中在应用层的脚本执行时间和数据库的慢查询上。可以先用curl直接请求源站IP绕过CDN验证：如果直连源站同样超时或耗时极长，就确认问题在源站；如果直连很快，才需要回头检查CDN配置和回源链路。
另外要注意区分504和502。502通常是后端进程崩溃、端口不通、PHP-FPM worker耗尽导致连接直接失败；而504是后端活着但太慢。如果你的监控里两者交替出现，往往是后端资源被慢请求占满的连锁反应，此时优先解决慢请求才是治本。
二、定位执行超时的源站脚本
确认问题在源站后，第一步是找出哪些请求耗时最长。以Nginx加PHP-FPM的架构为例，可以通过在access_log中记录$request_time和$upstream_response_time来观察每个请求的实际耗时。
# nginx.conf 中定义记录耗时的日志格式
log_format timed '$remote_addr - [$time_local] "$request" '
'$status $body_bytes_bytes '
'rt=$request_time urt=$upstream_response_time';
# 统计耗时超过5秒的请求
awk '($NF ~ /urt=/) {print}' /var/log/nginx/access.log | grep -E "urt=[5-9]\.|urt=[0-9]{2,}\."
拿到慢请求的URL后，下一步进入应用层分析。PHP可以在脚本入口和出口打点记录执行时间，也可以借助XHProf或Tideways做性能剖析；Java应用则可以通过Arthas的trace命令快速定位某个接口内部哪个方法最耗时。实践中要注意一个常见误区：脚本本身不慢，但它同步调用了外部接口或循环执行了大量SQL，这类问题在代码审查时重点看循环内是否有数据库查询。
同时别忘了检查应用自身的超时配置是否合理。例如PHP的max_execution_time、Nginx的fastcgi_read_timeout、PHP-FPM的request_terminate_timeout，这三者层层递进。如果max_execution_time设了30秒而CDN回源超时是30秒，等于两边同时到期，很容易出现边缘情况。一般建议源站内部超时略小于CDN回源超时，让源站先放弃并记录日志，而不是让CDN先掐断连接导致源站白白浪费资源继续计算。
三、用慢查询日志揪出拖垮接口的慢SQL
脚本慢的根因往往在数据库。以MySQL为例，开启慢查询日志是定位慢SQL最直接的手段，建议把long_query_time设置在1秒甚至0.5秒，宁可日志多一点也不要漏掉问题语句。
-- 开启慢查询日志并设置阈值 SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; -- 分析慢日志中扫描行数最多的语句 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
拿到慢SQL后，第一件事是用EXPLAIN查看执行计划。重点看type列，如果出现ALL说明全表扫描；再看rows列的预估扫描行数，以及key列是否用上了预期索引。很多慢SQL的罪魁祸首是隐式类型转换，比如varchar字段用数字比较、字符串字段与不同字符集的表关联，这些都会导致索引失效。还有一种高频问题是深分页，LIMIT 1000000,20这类语句会扫描并丢弃前一百万行，正确的做法是改用游标方式，记住上一页最后一条记录的主键，下一页直接从该主键之后取数。
对于多表JOIN的复杂查询，要检查关联字段是否都有索引，驱动表选择是否合理。如果业务允许，可以把大查询拆成多次小查询在应用层组装，或者引入缓存层。需要注意的是，加了索引不等于万事大吉，索引本身也有维护成本，对高频写入的表滥用索引反而会托慢写入并撑大存储，索引设计要结合实际查询模式来权衡。
四、优化手段与CDN侧的兜底配置
定位到具体瓶颈后，优化通常分三路推进。针对脚本层：把同步的外部调用改成异步或加超时控制，避免一个第三方接口卡住整个请求；针对SQL层：补齐索引、消灭全表扫描、对统计类大查询做预计算或读写分离；针对架构层：对热点数据加Redis缓存，把数据库的重复查询挡在缓存层。一个实用的原则是任何预期耗时超过一秒的动态请求都应该重新审视设计，正常用户的等待耐心在3秒左右，靠加超时时间掩盖慢是走不远的。
# Nginx 侧对上游PHP-FPM的超时控制示例
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_read_timeout 25s; # 略小于CDN回源超时30s
fastcgi_connect_timeout 3s;
}
CDN侧的兜底配置同样重要。适当调大回源超时能给慢接口留出缓冲，但更重要的是配置合理的回源重试次数，一般1到2次即可，重试过多会在源站已经吃紧时雪上加霜。对于纯静态或半静态内容，配置边缘缓存规则减少回源比例是降低504概率的根本手段。此外建议为504错误配置自定义错误页和监控告警，当错误率超过阈值时第一时间收到通知，而不是等用户投诉才发现。
总结一下排查思路：先用curl直连源站确认问题归属，再看Nginx日志找到慢请求的URL，然后通过应用剖析和慢查询日志定位到具体脚本或SQL，最后从代码、索引、缓存三个层面优化，并配合合理的超时与重试配置兜底。504看似是网关报错，实则是源站性能问题的一次集中暴露，把响应时间压下来，这类错误自然会消失。