“110: connection timed out”不是安全漏洞而是网络错误，反映配置失当或资源瓶颈；需据场景区分偶发现象与慢速攻击，通过收紧nginx超时设置、调优内核参数及建立监控拦截闭环来防御。
“110: Connection timed out”本身不是安全漏洞，而是 Linux 内核层面的网络错误（ECONNREFUSED 的同类错误码），在 Nginx 日志中表现为 [error] ... client timed out (110: Connection timed out) while reading client request headers。它通常暴露的是配置失当、资源瓶颈或潜在的慢速攻击面，而非直接可利用的安全漏洞。但若长期存在且未干预，会间接放大风险——比如被用于耗尽连接池、掩盖真实攻击、或拖垮服务可用性。
确认是否真为安全隐患
先区分场景：
- 偶发少量 408 错误 + 正常业务流量：大概率是客户端网络差、移动弱网重传失败，属常规现象；
- 大量集中出现 + client_header_timeout 触发 + 源 IP 高度分散或固定：需警惕慢速 HTTP 攻击（如 Slowloris）；
- 错误集中在特定路径或 User-Agent：可能是爬虫、扫描器或异常 SDK 行为，需结合访问日志分析。
收紧请求头接收策略
这是防御慢速攻击最直接有效的手段。Nginx 默认 client_header_timeout 60s 过长，给恶意客户端留足“滴答式”发送时间。
- 将
client_header_timeout降至 5–15 秒（多数正常客户端可在 1 秒内完成 header 发送）； - 同步设置
client_body_timeout为相同值，防止 POST 大体缓慢上传； - 启用
reset_timedout_connection on;，让超时连接立即释放 TCP 资源，不进入 TIME_WAIT； - 限制单个连接最大请求数：
keepalive_requests 100;，避免长连接被复用滥用。
强化系统级连接防护
Nginx 层控制只是第一道防线，Linux 内核参数决定底层抗压能力：
- 调小 TCP SYN 队列：修改
/proc/sys/net/ipv4/tcp_synack_retries为 2–3，加快丢弃无效握手； - 启用 syncookies：
net.ipv4.tcp_syncookies = 1，抵御 SYN Flood； - 缩短 TIME_WAIT 回收：
net.ipv4.tcp_fin_timeout = 30，配合net.ipv4.tcp_tw_reuse = 1（仅对客户端有效）； - 增大连接队列上限：
net.core.somaxconn = 65535和net.core.netdev_max_backlog = 5000。
监控与主动拦截
光靠调参不够，必须建立可观测闭环：
- 开启
ngx_http_stub_status_module，监控Reading状态连接数突增（典型慢速攻击特征）； - 用
fail2ban或自定义脚本解析 error.log，对 5 分钟内触发 >10 次 408 的 IP 自动封禁； - 在 WAF 或前置 LB 层部署速率限制（如每 IP 每秒最多 3 个新建连接），从源头过滤异常建连行为。
