默认 access_log 对 websocket 不够用，因为 nginx 仅在 http upgrade 阶段记录一条状态为 101 的日志，后续所有 websocket 数据帧均不触发新日志，导致无法反映连接时长、真实流量及关闭原因。
直接看 Nginx 的 access_log 无法准确获取 WebSocket 连接时长和真实流量分布，因为 WebSocket 升级后复用同一 TCP 连接，后续帧通信不产生新 access_log 条目。但可以通过合理配置日志字段 + 关联指标，间接还原关键行为特征。
为什么默认 access_log 对 WebSocket 不够用
Nginx 在处理 WebSocket 时，只在 HTTP Upgrade 阶段记录一条日志（如 "GET /ws HTTP/1.1" 101），之后所有 WebSocket 数据帧（text/binary/ping/pong）均不触发新日志。这意味着：
- 单次连接可能只有一条日志，但实际持续数分钟甚至数小时
- 响应体大小（
$body_bytes_sent）通常为 0 或极小值，无法反映真实消息量 - 无法区分连接是正常关闭、超时断开还是被代理中断
扩展日志字段：捕获升级关键信息
在 log_format 中加入 WebSocket 相关变量，能锁定连接建立上下文：
-
$http_upgrade：确认是否为websocket，过滤非 WebSocket 请求 -
$http_connection：检查是否含Upgrade，验证协议切换合法性 -
$request_time：记录 Upgrade 请求耗时，可识别握手延迟异常 -
$upstream_response_time：若后端是 Node.js/Go 等网关，该值反映服务端接受连接的延迟 -
$status：必须为101，其他状态码（如 400/502/504）说明升级失败，需重点排查
示例格式：log_format ws_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_upgrade" "$http_connection" $request_time $upstream_response_time';
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
关联 upstream 日志与连接生命周期
真正连接时长和流量要靠后端服务自身埋点。Nginx 只是入口，它不感知 WebSocket 连接存续。建议：
- 后端网关（如基于 Socket.IO、gorilla/websocket）在
OnOpen和OnClose回调中打日志，记录conn_id、user_id、open_time、close_time、bytes_in、bytes_out - 将 Nginx 日志中的
$request_id或自定义 header（如X-Trace-ID）透传给后端，实现前后端日志串联 - 用 Prometheus + Grafana 聚合后端上报的连接指标：当前活跃连接数、平均连接时长、每秒消息吞吐量（msg/s）、错误关闭率
用日志估算“有效连接热度”
虽不能精确统计单连接时长，但可通过 access_log 频次分析用户行为模式：
- 按
$remote_addr或$http_cookie分组，统计单位时间（如每小时）内 WebSocket Upgrade 请求次数 → 判断客户端重连频率 - 对返回
101的日志，计算$request_time分位值（P95 > 1s 需关注网络或 TLS 握手问题） - 对比
101成功率与后端上报的连接成功数，差值过大说明 Nginx 层有拦截（如超时、限速、WAF 规则误杀） - 结合
$upstream_response_time分布，定位慢连接是卡在 Nginx 转发，还是后端处理瓶颈
本质上，Nginx access_log 是 WebSocket 流量的“门禁记录”，不是“全程录像”。要掌握连接时长与真实流量，必须以后端网关日志和监控指标为主，Nginx 日志仅作辅助校验与异常初筛。
