核心要点（TL;DR）
- nginx 502 先看 error.log 报错类型，再判断是上游故障还是流量攻击。
- upstream timed out 多为后端慢或连接池耗尽，connection reset 常见于恶意短连接。
- ss 与 netstat 统计单 IP 连接数，是定位异常流量来源最快的手段。
- 限流与连接数限制只能缓解，根治需在边界层做流量清洗与封禁。
凌晨收到告警：站点大面积 502，重启 nginx 无效，后端进程还在。这类场景里，502 往往不是 nginx 本身坏了，而是上游不可用或流量异常。本文按「先看日志、再查连接、后抓流量」的顺序，给出可直接复制执行的排查步骤，帮你在最短时间内恢复服务并锁定攻击源。
一、先分清 502 的三种典型成因
nginx 返回 502 的本质是「无法从 upstream 拿到有效响应」，常见三类：
- 上游超时：后端处理慢，超过 proxy_read_timeout，日志出现
upstream timed out。 - 连接耗尽：后端连接池或文件句柄打满，出现
connect() failed (110: Connection timed out)。 - 恶意流量：大量短连接或高频请求打满 worker 连接，日志伴随
connection reset by peer、recv() failed。
三者处置方式完全不同，先定性再动手，避免盲目重启扩大故障面。
二、从 error.log 定位第一现场
直接过滤最近报错并按类型聚合：
tail -n 5000 /var/log/nginx/error.log | awk -F': ' '{print }' | sort | uniq -c | sort -rn | head -20重点看三类关键字：
upstream timed out：查后端响应时间与超时配置。no live upstreams：后端健康检查全部失败，确认后端是否真的挂了。worker_connections are not enough：连接数被打满，高度怀疑异常流量。
同时统计 access.log 高频来源：
awk '{print }' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20若 Top IP 请求量达到正常用户的数十倍，基本可判定为攻击或爬虫滥用。
三、用连接状态确认是否被打穿
执行 ss -s 看总量，再用下面命令按 IP 聚合：
ss -antp | awk 'NR>1{print }' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20判断标准：
| 现象 | 可能原因 | 处置方向 |
|---|---|---|
| TIME_WAIT 激增 | 大量短连接扫描或 CC | 限流、封禁、开启 keepalive |
| ESTAB 集中在少数 IP | 连接型攻击 | limit_conn 限制单 IP |
| SYN_RECV 偏高 | SYN Flood | 边界清洗、内核参数调优 |
必要时用 tcpdump -i eth0 -nn host <可疑IP> -c 200 抓包，确认请求特征与 UA。
四、分步处置：先止血再根治
- 临时封禁：
iptables -I INPUT -s <IP> -j DROP，或写入 nginx deny 规则。 - 开启限流：在 http 段配置
limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;，location 内加limit_req zone=req burst=20 nodelay;。 - 限制连接数：
limit_conn_zone $binary_remote_addr zone=conn:10m;配合limit_conn conn 20;。 - 核对后端参数：确认 proxy_connect_timeout、proxy_read_timeout 与后端最大连接数匹配，避免误判。
- 边界层防护：单机规则难以应对分布式 IP 池，可在流量入口启用 AegisX 的异常流量识别与 IP 信誉封禁能力，把清洗动作前移，减少源站压力。
五、恢复后的检查清单
- error.log 与 access.log 样本已留存，攻击特征已记录。
- 限流与连接数规则已生效并观察误伤情况。
- 后端超时、连接池、文件句柄上限已复核。
- 监控告警阈值已调整，覆盖连接数与 5xx 比例。
- 本次事件已纳入应急预案，明确封禁与升级流程。
行动建议：下次遇到 502，先执行「日志聚合 + 连接统计」两条命令定性，再决定是修后端还是封流量；把限流规则提前写入配置模板，比故障时临时加规则更可靠。
常见问题（FAQ）
nginx 出现 502 但后端服务看起来正常，是什么原因？
优先怀疑连接池与超时配置不匹配。检查 error.log 是否出现 upstream timed out 或 connect() failed，确认后端最大连接数、worker 进程数与 keepalive 设置是否过小；同时用 ss -s 观察 TIME_WAIT 数量，若短时间内激增，说明存在大量短连接，可能是扫描或 CC 攻击而非后端故障。
如何快速判断 502 是攻击导致还是程序故障？
看两个指标即可初判：一是 error.log 报错是否集中在同一时段且伴随大量 connection reset by peer，二是 access.log 中单 IP 请求频率是否远超正常用户。若单 IP 每分钟数百次请求且 UA 异常，基本可判定为恶意流量；若报错分散且后端 CPU 打满，则更可能是程序性能问题。
排查异常流量时最常用的命令有哪些？
常用组合是 ss -antp 查看连接状态与进程、ss -s 汇总连接数、netstat -anp 按 IP 排序统计、tcpdump 抓包确认报文特征，以及 awk 统计 access.log 中高频 IP 与 URL。建议先用一条命令按 IP 聚合排序，快速锁定 Top 来源，再针对性抓包验证。
nginx 限流配置能挡住 CC 攻击吗？
只能缓解不能根治。limit_req 与 limit_conn 可以有效压制单 IP 高频请求，但对分布式代理 IP 池效果有限，且配置过严会误伤正常用户。建议把限流作为兜底手段，同时在边界层做流量清洗、IP 信誉封禁与行为特征识别，形成分层防护。
502 恢复后还需要做什么？
必须做复盘与加固。保留 error.log 与 access.log 样本，记录攻击源 IP 段与请求特征，补充限流规则与监控告警阈值，检查后端超时与连接池参数是否合理，并将本次事件加入应急预案，避免同类流量再次打穿服务。