nginx 反向代理部署 node.js 时，应通过启用 http_stub_status_module 监控 active connections、writing 和 waiting 等关键连接状态字段，并结合 ss、top 等命令与 node.js 指标交叉验证瓶颈；配置 location /nginx_status { stub_status; allow 127.0.0.1; deny all; access_log off; } 即可安全启用。
Node.js 应用通过 Nginx 反向代理部署时，Nginx 本身不感知 Node.js 进程的内部状态，但可以利用其原生 http_stub_status_module 模块监控反向代理层的连接行为——这才是反映真实客户端压力的关键入口。只要 Nginx 正确配置了状态页，就能实时看到有多少连接正经由它抵达后端 Node.js 服务。
确认 stub_status 模块已启用并开放访问
绝大多数预编译 Nginx（如官方源、Ubuntu/Debian 的 apt 包）默认包含该模块，无需重新编译。只需在配置中启用：
- 在
server或location块内添加location /nginx_status { stub_status; } - 加访问控制，例如只允许本机或运维网段：
allow 127.0.0.1; allow 192.168.10.0/24; deny all; - 关闭日志避免干扰：
access_log off;
理解返回值中与 Node.js 流量直接相关的字段
访问 curl http://localhost/nginx_status 后，输出类似：
server accepts handled requests
1234567 1234567 8901234
Reading: 1 Writing: 12 Waiting: 74
重点关注：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- Active connections：当前所有 TCP 连接总数，包括正在读请求、发响应、以及空闲 keep-alive 连接。这个数接近你 Node.js 实际承载的并发连接上限
- Writing：Nginx 正在把 Node.js 返回的响应写给客户端的数量。若持续偏高（比如 >30% Active），可能 Node.js 响应慢或网络延迟大
- Waiting：空闲长连接数。Node.js 支持 keep-alive 时，该值通常占 Active 大头；若突然归零且 Active 波动剧烈，说明客户端频繁建连断连，或 Node.js 端主动关闭了 keep-alive
结合 Node.js 侧指标交叉验证瓶颈位置
Nginx 状态页反映的是“代理层视角”，要定位是 Nginx 卡住、网络卡住，还是 Node.js 处理不过来，需比对：
- 用
ss -s查系统总连接数，确认是否接近net.core.somaxconn或进程级ulimit -n上限 - 查 Node.js 进程 CPU 和内存：若
top -p $(pgrep node)显示 CPU 长期 >90%，而 Nginx 的Writing很低，说明瓶颈在 Node.js 逻辑而非 I/O - 对比
accepts和handled：若差值持续扩大（如每分钟增加上百），说明内核 accept queue 积压，Nginx 来不及调用accept()，常见于突发流量下 Node.js 响应延迟导致连接堆积
简单自动化采集示例
无需复杂工具，用 shell 脚本每 5 秒抓一次关键值：
curl -s http://localhost/nginx_status | awk '/Active connections:/ {print $3} /Writing:/ {print $2}'配合 watch -n 5 '上面命令' 就能肉眼观察连接增长和响应积压趋势。后续可导入 Prometheus + Grafana，用 nginx_connections_active 和 nginx_connections_writing 做告警。
