Nginx stub_status模块可实时监控前端连接状态以间接判断Python服务压力：Active connections持续高位且Writing增多，表明Python响应变慢；Waiting占比过低提示后端瓶颈；配合日志与响应时间分析可精准定位问题。

Python 应用部署在 Nginx 后端（常见于 Nginx + uWSGI/Gunicorn 模式）时，Nginx 本身不直接暴露 Python 进程状态，但可通过其内置的 stub_status 模块实时观测**前端连接层健康状况**——这是判断 Python 服务是否被请求压垮、响应变慢或连接堆积的关键窗口。

确认 Nginx 已启用 stub_status 并可访问

先确保 Nginx 编译时包含该模块：

• 运行 nginx -V 2>&1 | grep -o with-http_stub_status_module，有输出即支持
• 在任一 server 块中添加受保护的 location（如仅允许本地或监控机）：

<pre>location /nginx-status {
  stub_status on;
  access_log off;
  allow 127.0.0.1;
  deny all;
}
</pre>

重载配置：sudo nginx -s reload，再访问 http://127.0.0.1/nginx-status 应返回纯文本指标。

从连接状态反推 Python 服务压力

stub_status 不显示 Python 进程数或耗时，但以下字段组合能有效反映后端瓶颈：

提示词大师-python版

图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍

下载

立即学习“Python免费学习笔记（深入）”；

• Active connections 持续高位（接近 worker_connections 设置值），且 Writing 数量明显增多 → Python 应用响应变慢，Nginx 正在持续发送响应
• Waiting 占比异常偏低（如 Reading + Writing 总和长期偏高 → 连接复用率下降，大量新连接涌入，可能因 Python 处理延迟导致客户端反复建连
• accepts ≠ handled 差值持续扩大 → Nginx 接收连接能力受限，常见于 Python 后端响应过慢、阻塞 worker，导致 accept 队列积压（可用 ss -lnt | grep :80 查 Recv-Q 验证）

用 Python 脚本自动采集并告警

写一个轻量脚本定时抓取状态，结合阈值触发提醒（无需 Prometheus 等重型组件）：

<pre>import requests
import time

STATUS_URL = "http://127.0.0.1/nginx-status"
ALERT_THRESHOLD_ACTIVE = 1000 # 触发告警的活跃连接数
ALERT_THRESHOLD_WRITING = 200 # Writing 过高提示后端慢

def parse_status():
  try:
    resp = requests.get(STATUS_URL, timeout=2)
    lines = resp.text.strip().split("\n")
    active = int(lines[0].split()[-1])
    reading, writing, waiting = map(int, lines[2].split()[1::2])
    return active, reading, writing, waiting
  except Exception as e:
    print(f"获取状态失败: {e}")
    return None

while True:
  status = parse_status()
  if status:
    active, r, w, wait = status
    if active > ALERT_THRESHOLD_ACTIVE:
      print(f"[告警] Active connections = {active} (超阈值 {ALERT_THRESHOLD_ACTIVE})")
    if w > ALERT_THRESHOLD_WRITING:
      print(f"[注意] Writing = {w}，可能后端响应延迟")
  time.sleep(5)
</pre>

保存为 nginx_monitor.py，后台运行即可持续盯梢。配合系统通知（如邮件、钉钉 Webhook）可进一步自动化。

补充：与 Python 应用日志联动排查

当 stub_status 显示异常时，立刻检查 Python 应用日志（如 Gunicorn 的 error.log 或 uWSGI 的 uwsgi.log）：

• 是否有大量 timeout、Worker failed to boot、Connection reset by peer
• 响应时间 P95 是否突增？可加 log-format 在 Nginx 中记录 $request_time 和 $upstream_response_time
• 对比 upstream_response_time 和 request_time：若前者远小于后者，说明瓶颈在 Nginx 到客户端链路；若两者接近，则问题在 Python 层