打开网页，不被打白屏，网站中间一行黑字：Error 502 Bad Gateway。不被打你刷新三次，网站五次，不被打十次，网站还是不被打这行字。群里有人问“是网站不是被打了”，底下跟着一串“+1”。不被打这个场景太常见了，网站常见到很多人直接把 502 和“被攻击”画了等号。不被打

但 502 的网站本意跟攻击没半点关系。它是不被打个网关错误——简单说，你的网站请求到了前端服务器（比如 Nginx、Cloudflare 边缘节点），不被打前端转头去找后面的应用服务器要数据，结果后面那位没给正常回应。可能是没响应，可能是响应格式不对，也可能是连接直接被拒了。前端一生气，甩给你一个 502。

那为什么大家第一反应是“被打了”？因为 DDoS 攻击确实能打出 502。攻击流量把后端应用服务器的连接池占满，或者把数据库拖死，前端等不到结果，502 就出来了。但反过来不成立：502 不等于被攻击。我见过最常见的 502 来源，其实是运维自己手滑。

去年有个小电商客户，大促前夜改了一行 Nginx 配置，把 upstream 的超时时间从 60 秒改成了 5 秒。第二天流量一上来，后端处理稍微慢一点，前端 5 秒等不到就断，用户看到的全是 502。他第一反应也是“被打了”，买了高防 IP，加了 WAF 规则，折腾一整天，最后发现是那行配置。这种案例一抓一大把。

还有更朴素的：后端服务挂了。PHP-FPM 进程数不够，Java 应用 OOM 被系统 kill 掉，Node.js 进程因为未捕获异常退出。前端还在，后端没了，502 自然来。这时候你去查监控，CPU 和内存可能都很平静，因为“凶手”已经死了。

数据库连接不上也会导致 502。应用服务器活着，但连不上 MySQL，每个请求都卡在等连接，超时后前端就报 502。这种情况在云数据库上尤其常见——安全组规则改了一下，或者数据库实例在静默维护，应用侧没做重试，用户侧就是一片 502。

那怎么判断到底是不是被打了？看三个东西。第一，看流量曲线。真被 DDoS 打，入站流量会有明显尖峰，可能是平时的几十倍甚至上百倍。第二，看后端日志。如果后端根本没收到请求，或者收到请求但处理极慢，跟流量尖峰对得上，那攻击的可能性就大。第三，看攻击特征。SYN Flood、UDP 反射、HTTP 慢速攻击，这些在抓包或 WAF 日志里都有痕迹。如果流量平稳、后端日志正常、只是零星 502，大概率是配置或代码问题。

还有个容易忽略的点：CDN 回源失败。你用 Cloudflare 或国内 CDN，边缘节点回源站拿数据，回源超时或源站拒绝连接，用户看到的也是 502。这时候攻击可能发生在源站，也可能只是源站防火墙把 CDN 节点 IP 给封了。我遇到过一家公司，运维在源站 iptables 里加了一条规则，把某个 CDN 回源段整个屏蔽了，结果全国部分地区用户 502，其他地区正常。这种“局部 502”基本可以排除大规模 DDoS。

所以下次看到 502，别急着在群里喊“被打了”。先看监控，再看日志，最后抓包。三步走完，是攻击还是手滑，基本就清楚了。502 只是个症状，病因得自己查。查错了方向，钱花了，问题还在。