流量突然增加时，连接失败不一定是“队列太小”：客户端可能在服务端处理前超时，应用也可能来不及接收已建立的连接。TCP并发耗尽防护下的连接超时与队列参数，需要结合并发规模、请求耗时和突发形态一起看；只延长超时或扩大队列，反而可能让资源被占用更久。
先分清连接在哪一层排队
Linux 监听端口涉及两类常被混淆的队列。SYN 队列保存尚未完成握手的连接状态；accept 队列则等待应用调用 accept() 接收已经建立的连接。应用处理线程不足时，后者可能堆积；握手流量异常或突发过猛时，前者更值得关注。两者的容量和成因不同，不能用一个 backlog 数值解决所有问题。
查看监听状态可使用 ss -lnt，重点关注 Recv-Q 与 Send-Q，并结合 ss -s、应用日志和主机资源指标观察趋势。监听 socket 的队列上限还会受到应用设置及 Linux 的 net.core.somaxconn 等参数约束；SYN 队列则受相关内核设置和系统行为影响。调大其中一个上限，不代表实际处理能力同步增加。
超时要按连接阶段分别设定
连接建立超时
连接超时决定客户端或代理愿意等待多久完成建连。以 Nginx 的 proxy_connect_timeout 为例，同一局域网内的服务通常可以采用较短等待时间；跨区域或链路质量不稳定时，过短设置会增加误判。可以先从约 1—5 秒的范围评估，但应依据网络往返时延、重试策略和业务容忍度验证，不应把它当作通用标准。
请求读取与空闲超时
读超时通常限制等待上游数据或连续数据间隔的时间，并不总等于整个请求的最长执行时间。长轮询、流式响应和普通短请求的合理值差异明显。空闲连接超时也要与客户端重用连接的方式协调：设得过长会占用文件描述符和连接状态，设得过短则可能增加重新建连。TCP keepalive 用于探测部分失效连接，不能替代应用层请求超时。
按负载证据调整，而不是先放大参数
- 建立基线：记录连接数、连接建立失败、请求延迟分位数、应用线程或协程占用、文件描述符使用量，以及 Recv-Q 的变化。
- 定位瓶颈：若 accept 队列持续接近上限，同时应用接收或处理能力不足，先检查工作线程、连接池和下游依赖；若队列仅在短暂流量尖峰出现，评估峰值持续时间与应用恢复速度。
- 分项调整：先依据业务时延预算设置连接与读超时，再检查应用监听 backlog、内核上限和实际队列状态。队列上限可从当前值逐级提高并观察，避免一次设到很大却掩盖处理能力不足。
- 重复验证：在接近预期峰值的压测或受控流量下，观察队列是否快速回落、失败率和延迟是否改善，同时检查内存、文件描述符及下游连接是否承压。修改前后保持其他条件尽量一致。
TCP并发耗尽防护下的连接超时与队列参数，最终要匹配系统能接收和完成连接的速度。队列负责吸收有限的瞬时波动，超时负责限制等待与资源占用；两者都不能替代容量规划和应用侧限流。
常见问题
队列越大，连接失败就越少吗？
不一定。更大的队列能缓冲短时突发，但若应用长期处理不过来，等待时间和资源占用会增加，超时仍可能发生。
提高连接超时能保护服务吗？
通常不能单独起到保护作用。它可能减少网络抖动导致的误失败，也可能让请求和连接占用更久，应结合并发上限及请求时限设置。
改完参数后看什么指标？
至少观察监听队列、连接错误、请求延迟、活跃连接数和应用资源使用情况，并确认短时峰值后队列能够回落。
