直接调大 net.core.somaxconn 并同步应用层 backlog 设置是解决“511 报错”的根本方法，需先用 ss 和 netstat 确认队列真实溢出，再临时验证、永久配置并调优配套参数。

直接调大 net.core.somaxconn 是解决“511 报错”（如 Nginx 日志中 listen queue of socket ... full 或 accept() failed (111: Connection refused)）最直接有效的手段，但必须同步匹配应用层 backlog 设置，否则内核放宽了也没用——实际队列仍被卡在应用默认值上。

先确认是不是真溢出

别一看到 511 就改参数，先查真实状态：

• 运行 ss -lnt | grep :端口，看目标监听行的 Send-Q（队列上限）和 Recv-Q（当前积压数）。例如显示 0 511 *:80，说明上限是 511；若长期出现 511 511，就是队列持续满载
• 执行 netstat -s | grep -i "listen overflows"，如果数值在增长，代表内核已开始丢连接
• 检查服务日志：Nginx 常见报错是 listen queue of socket ... full；uWSGI 是 listen queue overflow；Java 应用可能表现为上游超时或连接拒绝

临时调大验证效果

快速验证是否有效，不需重启服务：

• 执行 sudo sysctl -w net.core.somaxconn=4096（建议从 4096 或 8192 起步）
• 再运行 sysctl net.core.somaxconn 确认已更新
• 注意：这只是内核层面放开限制，Nginx、Tomcat、Go 等仍按自己默认 backlog 启动，所以此时 ss -lnt 的 Send-Q 可能还是 511 —— 这正说明下一步必须改应用配置

永久生效并同步应用层 backlog

改完内核参数后，必须让应用真正用上这个新上限：

• 编辑 /etc/sysctl.conf，追加：
  net.core.somaxconn = 65535
  然后运行 sudo sysctl -p 加载
• Nginx：在 listen 指令后显式加 backlog=65535，例如 listen 80 backlog=65535;
• Tomcat：修改 server.xml 中 Connector 的 acceptCount="65535"
• uWSGI：启动时加 --listen 65535 参数
• Node.js：server.listen(port, host, 65535) 第三个参数即 backlog
• 改完务必重启对应服务，再用 ss -lnt | grep :端口 确认 Send-Q 已变成 65535

顺带调好配套参数防新瓶颈

只动 somaxconn 容易把压力转移到其他队列：

• net.ipv4.tcp_max_syn_backlog：控制半连接队列（SYN 队列），建议设为与 somaxconn 相同，如 65535
• net.core.netdev_max_backlog：网卡收包队列，高并发时建议 ≥ 262144
• net.ipv4.tcp_abort_on_overflow = 1：全连接队列溢出时发 RST 而非静默丢 ACK，能更快释放恶意连接
• net.ipv4.tcp_syncookies = 1：作为突发流量兜底，避免 SYN 包直接被丢弃