client_header_timeout 是容器化环境中防御慢速头部攻击最轻量、最前置的防线，需按场景设为4–12秒，并配套 reset_timedout_connection、限连及缓冲区调优以闭环防护。
client_header_timeout 是容器化环境中防御慢速头部攻击（如 slowloris）最轻量、最前置的防线。它不依赖后端服务，也不经过业务逻辑，只在 nginx worker 的事件循环里盯住“请求头是否按时发完”这一环节——对容器场景尤为关键：资源更紧、连接更短、横向扩缩更频繁，容不得半开连接长期滞留。
容器环境下的 timeout 取值逻辑
容器通常部署在 Kubernetes Ingress、Service Mesh 边界或云原生网关层，链路比传统物理机更可控，但也更易被扫描器高频试探。取值不能照搬默认 60 秒，也不能盲目压到 3 秒：
标准 API 网关（面向公网）：设为 7 秒
浏览器、curl、主流 SDK 在 TLS 握手完成后，通常 1–2 秒内发完全部 header；7 秒可覆盖 CDN 中转、跨 Region 延迟，同时拦截每 10 秒补一个字段的扫描器。Ingress 后置的 Pod 服务（内网直连）：设为 4–5 秒
无 NAT、无深度检测设备、无 TLS 终结（若 TLS 已在 Ingress 层卸载），首字节延迟极低，可收紧防御窗口。含 JWT/多段 Cookie 的鉴权容器（如 OAuth2 Proxy）：设为 12 秒
但必须同步检查client_header_buffer_size和large_client_header_buffers，否则缓冲不足会触发重试，反而延长等待时间，让攻击绕过 timeout。不建议低于 3 秒
某些 Istio Sidecar、Linkerd Proxy 或老旧 CNI 插件可能引入微秒级调度抖动，过短易导致合法健康检查失败或 readiness probe 超时。
必须配套的容器友好配置
单设 client_header_timeout 不足以闭环防护，尤其在容器动态伸缩场景下，需避免连接堆积引发 OOM 或 readiness 失败：
reset_timedout_connection on;
超时后主动发 RST 包，跳过四次挥手，立即释放 socket 文件句柄和内核连接槽位。这对容器 PID namespace 和 conntrack 表清理至关重要，防止TIME_WAIT泛滥拖慢新连接建立。limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 8;
单 IP 限 8 并发连接，防攻击者用少量 IP 扫描多个 Pod 实例。注意：若前端有统一 LB（如 AWS ALB、GCP HTTP Load Balancer），应改用$http_x_forwarded_for或$realip_remote_addr，并开启set_real_ip_from。client_header_buffer_size 4k; large_client_header_buffers 4 16k;
容器中常见长 JWT（>2KB）、多域 Cookie 或 OpenID Connect 头，缓冲区不足会导致 Nginx 重试读取或直接 400，间接延长等待——这反而给慢速攻击留出空隙。
验证是否真生效（容器实操）
别只看 nginx -s reload 成功，要验证行为是否符合预期：
-
用
kubectl exec -it <nginx-pod> -- sh</nginx-pod>进入容器，执行：telnet localhost 80 GET / HTTP/1.1
不发
Host:也不发空行，等待约 4–7 秒，连接应被主动关闭（非客户端断开），且 error log 出现client timed out while reading client request headers。 -
查看日志是否带
$request_time和$status：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent $request_time';
攻击流量特征明显：同一 IP 短时大量
408，$request_time高度集中在 timeout 值附近（如 6.98s、6.99s）。
不复杂但容易忽略
