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（如仅允许本地或监控机）：
location /nginx-status {<br> stub_status on;<br> access_log off;<br> allow 127.0.0.1;<br> deny all;<br>}<br>重载配置：sudo nginx -s reload，再访问 http://127.0.0.1/nginx-status 应返回纯文本指标。
从连接状态反推 Python 服务压力
stub_status 不显示 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 等重型组件）：
import requests<br>import time<br><br>STATUS_URL = "http://127.0.0.1/nginx-status"<br>ALERT_THRESHOLD_ACTIVE = 1000 # 触发告警的活跃连接数<br>ALERT_THRESHOLD_WRITING = 200 # Writing 过高提示后端慢<br><br>def parse_status():<br> try:<br> resp = requests.get(STATUS_URL, timeout=2)<br> lines = resp.text.strip().split("\n")<br> active = int(lines[0].split()[-1])<br> reading, writing, waiting = map(int, lines[2].split()[1::2])<br> return active, reading, writing, waiting<br> except Exception as e:<br> print(f"获取状态失败: {e}")<br> return None<br><br>while True:<br> status = parse_status()<br> if status:<br> active, r, w, wait = status<br> if active > ALERT_THRESHOLD_ACTIVE:<br> print(f"[告警] Active connections = {active} (超阈值 {ALERT_THRESHOLD_ACTIVE})")<br> if w > ALERT_THRESHOLD_WRITING:<br> print(f"[注意] Writing = {w}，可能后端响应延迟")<br> time.sleep(5)<br>保存为 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 层
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
