reading和writing是nginx stub_status中反映连接i/o阶段的指标，分别表示正读取请求和正发送响应的连接数，需结合waiting判断真实活跃连接与瓶颈位置。
reading 和 writing 是 stub_status 提供的两个关键连接状态指标，它们反映的是 Nginx 工作进程在当前时刻处于特定 I/O 阶段的连接数，**不能直接等同于并发请求数或负载高低，但能有效揭示连接在处理链路中的瓶颈位置**。
reading：正在读取客户端请求头/体的连接数
该数值表示 Nginx 已接受连接（accept），且正从 socket 缓冲区中读取 HTTP 请求数据（如请求行、头、POST body）。常见于以下情况：
- 客户端发送慢（如移动网络上传大文件、弱网设备提交表单）导致读取未完成
- 后端未及时响应，但客户端仍在持续发包（较少见，因 Nginx 默认会限制 request body 大小和超时）
- 存在大量长连接且客户端周期性发送小请求，但 Nginx 尚未收全一次完整请求
评估建议：若 reading 持续 > 10–20（视 worker_connections 设置而定），需检查 client_header_timeout、client_body_timeout 是否过长，并确认是否有异常爬虫或慢客户端。结合 access.log 中 $request_time 和 $upstream_response_time 分析，若前者显著大于后者，说明问题出在请求接收阶段。
writing：正在向客户端发送响应的连接数
该值表示 Nginx 已完成 upstream 处理（或本地响应生成），正将响应数据写入 socket 发送给客户端。高 writing 常意味着：
- 客户端接收能力弱（如下行带宽小、TCP 窗口满、频繁丢包）
- 响应体过大（如未压缩的 JS/CSS/图片流式输出）
- 启用了 sendfile 但磁盘 I/O 或 page cache 不足，导致内核 write 调用阻塞
评估建议：writing 长期高于 reading，尤其伴随 high load 和低吞吐时，应优先排查网络质量与响应压缩（gzip / brotli）、缓冲区设置（proxy_buffering、proxy_buffers）、以及是否误用 chunked transfer encoding 导致流式阻塞。
reading + writing ≠ 并发连接数，需结合 waiting 综合判断
stub_status 还提供 waiting（即 keepalive 空闲连接数）。真实活跃连接 ≈ reading + writing；总连接数 = reading + writing + waiting。若 waiting 占比极高（如 >80%），说明多数连接是空闲保活，实际 I/O 压力不大；若 reading/writing 合计接近 worker_connections 上限，则可能触发连接拒绝（error log 出现 "accept() failed"）。
操作建议：定时采集 reading、writing、waiting 三值，绘制趋势图。当 reading + writing 持续超过 worker_connections × 0.7，且 waiting 缓慢下降，说明连接积压风险上升，需扩容或优化客户端行为。
注意：这些数值是瞬时快照，需配合其他指标交叉验证
单一时间点的 reading=5、writing=3 几乎无意义。必须结合：
- accepts / accepted 差值 → 实际每秒新建连接数
- handled / requests 差值 → 请求处理效率（是否大量失败）
- 系统指标：netstat -ant | grep :80 | wc -l、ss -i state established | grep nginx | wc -l、load average、%sys CPU
快速定位步骤：先看 reading 是否突增 → 查客户端超时与请求大小；再看 writing 是否滞涨 → 查响应体积与网络质量；最后对比 waiting 变化 → 判断是真实压力还是连接复用率高。
