Nginx 本身不提供自动化预警能力，需结合外部监控工具实现WebSocket异常告警：通过日志、stub_status、上游健康检查暴露指标，用Prometheus等采集并设置升级失败率、上游宕机等告警规则，再经Alertmanager通知。
Nginx 本身不提供“自动化预警”能力，它是一个反向代理和负载均衡器，不具备主动监控、告警或通知功能。所谓 WebSocket 代理的“自动化预警”，实际是指：通过合理配置 Nginx + 外部工具，实现对 WebSocket 连接异常（如后端不可达、协议升级失败、频繁断连）的可观测与告警闭环。核心思路是——让 Nginx 暴露可采集指标，再由监控系统识别异常模式并触发告警。
暴露关键连接状态指标
Nginx 默认不输出 WebSocket 特定指标，但可通过以下方式间接获取健康信号：
启用
ngx_http_stub_status_module（需编译时开启），获取基础连接数、活跃连接、等待连接等全局状态-
配置
log_format记录 WebSocket 升级关键字段，例如：log_format ws_log '$time_iso8601 $status $http_upgrade $http_connection "$request" $upstream_addr'; access_log /var/log/nginx/ws-access.log ws_log;
成功升级的请求会记录
Upgrade: websocket+Connection: upgrade+ 状态码101；失败则多为400/502/503，便于日志分析 -
使用
upstream健康检查（商业版 Nginx Plus 或开源版配合nginx_upstream_check_module）：upstream ws_backend { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; check interval=3 rise=2 fall=3 timeout=10 type=http; check_http_send "GET /health HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; }可实时发现后端 WebSocket 服务是否响应健康接口，避免将流量打到宕机节点
识别常见 WebSocket 异常模式
仅靠 Nginx 日志或状态页不够，需结合时间维度做聚合判断：
协议升级失败突增：1 分钟内
status=400或status=502且$http_upgrade="websocket"的日志条数超过阈值（如 >10 条）→ 可能是后端未返回101 Switching Protocols，或 Nginx 配置漏了proxy_set_header Upgrade $http_upgrade连接频繁重连：前端上报的
onclose事件密集触发（需前端埋点），同时 Nginx access log 中同一 client IP 在短时间（如 30 秒）内出现多个101→499或502循环 → 往往对应proxy_read_timeout过短或后端心跳缺失上游全不可用：
upstream健康检查连续失败，nginx -T显示所有 server 标记为down，或stub_status中Active connections骤降但Waiting数激增 → 表明后端集群整体失联
对接外部监控与告警系统
Nginx 自身不发告警，需借助标准链路：
采集层：用 Filebeat / Fluent Bit 收集 Nginx 日志，或 Prometheus +
nginx-vts-exporter/nginx-lua-prometheus抓取指标-
处理层：Prometheus 设置如下告警规则示例：
- alert: WebSocketUpgradeFailureRateHigh expr: rate(nginx_http_requests_total{status=~"400|502", http_upgrade="websocket"}[5m]) / rate(nginx_http_requests_total{http_upgrade="websocket"}[5m]) > 0.1 for: 2m labels: severity: warning annotations: summary: "WebSocket 协议升级失败率过高" description: "过去5分钟升级失败占比超10%，请检查后端响应或Nginx Upgrade/Connection头配置" - alert: WebSocketUpstreamDown expr: nginx_upstream_healthcheck_failures_total{backend="ws_backend"} > 0 and (time() - nginx_upstream_healthcheck_last_passed_timestamp_seconds{backend="ws_backend"}) > 60 for: 1m 通知层：Alertmanager 推送至企业微信、钉钉或邮件，附带快速排查指引（如“请确认 backend 是否返回 101”、“检查 proxy_read_timeout 是否 ≥ 后端心跳间隔 × 1.5”）
辅助手段提升可观测性
- 在 location 块中添加唯一 trace ID，便于前后端日志串联：
map $request_id $ws_trace_id { "" $request_id; default $request_id; } proxy_set_header X-Ws-Trace-ID $ws_trace_id; - 后端服务暴露
/actuator/health或自定义/ws/status接口，返回当前活跃连接数、最近失败原因等，供监控轮询 - 前端 SDK 主动上报连接状态（成功/失败/重试次数/延迟），与 Nginx 日志交叉验证，定位是网络层、代理层还是应用层问题
不复杂但容易忽略
