net.ipv4.tcp_tw_reuse仅对客户端新出站连接有效，需tcp_timestamps=1配合，服务端无效；ss -i的retrans非累计值；somaxconn与应用backlog取最小值；UDP丢包因无socket或缺SO_REUSEPORT。

为什么 net.ipv4.tcp_tw_reuse 开启后连接仍超时？

因为该参数只对客户端有效，且仅在 TIME_WAIT 状态套接字可被复用于**新 outbound 连接**（即本机主动发起的连接），不适用于服务端接收连接或被动关闭场景。常见误用是把它当成“解决端口耗尽万能开关”，但实际需配合 net.ipv4.tcp_fin_timeout 和连接池策略。

• 必须确保 net.ipv4.tcp_timestamps = 1 已启用，否则 tcp_tw_reuse 不生效
• 若应用使用短连接且并发高（如 HTTP client 频繁调用 API），建议同时调小 net.ipv4.tcp_fin_timeout 至 30 秒以内
• 服务端（如 Nginx、Redis）无法靠此参数缓解 TIME_WAIT 压力，应改用连接复用（keepalive）或反向代理层做连接收敛

如何让 ss -i 显示真实重传与拥塞窗口信息？

ss -i 默认输出中 retrans 字段为 0 并不表示无重传——它只显示当前连接最近一次重传事件的计数，且需内核开启 TCP info 支持。要获取稳定可观测数据，得结合 /proc/net/snmp 和 tcpretrans 工具。

• 检查是否启用详细 TCP 统计：cat /proc/net/snmp | grep -A1 Tcp | tail -1，看 RetransSegs 是否持续增长
• ss -i dst 8.8.8.8 只能观察单条连接瞬时状态；批量诊断请用 tcpretrans -C（来自 perf-tools 包）
• 若 cwnd 长期卡在 10 MSS 以下，大概率是链路丢包或接收方通告窗口过小，而非本机配置问题

net.core.somaxconn 和应用 listen() 的 backlog 参数谁起作用？

两者共同限制全连接队列长度，最终生效值取二者最小值。很多服务（如 Nginx、Node.js）默认 backlog 设为 511，若系统 net.core.somaxconn 仍为旧版默认值 128，就会 silently 截断连接请求，表现为偶发性 “Connection refused” 或 SYN_RECV 滞留。

• 先确认当前值：sysctl net.core.somaxconn，生产环境建议设为 65535
• Nginx 需显式配置 listen 80 backlog=65535;；Node.js 的 server.listen(port, cb) 第二个参数可传 backlog 数值
• 修改后必须重启对应服务进程，仅 reload 不生效（因 listen() 在进程启动时调用）

UDP 应用丢包但 netstat -su 显示 no socket 错误？

这说明数据包到达了 IP 层，但找不到匹配的 UDP socket——常见于端口未监听、进程已崩溃、或 bind() 时未设 SO_REUSEPORT 导致多 worker 场景下部分包被内核丢弃。

• 用 ss -uln | grep :端口号 确认端口确实在监听，注意 ss 输出中的 State 列应为 UNCONN
• 若使用多进程/线程模型（如 Gunicorn + UDP handler），必须在每个进程 bind 前设置 SO_REUSEPORT，否则仅第一个进程能收包
• netstat -su 中的 no socket 计数不会自动清零，需对比前后差值判断是否持续发生

#!/bin/bash
# 快速检查关键网络参数是否就绪
for p in net.core.somaxconn net.ipv4.tcp_tw_reuse net.ipv4.tcp_timestamps; do
    v=$(sysctl -n $p 2>/dev/null)
    echo "$p = $v"
done
echo "TCP retransmit segments: $(awk '/Tcp:/ {print $13}' /proc/net/snmp 2>/dev/null)"

真正影响稳定的不是单个 sysctl 调优，而是连接生命周期各环节的协同：TIME_WAIT 处理方式是否匹配你的客户端/服务端角色，全连接队列是否被低估，UDP 多实例是否正确启用 SO_REUSEPORT。这些点一旦错位，再精细的拥塞控制参数也压不住丢包。