502与504频繁出现时，回源侧的排查重点应放在源站可用性、网络链路质量以及超时参数配置这三层关系上，多数情况下根源在于源站响应慢或回源链路拥塞，而非CDN或WAF节点本身。
502 Bad Gateway是什么原因引起的：先分清网关报错与源站报错
502和504在HTTP语义上的本质区别
502 Bad Gateway表示网关或代理服务器从上游服务器收到了无效响应，常见的是源站进程崩溃、端口无监听、返回了无法解析的响应包，504 Gateway Timeout则表示网关在规定时间内没有收到上游的响应，源站进程还在,但处理速度超过了阈值。
行业共识认为，502偏向于“连接建立失败”，504偏向于“连接建立成功但响应超时”，这个区分决定了排查方向完全不一样，502查的是端口、进程、防火墙；504查的是慢查询、阻塞、超时参数。
回源侧出现502的典型触发场景
- 源站机器负载过高，Nginx或Apache的worker进程全部被占满,新连接无法被accept。
- PHP-FPM或Java应用线程池被打满，请求在应用层排队,网关层直接判定连接失败。
- 源站防火墙或安全组误拦截了CDN回源IP段，表现为部分区域502,部分区域正常。
- 源站域名解析到了多个IP，其中一个IP的机器宕机,而健康检查未及时摘除。
502 Bad Gateway与504 Gateway Timeout排查：先看日志再动配置
第一步：确认报错出现的节点位置
打开浏览器开发者工具，查看响应头中的Via字段或Server字段，如果是CDN场景，响应头里通常能看到类似Via: cdn或X-Cache: MISS的标记。确认报错是发生在CDN与源站之间，还是客户端与CDN之间,这一步能直接排除掉一半的干扰因素。
如果直接访问源站IP（用本地hosts绑定）也报同样的错误，问题基本锁定在源站自身，如果直接访问源站正常但走CDN报错,先检查回源HOST头是否配置正确。
第二步：查看源站访问日志与错误日志
以Nginx为例,重点看两个文件：
/var/log/nginx/access.log：看回源请求的upstream_status列，502对应的是502，504对应的是504。/var/log/nginx/error.log：常见错误关键字包括upstream prematurely closed connection、upstream timed out、connect() failed (111: Connection refused)。
connect() failed表示源站端口没有服务在监听。upstream prematurely closed表示连接建立后，源站进程在响应完成前主动断开了连接，通常是PHP-FPM进程崩溃或worker被kill。
upstream timed out则是源站在规定时间内没处理完。
第三步：检查源站端口与进程状态
netstat -tlnp | grep :80 ps aux | grep nginx ps aux | grep php-fpm
如果端口在监听，但请求仍然502,手动用curl模拟一次回源请求：
curl -I -H "Host: www.example.com" http://127.0.0.1
观察返回结果，如果curl直接返回502或连接重置，说明问题在源站内部，与CDN无关，此时需要逐一排查PHP-FPM、数据库连接、Redis等中间件。
回源链路四层排查思路：从边缘到源站逐段剥开
第一层：DNS解析与回源IP有效性
回源IP的可用性是最容易忽略的盲区，很多站点配置了多个源站IP做负载均衡，但其中一个IP已迁移或下线，DNS缓存尚未过期,检查方式：
- 用
dig命令查看源站域名的解析结果,确认所有A记录对应的机器都在正常运行。 - 在CDN控制台逐一检查源站配置,确认没有配置已失效的IP。
- 如果源站是负载均衡设备（如SLB、CLB），检查后端服务器组的健康检查状态,确认是否有机器被标记为异常但未自动剔除。
第二层：网络链路质量与MTU异常
源站与CDN节点之间的链路质量直接影响回源成功率，近年来CDN节点覆盖范围越来越广，但跨境、跨运营商回源仍是重灾区。
- 使用
mtr命令从源站反向追踪到CDN节点IP，观察丢包率与延迟，丢包率超过5%就需要重点关注。 - 注意MTU值不一致问题，会导致大包被丢弃而小包正常，表现为页面部分资源加载失败,API请求超时。
- 检查源站带宽是否被打满，用
iftop或nload工具查看实时流量,回源带宽超过上限会直接导致延迟增加和超时。
第三层：源站并发能力与连接数限制
这是502问题最集中的根源区域，源站的最大并发连接数是一个硬性门槛，软件层面由Nginx的worker_connections和系统内核的net.core.somaxconn共同决定,硬件层面由CPU核数和内存限制。
常见配置检查项：
- Nginx的
worker_processes是否设置为CPU核数，worker_connections是否合理（通常每个worker设置1024-4096）。 - 系统文件描述符上限
ulimit -n是否够大,生产环境建议设置到65535以上。 - PHP-FPM的
pm.max_children是否与实际内存匹配，内存小的机器配置过大，直接导致OOM Killer频繁杀进程。
多数情况下，源站4核8G的机器PHP-FPM的max_children设置在20-30之间比较合理,具体需要根据单个进程平均内存占用反推。
第四层：超时参数配置兼容
CDN侧回源超时、Nginx代理超时、PHP-FPM超时，三层超时时间需要按从大到小排列，即CDN回源超时时间 > Nginx代理超时时间 > PHP-FPM超时时间，如果层级关系颠倒，就会出现CDN还在等待,但Nginx已经断开连接的情况。
| 层 | 参数 | 常用值 |
|---|---|---|
| CDN | 回源超时 | 30-60秒 |
| Nginx | proxy_read_timeout | 15-30秒 |
| Nginx | proxy_connect_timeout | 3-5秒 |
| PHP-FPM | request_terminate_timeout | 30-60秒 |
| PHP | max_execution_time | 30秒 |
502 Bad Gateway常见业务场景中怎么排查处理：按应用类型区分
Nginx + PHP-FPM架构
这是最常见的架构模式，先检查PHP-FPM的状态页（如果已开启），访问/status查看当前活跃进程数、队列长度和空闲进程数，如果max_children已耗尽且队列有积压,说明并发超过了处理能力。
排查建议：
- 开启PHP-FPM的slow log，定位哪些请求执行时间超过阈值,通常设置为5秒。
- 检查数据库慢查询日志，90%的PHP-FPM阻塞与数据库查询效率低有关。
- 如果某段时间内502集中爆发，用
dmesg查看是否有OOM Killer记录,确认是否因内存不足导致进程被杀。
Java应用与Tomcat
Java应用的502问题多与线程池耗尽或Full GC停顿相关，查看Tomcat的localhost.log和catalina.out，搜索Connection refused或SocketTimeoutException。
重点检查：
- Tomcat的
maxThreads配置，默认200,在高并发下很容易耗尽。 - JVM堆内存设置与GC日志，Full GC频繁且停顿时间超过3秒时,应用会短暂失去响应。
- 数据库连接池，连接池耗尽时JDBC获取连接会等待，超过阈值会抛异常,反映到网关层就是502或504。
CDN回源到OSS或对象存储
如果你在处理视频云或者图片处理类的502网关超时排查，OSS场景相对简单，优先检查签名URL是否过期、Bucket是否设置了防盗链规则、源站类型在CDN控制台是否选择正确（是选了“OSS域名”还是“自定义源站”），处理方式也很直接：如果确认是签名问题，换用CDN源站托管功能或改用私有Bucket + CDN鉴权,能从根本上规避。
另外一个常见的情况是CDN回源到OSS时，Bucket为私有权限且CDN控制台未配置对应的回源鉴权头，OSS会拒绝访问并返回403，部分CDN节点会将403缓存并向上游报502，这类问题只需要在CDN的回源配置中开启简米云OSS回源或酷番云COS回源,问题即解决。
跨地域回源
源站在国内而CDN节点在海外，或者反向交叉，这类地理链路问题比较棘手，跨境链路的国际出口带宽在晚高峰（北京时间20:00-23:00）拥塞很严重,延迟波动大。
处理建议：
- 使用专线回源而不是公网回源,云厂商的CDN服务通常提供内网回源通道。
- 在海外区域部署源站实例,用全球加速产品把请求调度到就近源站。
- 降低CDN节点对源站的探测频率,避免因链路抖动触发健康检查失败而主动摘除。
502 Bad Gateway与504 Gateway Timeout区别大不大：本质上都是源站出了问题
这个问题在运维社区里经常被问到，简单回答：区别不大，排查路径基本可以共用，502更偏向连接层故障，504更偏向处理层超时，但落实到动作上都是去查源站进程是否存在、资源是否充足、链路是否通畅。
一个值得留意的细节是，502有时是CDN节点主动生成的，当CDN节点与源站建连失败，同时CDN侧又配置了“失败时返回502”的响应策略，节点会直接构造502返回给用户，此时源站本身可能并没有接收到任何请求，这种场景下,排查方向要转向CDN节点状态与调度系统。
两个Q&A
502和504频繁出现时，最有效的第一步排查动作是什么？
直接去源站机器上看错误日志和访问日志，而不是先调CDN配置，具体操作是登录源站，打开Nginx错误日志，用tail -f观察实时输出，同时配合curl -I手动请求本地服务，判断源站自身是否正常，如果源站本地请求也报错，问题在源站；如果本地正常，再往CDN回源链路查，这一步能快速缩小故障范围,减少无效操作。
如果源站日志显示没有收到任何回源请求，但客户端一直在报502，怎么定位？
优先检查CDN控制台的回源IP配置和健康检查日志，源站没收到请求，说明请求根本没有到达源站，可能被CDN节点的缓存策略拦截、节点的回源鉴权失败或被WAF拦截规则命中，此时应查看CDN节点的请求日志，重点关注回源状态码和回源耗时字段，确认节点是否成功将请求转发到源站，同时检查CDN回源HOST配置是否与源站绑定的域名一致,这是最常被忽略的配置项。