在 CentOS 中，backlog 通常指内核与应用程序用于暂存待处理连接的队列长度。要“减少”它，可以从两方面入手：一是降低内核允许的队列上限，二是降低具体服务在 listen() 时声明的队列长度。注意：盲目减小可能导致新连接被丢弃或超时，通常仅在明确需要限制突发连接或受资源约束时才这么做。
一、先确认当前 backlog 的实际值
- 查看系统最大全连接队列上限：cat /proc/sys/net/core/somaxconn（常见默认值为128）。
- 查看半开连接（SYN 队列）上限：cat /proc/sys/net/ipv4/tcp_max_syn_backlog。
- 查看各监听端口的实际队列设置与当前排队情况：ss -lnt | column -t（关注 Recv-Q 与 Send-Q；对监听套接字，Send-Q 通常显示该监听套接字的 backlog 配置值）。
- 如需定位监听套接字的配置来源，检查具体服务的配置文件或启动参数中的 listen(…, backlog) 值。
以上命令与含义适用于 CentOS 7/8/Stream 等常见版本。
二、降低内核与设备层队列上限
- 临时降低（立即生效，重启后失效）：
- 降低全连接队列上限：echo 128 | sudo tee /proc/sys/net/core/somaxconn
- 降低半开连接队列上限：echo 128 | sudo tee /proc/sys/net/ipv4/tcp_max_syn_backlog
- 降低网卡接收队列上限：echo 1000 | sudo tee /proc/sys/net/core/netdev_max_backlog
- 永久降低（写入 sysctl 配置）：
- 编辑 /etc/sysctl.conf 或 /etc/sysctl.d/99-backlog.conf，按需写入更小的值，例如：
net.core.somaxconn = 128
net.ipv4.tcp_max_syn_backlog = 128
net.core.netdev_max_backlog = 1000
- 使配置生效：sudo sysctl -p
说明：上述“128/1000”为常见默认值示例，你可以根据业务容忍度设置得更低，但过小会显著增加连接失败与超时。
三、降低应用程序的 listen backlog
- 通用思路：在服务的配置或启动脚本中，将 listen(…, backlog) 的参数调小到你期望的上限。该值受内核的 somaxconn 限制，实际生效值会被截断为不超过 somaxconn。
- 常见服务的示例做法：
- Nginx：在 nginx.conf 的 events/http 段使用 backlog=128; 并重启。
- Redis：在 redis.conf 设置 tcp-backlog 128，重启服务。
- Tomcat/Jetty/Node.js/Go：在对应应用或反向代理（如 systemd 服务 ExecStart 前的参数、或应用配置）中显式设置较小的 backlog。
示例（示意）：ss -lntp | grep 80 可验证修改后监听套接字的 Send-Q 是否变小。
四、验证与风险提示
- 验证：
- 观察队列是否变小：ss -lnt | column -t（监听套接字的 Send-Q 接近你设置的 backlog）。
- 观察连接行为：在压测或突发流量下，若出现连接超时/拒绝增多，说明 backlog 过小或应用 accept 能力不足。
- 风险提示：
- 过小的 backlog 会在突发流量时导致新连接被丢弃或 connect 超时，通常应先优化应用的 accept 与处理能力，再考虑是否降低队列。
- 若目的是缓解 SYN Flood 等攻击，更稳妥的做法是保持或提高内核队列上限，并启用如 tcp_syncookies 等机制，而不是单纯减小队列。
- 调整前建议在测试环境验证，并逐步变更，配合监控告警与回滚预案。