Dropped 指 TCP 连接建立阶段因 accept 队列溢出被内核拒绝的真实连接，由 nginx backlog 与系统 somaxconn 较小值共同限制，反映高并发下服务稳定性瓶颈。
“丢弃请求数（Dropped）”在 Nginx 监控中不是指 HTTP 层的 4xx/5xx 错误，而是底层 TCP 连接建立阶段因队列溢出导致的真实连接拒绝——它直接关联系统 backlog 配置是否合理，是高并发下服务稳定性的关键信号。
什么是 Dropped：来自内核的连接拒绝
当客户端发起 TCP 连接（SYN），服务端完成三次握手后，需将已建立的连接（ESTABLISHED 状态）放入 accept 队列（也称全连接队列）。Nginx 的 accept() 调用从该队列取连接。若队列已满，内核会直接丢弃新到达的 ACK 包，并向客户端返回 ECONNREFUSED（即 “Connection refused”）。这类被拒连接就会计入 Dropped。
可通过以下命令确认是否发生：
netstat -s | grep -i "listen\|drop"
典型输出如：
62678 times the listen queue of a socket overflowed<br>65640 SYNs to LISTEN sockets dropped
注意：第二行“SYNs dropped”实际是 accept 队列溢出的连锁反应——因为 accept 队列长期满载，导致半连接队列（SYN queue）也间接溢出，最终丢弃新 SYN。
backlog 参数到底控制什么
Nginx 的 listen ... backlog=N 设置，仅影响单个 listen 套接字的 accept 队列长度上限，但真正生效的队列大小由两个值中的较小者决定：
- Nginx 配置的
backlog值（例如listen 80 backlog=8192;） - 系统内核参数
/proc/sys/net/core/somaxconn（默认常为 128 或 4096）
也就是说，即使 Nginx 设了 65535，若 somaxconn=1024，实际队列最大仍只有 1024。而半连接队列（SYN queue）则由另一参数 tcp_max_syn_backlog 控制，它不直接受 Nginx 影响，但对整体抗压能力至关重要。
如何定位和优化 Dropped 高的问题
持续增长的 Dropped 数，说明 accept 队列频繁溢出。常见原因和对应动作如下：
-
应用处理太慢：worker 进程繁忙、阻塞式 accept、或业务逻辑耗时长导致来不及调用
accept()。可检查nginx -V是否启用--with-http_realip_module等重型模块，或是否存在未配置multi_accept on导致单次只取一个连接 -
backlog 配置偏低：Nginx 的
backlog值小于somaxconn，或两者都远低于当前并发连接建立速率。建议设为 8192～32768，并同步调整内核：echo 32768 > /proc/sys/net/core/somaxconnecho 65535 > /proc/sys/net/ipv4/tcp_max_syn_backlog - 瞬时流量尖峰：如秒级数万连接涌入，即使队列够大也可能短暂溢出。此时需结合限流（limit_conn）、连接复用（keepalive_timeout）、以及上游负载均衡调度策略共同缓解
验证改动是否生效
修改后，用 ss -lnt 查看监听套接字的 Recv-Q 列（即当前 accept 队列积压数）：
State Recv-Q Send-Q Local Address:Port Peer Address:Port<br>LISTEN 0 8192 *:80 *:*
其中 Recv-Q 显示当前排队连接数，Send-Q 即为该套接字实际生效的 backlog 上限（此处为 8192）。若该值长期接近上限，且 netstat -s 中 overflow 持续增加，说明仍需进一步调优。
