发现并防御http慢速连接攻击需主动监控异常连接模式：重点分析nginx超时日志（header/body/read三类）、stub_status连接状态分布、access_log请求节奏，并通过curl/python模拟验证配置实效性。
发现并防御 HTTP 慢速连接攻击，关键不是等告警才行动，而是用监控数据主动识别异常连接模式——尤其是那些“连得上、发得慢、不结束”的连接行为。
看连接生命周期：重点盯三类超时日志
Slowloris 类攻击的核心特征是连接长期卡在某个处理阶段。Nginx 默认会在 error_log 中记录超时事件，这是最直接的线索：
-
client timed out (read header)：对应
client_header_timeout触发，说明有连接在发头部时拖太久——典型 Slow Headers -
client timed out (reading client request body)：对应
client_body_timeout触发，说明声明了大 Content-Length 却迟迟不传完——典型 Slow Body -
client timed out (sending response)：对应
send_timeout触发，说明响应已生成但客户端读得太慢——典型 Slow Read
建议在 log_format 中加入 $request_time 和 $upstream_response_time，再用 ELK 或 Prometheus + Grafana 聚合统计每分钟超时类型分布。若某 IP 在 1 分钟内触发 >5 次 header 超时，基本可判定为攻击源。
查连接状态分布：用 stub_status 或 nginx-module-vts
Nginx 自带的 stub_status（需编译启用）或第三方模块 nginx-module-vts 可实时暴露连接状态：
- Active connections 持续高位且 Reading 数值异常高（远超 Writing/Waiting）：说明大量连接卡在接收请求头或体阶段
- Waiting 长期接近 worker_connections 上限：可能被 Slow Read 占满，客户端不读响应却维持连接
- 配合
limit_conn日志，观察单 IP 的limit_conn拒绝次数突增，也是强信号
可在 Prometheus 中配置 exporter 抓取这些指标，设置告警规则：当 nginx_connections_reading > 80% of worker_connections 并持续 2 分钟，即触发预警。
验真实请求节奏：用 access_log 分析请求间隔与速率
攻击者发包节奏高度规律（如每 10 秒一个 User-Agent 字段），而正常用户是突发性、非周期性的。通过增强 access_log 记录关键字段：
log_format slowlog '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time $connection_requests';- 用脚本或日志分析工具（如 GoAccess、Logstash）统计同一 IP 的请求时间戳间隔
- 筛选出
request_time > 5s且$connection_requests == 1（首次请求就超时）的条目 - 对高频低速 IP，检查其
$request是否总以GET / HTTP/1.1开头但无完整头，或 POST 请求中Content-Length很大但body_bytes_sent极小
这类模式一旦在 5 分钟窗口内出现 ≥10 次，即可自动加入临时封禁名单（如通过 fail2ban 或 Nginx 的 map + deny）。
联动配置验证：监控是否真正生效
配了超时参数不等于防御落地。必须验证实际行为是否符合预期：
- 用
curl -v --limit-rate 10 http://your-site/模拟慢速头，确认 10 秒内返回 408 而非卡住 - 用 Python 脚本模拟 Slow Body：发送
Content-Length: 10000000后每 15 秒发 1 字节，观察连接是否在client_body_timeout内断开 - 检查
netstat -ant | grep :80 | awk '{print $6}' | sort | uniq -c | sort -nr，确认 ESTABLISHED 连接数未因长连接堆积失控
若监控显示超时日志极少，但 Active connections 持续飙升，说明超时值设得过大或 reset_timedout_connection off 导致连接未真正释放——这时要立刻调整。
