Nginx 本身不“防爬虫”，但不合理超时配置会让爬虫（尤其是慢速攻击类）轻易耗尽 worker 连接，导致服务不可用；关键不是堵爬虫，而是让无效连接快速释放——读写超时就是最有效的“断连开关”。
直接说结论：Nginx 本身不“防爬虫”，但不合理超时配置会让爬虫（尤其是慢速攻击类）轻易耗尽 worker 连接，导致服务不可用。关键不是堵爬虫，而是让无效连接快速释放——读写超时就是最有效的“断连开关”。
client_header_timeout 和 client_body_timeout：防弱网误杀，也防 Slowloris
这两个参数决定 Nginx 等待客户端发完请求头和请求体的“耐心程度”。
- 普通网页（HTML/CSS/JS/小图）：设为 10s 即可。用户弱网卡顿一般不会超 10 秒，设太长反而给 Slowloris 留空子
- 含文件上传的后台（如 Flask Admin、Django Admin 表单）：client_header_timeout 设 30s（覆盖 TLS 握手+代理重传），client_body_timeout 设 300s（5 分钟够传百 MB 文件）
- 移动端 API 接口：统一设 60s，避免因蜂窝网络抖动或中间 CDN 重传触发 header 超时
注意：client_body_timeout 不是整个上传耗时上限，而是两次 TCP 数据包之间的最大空闲时间。断续上传只要每段间隔 ≤60s 就不会中断。
proxy_read_timeout 和 proxy_send_timeout：匹配 Python 后端真实响应节奏
这是反向代理场景下最关键的两个超时，直接影响 Flask/FastAPI/Django 是否被“假杀”。
立即学习“Python免费学习笔记（深入）”；
- 先实测后端 P95 响应时间：用
curl -w "@format.txt" -o /dev/null -s http://localhost:8000/api/xxx测真实延迟，再加 20% 余量 作为 proxy_read_timeout - 例如后端 P95 是 4.2s → 设为 5s；报表类接口 P95 是 78s → 设为 95s
- proxy_send_timeout 设 60s 足够。它极少触发，只在后端进程卡死、拒绝接收请求时起作用，不必比 read 更大
- 若后端支持流式响应（如 SSE、实时日志）、长轮询，proxy_read_timeout 必须设大（如 3600）并配
proxy_buffering off
send_timeout 和 keepalive_timeout：控制响应发出与连接复用寿命
这两个参数管的是“发给用户”的最后环节，常被忽略却极易引发连接堆积。
- send_timeout：Nginx 向浏览器写响应时，两次成功 write 的最大间隔。默认 60s，建议调低至 30s。防止用户端网络卡住、只收一半响应却长期占着连接
- keepalive_timeout：HTTP/1.1 长连接空闲多久关闭。静态资源多可设 60–120s；纯 API 服务建议 15–30s，减少空闲连接积压
- 务必配合 keepalive_requests 100（默认值），避免单连接无限复用，造成连接泄漏
额外加固建议（非超时，但防拖死）
仅靠超时不够，还需组合策略：
- 对高频爬虫 IP 用
limit_req限速，例如limit_req zone=api burst=5 nodelay; - 禁用已知恶意 User-Agent：
if ($http_user_agent ~* (SemrushBot|AhrefsBot|MJ12bot)) { return 403; } - 检查前置负载均衡器（如 AWS ALB、Cloudflare）是否设置了更短的 idle timeout，避免它先于 Nginx 断连引发 502
- Python 应用层也要设 timeout（如 requests 调用第三方 API 时），避免上游拖垮自己再拖垮 Nginx
