Reading值异常升高表明客户端请求头读取阻滞，常见于弱网、慢速攻击或中间设备干扰，需结合tcpdump和日志分析定位，可通过调低client_header_timeout等配置缓解。
Reading 值本身不直接反映“延迟”，它只表示当前有多少个连接正处于读取请求头（request header）的阶段。想通过 Reading 监控静态请求头读取是否变慢，关键不是看 Reading 是多少，而是看它是否异常升高、持续不降，或与 Waiting、Writing 不匹配——这背后往往暗示着客户端行为或网络层的问题。
Reading 异常升高的典型信号
Reading 值通常极低（0 或 1～2），因为 HTTP 请求头很短，正常网络下毫秒级即可收完。如果出现以下情况，需警惕读取环节存在阻滞：
- Reading 长期维持在 5+，尤其在低流量时段仍不回落
- Active connections 明显上升，但 Writing 和 Waiting 却偏低，Reading 占比突增
- 同一时间点多次 curl /nginx-status，Reading 值波动剧烈且难以清零
可能原因与排查方向
Reading 高 ≠ Nginx 本身卡顿，它反映的是“等待客户端发完 header”的状态。常见根源包括：
- 客户端发送缓慢：移动端弱网、浏览器节流、恶意慢速攻击（如 Slowloris），导致 TCP 包分片发送、间隔拉长
- 中间设备干扰：WAF、代理或防火墙对 header 做深度检测（如大 header、特殊字段），造成转发延迟
- 客户端异常中断：发起 CONNECT 或 OPTIONS 预检后未继续，连接卡在读 header 状态，超时前一直计入 Reading
- 前端 SDK 或埋点脚本错误：重复构造不完整 request（如漏 Host、空 User-Agent），触发 Nginx 等待补全
辅助验证方法
单靠 stub_status 不足以定位延迟源头，需结合其他手段交叉印证：
- 用 tcpdump 抓包观察 client → nginx 的首个 TCP 数据段是否延迟到达，或 header 是否被拆成多个小包
- 检查 access_log 中 $request_time 和 $upstream_header_time：若 $request_time 大但 $upstream_header_time 接近 0，说明延迟发生在 header 读取阶段
- 对比 同一 client IP 的 Reading 持续时间：启用 log_format 记录 $connection_requests 和 $msec，观察某连接是否反复出现在 Reading 状态
- 临时开启 error_log info 级别，搜索 "client timed out" 或 "header read timeout" 相关日志
配置层面可做的缓解
虽不能消除外部网络问题，但可通过合理设置减少 Reading 积压影响：
- 调低 client_header_timeout（默认 60s），让卡住的连接更快释放
- 限制 client_header_buffer_size 和 large_client_header_buffers，避免为畸形 header 分配过多内存
- 对可信内网来源，可适当启用 underscores_in_headers on，防止因 header 字段名含下划线被拒绝而挂起
