Nginx stream模块本身不原生支持详细连接统计，但可通过log_format记录$upstream_connect_time等变量配合access_log输出基础连接日志，并借助外部工具（如Prometheus+Grafana、awk或系统命令）实现每秒新建连接数、活跃连接数及后端延迟分布等统计分析。

Nginx 本身在 stream 模块中不原生支持连接级的详细统计分析（比如每秒新建连接数、当前活跃连接数、各后端节点响应延迟分布等），但可以通过组合配置与外部工具，实现对 TCP 代理连接的基础监控和可观测性。关键在于：统计能力不在 proxy 动作本身，而在日志、状态接口和系统层面的协同。

---

✅ Nginx stream 模块能提供的连接统计能力

stream 模块虽不内置 Prometheus 指标或实时 Dashboard，但它支持两类轻量级统计入口：

• 连接计数类变量（需配合 access_log）
  stream 块中可使用以下内置变量记录连接行为：

  • $remote_addr：客户端 IP
  • $server_addr:$server_port：代理监听地址
  • $upstream_addr：实际转发到的后端地址（含端口）
  • $upstream_connect_time：建立 TCP 连接耗时（毫秒，需开启 proxy_timeout 和 log_format 支持）
  • $upstream_bytes_sent / $upstream_bytes_received：转发数据量（需 Nginx ≥1.23.0 且启用 log_format 中对应字段）

  示例日志格式（加在 stream 块顶部）：

  

  Nginx Hosting

  通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

  下载

  log_format stream_log '$remote_addr [$time_local] '
                         '-> $server_addr:$server_port '
                         'to $upstream_addr '
                         'connect: $upstream_connect_time ms '
                         'sent: $upstream_bytes_sent recv: $upstream_bytes_received';
  access_log /var/log/nginx/stream-access.log stream_log;

• 基础连接状态（仅限 nginx -s status 或第三方模块）
  官方 stream 模块没有 /status 或 stub_status 类似 HTTP 的内置状态页。若需实时连接数，有两条路径：

  • 使用 ss -tn sport = :3306 | wc -l 或 netstat -ant | grep :3306 | grep ESTAB | wc -l 等系统命令抓取监听端口的 ESTABLISHED 连接数；
  • 编译安装带 nginx-sticky-module 或 nginx-stream-status-module 的增强版（非官方，运维需评估稳定性）。

---

✅ 实用的统计分析落地方式

真正可用的统计分析，靠的是“Nginx 日志 + 外部工具”组合：

• 按分钟聚合连接数 & 错误率
  用 awk 或 logrotate + goaccess/graceful 快速生成日报：

  # 统计每分钟新建连接数（基于时间戳）
  awk '{print substr($2,2,15)}' /var/log/nginx/stream-access.log | \
    sort | uniq -c | sort -nr

• 对接 Prometheus + Grafana（推荐）
  需部署 nginx-prometheus-exporter（如 nginx-lua-prometheus 的 stream 分支适配版），或用 Filebeat + Logstash 将 stream-access.log 解析为结构化事件，再写入 Prometheus 的 counter{job="mysql-proxy"} 指标。

• 连接健康度观测（关键！）
  在 upstream 中启用失败探测，间接反映连接质量：

  upstream mysql_backend {
      server 192.168.1.10:3306 max_fails=3 fail_timeout=30s;
      server 192.168.1.11:3306 max_fails=3 fail_timeout=30s;
      keepalive 32;  # 复用后端连接，减少握手开销
  }

  结合 error_log 级别设为 warn，可捕获 connect failed、connection refused 等事件，用于判断网络抖动或后端宕机。

---

⚠️ 注意事项：统计不准的常见原因

• upstream_connect_time 仅记录成功建连耗时，超时或拒绝连接不计入该字段，需查 error.log 补充；
• access_log 默认只记录连接关闭时的日志（非连接建立瞬间），长连接场景下日志延迟明显；
• stream 日志不支持 if 条件过滤，无法像 HTTP 模块那样排除心跳包或健康检查请求；
• 若开启 so_keepalive on，TCP 层保活包不会触发新日志行，不影响连接数统计，但可能让 ss 统计虚高。

---

Nginx TCP 代理的统计不是开箱即用的功能，而是以日志为源头、以运维脚本或可观测体系为延伸的一套实践。重点不在“能不能统计”，而在于“你想回答什么问题”——是排查偶发断连？评估扩容阈值？还是监控慢查询源头？明确目标后，选日志解析、进程态采集或 exporter 对接，效果比强求 Nginx 自身输出仪表盘更可靠。