服务器超时设置过长，本质上是替慢速攻击者免费延长了占用资源的许可，是慢速攻击得逞的关键帮凶。这意味着，当你把超时时间调到很宽泛时，等于亲手为攻击者敞开了大门，他们只需要极少的带宽,就能轻松拖垮你的服务器。
服务器超时时间设置多少合适？先明白它到底在防什么
超时时间是服务器耐心程度的唯一标尺
服务器与客户端之间的每一次数据交换，都建立在“连接”这条虚拟管道上，超时时间规定了管道两端在一段时间内必须完成沟通，否则就自动断开，业内人士常把超时设置比作守门员的耐心请求太久没动静，要么放行,要么强制清理。
这个机制的初衷是为了防止资源黑洞，即客户端建立连接后一直不发送数据，导致服务器线程被白白占着，合理设置能及时回收僵死连接，保障正常访客畅通无阻，但现实情况是，很多运维人员怕误伤正常用户，把超时时间调得异常肥大，从默认的30秒一路调到300秒甚至更大,这给慢速攻击架起了绝佳的温床。
多数情况下，超时设置从“防死”变成了“帮死”
慢速攻击的原理并不复杂：攻击者建立连接后，以极慢的速度发送数据，每次只发一个字节，或者间隔很久才发一次数据头，让服务器始终觉得连接“还活着”，只要你的超时时间足够长，服务器就只能痴痴地等待，庞大的连接池就这么被一点一点占满,真实用户再也挤不进去。
行业共识认为，服务器的资源是有限的，连接池是有限的，线程池也是有限的，当攻击者控制的僵尸主机数量足够多时，哪怕每台只占用一个连接，你的服务器也会因为等待而全面瘫痪，超时时间越长，攻击者的“合法占座”时间越久,防守方的翻身机会就越渺茫。
nginx服务器超时设置在哪改？动手调整前的必读清单
影响慢速攻击的关键指令不止一条
多数网站跑在Nginx环境下，调整超时设置并不是改一个数字那么简单，以下四条指令与慢速攻击的对抗息息相关，任何一条设置过长,都可能成为帮凶。
- client_body_timeout：控制读取客户端请求体的超时时间，慢速POST攻击就是死盯这个参数，攻击者每隔几分钟才发一点数据，让服务器永远处于“读取中”状态。
-
client_header_timeout
：控制读取请求头的超时时间，默认值通常为60秒，如果被调得过高，配合不完整的请求头,可以直接占满空闲连接。 - keepalive_timeout：控制长连接的空闲存活时间，这个参数服务于高并发场景下的复用，但同样会被攻击者利用,把空闲连接牢牢握在手里不释放。
- send_timeout：控制数据发送的间隔时间，攻击者如果故意不读取服务器响应内容,这个参数过长同样能造成资源积压。
推荐的服务器超时时间基线参考
| 参数名 | 保守默认值 | 慢速攻击防护推荐值 | 适用场景 |
|---|---|---|---|
| client_header_timeout | 60秒 | 10-15秒 | 常规网站业务 |
| client_body_timeout | 60秒 | 10-20秒 | 有表单提交的网站 |
| keepalive_timeout | 75秒 | 15-20秒 | 静态资源较多的站点 |
| send_timeout | 60秒 | 10-20秒 | 普通动态接口 |
业内专家指出，将Nginx的这些超时参数压缩到20秒以内，既能兼容正常网络波动，又能大幅压缩慢速攻击的生存空间，如果需要兼容弱网用户，可以通过调整TCP层参数弥补,而不应该只在应用层无脑放宽超时。
手把手设置命令，照着操作即可
调整Nginx超时设置，只需打开站点配置文件，通常位于/etc/nginx/nginx.conf或/etc/nginx/conf.d/目录下，找到http块或者对应的server块,插入以下内容：
http {
client_header_timeout 12s;
client_body_timeout 15s;
keepalive_timeout 18s;
send_timeout 12s;
# 限制单个连接请求速率，防止慢速拖拽
limit_req_zone $binary_remote_addr zone=flood:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;
}保存后执行nginx -t检查语法，再执行nginx -s reload平滑重载，这组参数能应对大多数慢速攻击场景，如果你的业务包含大文件上传，适当放宽client_body_timeout到30秒以内是合理的，但一定要配合请求体大小限制,避免一次超大上传拖垮进程。
慢速攻击防御方案对比：超时调优只是第一步，实战组合拳更重要
为什么只改超时时间不够？真实的慢速攻击远比想象中狡猾
超时调优相当于加固了门窗，但慢速攻击的变种层出不穷,最常见的乏敌手段包括：
- Slowloris：只发送不完整的HTTP请求头，不断用新请求头补充，但永远不发结尾的换行符,让服务器误以为请求还在传输中。
- Slow POST：声明一个超大Content-Length，然后用极慢的速度填写请求体，服务器为了接收完整数据,只能无限期等待。
- Slow Read：客户端正常发出请求，但故意极慢地读取响应数据，迫使服务器的发送缓冲区长期堆积,源站陷入半死不活的状态。
如果只把超时时间调低，面对上述攻击的第一波冲击，源站依然会抖动，需要把超时策略与并发限制、流量清洗结合起来。
从免费到付费，几套差异明显的防慢速攻击思路
| 防御思路 | 典型手段 | 适合对象 | 预算参考 |
|---|---|---|---|
| 纯应用层调优 | 修改超时参数、限制单IP连接数 | 小型个人站、低成本业务 | 0元，纯运维投入 |
| 中间件层加固 | 在LVS或HAProxy层丢弃不完整连接 | 中小规模企业站 | 防御方案费用通常在数千到数万不等 |
| 云厂商WAF清洗 | 接入云WAF或高防IP，由边缘节点判别慢速流量 | 电商、游戏、线上服务 | 慢速攻击防御价格取决于套餐包，便宜的几百元/月起步 |
值得提醒的是，自建防御最容易被“打穿”的环节，不是技术能力，而是运维精力，慢速攻击的发起端分布极广，单靠手工封禁IP根本不现实，如果公司业务对可用性要求高，建议优先选用带TCP层校验的云防护产品，它们能在协议栈层面直接识别并丢弃低速连接,完全不需要源站等超时时间到点才反应。
如何用一条命令快速识别慢速攻击特征
在调整超时时间之前，先确认你的服务器是不是正在被慢速攻击，在Linux服务器上执行以下命令,观察当前连接状态：
ss -ant | grep -E 'SYN_RECV|ESTAB' | wc -l再执行下面这条,统计各个IP的并发连接数：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | tail -20
如果发现单个或少数几个IP的并发连接数异常偏高，且连接长时间处于ESTABLISHED状态但网络流量并不大，大概率就是慢速攻击的早期信号，此时配合lsof -i :80查看请求占用情况，若发现大量连接发送了0.1KB级别的数据，请不要犹豫，立刻收紧该IP访问速率,或者直接将其封禁。
Q&A：服务器超时与慢速攻击，你还需要弄懂这几件事
调低超时时间真的会误伤正常用户吗？
不会，对于现代浏览器和移动App来说，TCP连接的建立速度在毫秒级，哪怕超时时间只有10秒，也远远大于正常用户发送请求的耗时。真正受影响的是弱网用户，例如地铁隧道、偏远地区等场景下网络延迟较高，这种情况下可以把client_body_timeout放宽到20秒，但必须同步启用limit_conn限制同一IP的连接数,防止攻击者利用宽超时开多线程占坑。
国内主流云厂商的服务器超时时间默认值是多少？
多数云服务器操作系统（如CentOS、Ubuntu）默认安装的Nginx，client_header_timeout与client_body_timeout均为60秒，简米云、酷番云、华为云的默认Web应用防火墙产品，在检测到慢速攻击时，一般会在5-10秒内强制切断恶意连接并返回503状态码，如果你购买的是高防IP服务，厂商通常会在接入层主动拦减慢速流量，不需要单独调整源站超时参数，但建议保持源站超时时间在30秒以内,实现纵深防御。
慢速攻击和DDoS攻击是一回事吗？
有本质区别，完整的DDoS攻击大多通过巨大的流量直接挤爆带宽或CPU，攻击目标是“淹没”；而慢速攻击走的全是低带宽，目标是耗尽服务器可用连接数，慢速攻击的隐蔽性远高于流量型DDoS，普通流量监控根本不会触发告警，因为总带宽占用可能只有几十Kbps，防御者的核心思路也完全不同，慢速攻击拼的是协议栈的健壮性,超时时间就是第一道也是最重要的一道防线。
把超时收缩到合理区间，等于拆掉了慢速攻击赖以生存的温床，超时参数越小，攻击者占坑的成本越高，源站承受的压力就越低，从今天开始，动手检查你的Nginx或Apache配置，给超时时间做一个“瘦身”手术,确保它不被别有用心的慢速请求绑架。