要确认 limit_conn 是否真正重置连接，需抓包验证 tcp rst 包、检查错误日志中“limiting connections by zone”记录，并通过 ss 命令观察 inuse 连接数是否被压制且 orphan 上升。
要观察 limit_conn 触发后是否真正重置连接（而非仅返回错误响应），关键不是看 HTTP 状态码，而是确认 TCP 层面的连接被主动拒绝或关闭——即客户端收到 RST 包或连接直接失败。这需要从网络行为、日志信号和系统状态三方面交叉验证。
抓包确认 RST 是否真实发出
在 Nginx 服务器上用 tcpdump 捕获目标端口（如 80/443）的流量，同时发起超限并发请求：
tcpdump -i any 'port 80 and (tcp-rst or tcp-syn)' -nn -w limit_conn_rst.pcap- 用
hey -c 20 -n 100 -disable-keepalive http://your-domain.com/发起短连接压测（避免复用） - 回放 pcap 文件，筛选出源为客户端 IP、目的为 Nginx 的
TCP RST包：若存在大量 RST 响应（尤其在 SYN 阶段未完成三次握手时），说明 Nginx 已在连接建立前就拒绝，属于“连接重置”；若只有 ESTABLISHED 后返回 503，则只是应用层拒绝，未重置连接
检查错误日志中的精确触发标识
Nginx 错误日志中出现特定关键词，是连接被限流模块拦截的直接证据：
- 运行
tail -f /var/log/nginx/error.log，看到类似limiting connections by zone "addr", client: 192.168.1.100的记录，表示limit_conn模块已介入 - 若配置了
limit_conn_log_level notice，该日志会以notice级别输出，比默认error更易捕获 - 注意：没有这条日志，即使返回 503，也不能断定是
limit_conn触发的——可能是其他模块（如limit_req）或 upstream 故障
对比 ss 统计与 worker_connections 设置
系统级连接数是否被有效压制，是判断“重置是否生效”的硬指标：
- 先查 Nginx 配置：确认
worker_processes × worker_connections总值（例如 4×1024 = 4096） - 压测中执行
ss -s | grep "TCP:"，观察inuse和orphan数值：若inuse稳定在远低于总值的水平（如卡在 10 左右），且orphan显著上升（表示连接被快速释放），说明连接未堆积，重置机制起效 - 反例：若
inuse随压测线性增长并逼近上限，说明连接未被及时切断，limit_conn可能未生效或 key 设置不合理（如用了$remote_addr而非$binary_remote_addr）
客户端侧验证连接失败类型
不同失败表现对应不同底层行为，可辅助判断：
- 使用
curl -v http://x.x.x.x/或telnet x.x.x.x 80手动测试：若立即报Connection refused，说明端口未监听或防火墙拦截；若卡住几秒后报Empty reply from server或Connection reset by peer，才是limit_conn主动发送 RST 的典型特征 - 用 Python 简单脚本批量建连，捕获异常类型：
ConnectionResetError对应 RST，TimeoutError或ConnectionRefusedError则需排查其他环节
