Nginx连接数监控与性能调优实战指南

1. 从一次线上告警说起：为什么连接数监控如此重要

那天下午，我正在处理一个需求，突然钉钉群里连续弹出了几条告警信息：“服务器TCP连接数超过阈值”。点开监控图表一看，其中一台Nginx服务器的连接数曲线像坐了火箭一样，从平时的几百个瞬间飙到了接近两万，并且还在持续增长。整个团队的神经立刻紧绷了起来，因为这通常意味着两种可能：要么是迎来了意想不到的业务洪峰，要么就是服务出现了异常，比如连接泄漏、慢请求堆积，甚至是遭受了攻击。

我第一时间登录服务器，习惯性地想用netstat或ss命令看一眼概况，但转念一想，作为流量入口的Nginx，它自己统计的连接数才是最直接、最准确的“第一现场”数据。Nginx的连接数不仅仅是一个数字，它背后是活跃连接（Active Connections）、读取请求头（Reading）、处理请求（Writing）和保持连接（Waiting）这四个状态的动态组合。理解这几个数字，就像医生看化验单，能快速判断出系统是“健康繁忙”还是“病态阻塞”。比如，如果Writing状态连接数异常高，可能意味着后端应用响应缓慢；如果Waiting连接数占比过高，则可能跟keepalive_timeout配置有关。

掌握查看Nginx连接数的方法，是每一个运维、开发和架构师的必备技能。这不仅是事后排查问题的“手术刀”，更是事前发现隐患、进行容量规划和性能调优的“听诊器”。今天，我就结合那次真实的排查经历和日常实践，为你系统梳理几种核心的查看方法，从最简单的状态页到深入内核的统计，让你不仅能看懂数字，更能理解数字背后的故事。

2. 核心方法一：活用Nginx内置状态页（stub_status）

这是最经典、最直接，也是信息最丰富的方法。它不需要额外安装第三方模块，但需要在Nginx配置中显式开启一个用于暴露状态信息的接口。

2.1 配置启用stub_status模块

首先，你需要确认编译安装的Nginx包含了--with-http_stub_status_module模块。可以通过运行nginx -V命令来查看编译参数。绝大多数主流发行版的预编译包都会包含此模块。

启用它的配置非常简单。在你的Nginx配置文件（通常是nginx.conf或sites-available/下的某个配置文件）中，在一个合适的server块内添加一个location：

server { listen 80; server_name status.yourdomain.com; # 建议使用独立的域名或IP+端口 location /nginx_status { stub_status on; access_log off; # 状态页访问通常不需要记录日志 allow 192.168.1.0/24; # 非常重要！限制可访问的IP段，切勿公开暴露 allow 127.0.0.1; deny all; # 如果部署在云上，可能需要结合安全组和该配置共同限制 } }

注意：安全是重中之重。stub_status接口会暴露服务器的连接信息，必须通过allow/deny指令或防火墙策略将其访问权限严格限制在内网或管理IP范围内，绝对不允许公网无限制访问。

配置完成后，执行nginx -t测试配置无误，然后通过nginx -s reload平滑重载配置。

2.2 解读状态页的输出信息

访问你配置的地址（如http://status.yourdomain.com/nginx_status），你会看到类似下面的纯文本输出：

Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 3 Waiting: 282

我们来逐行拆解这些数字的含义：

• Active connections：当前所有活跃的客户端连接总数。这是最宏观的指标。
• accepts：自Nginx启动以来，已经接受的客户端连接总数量。
• handled：自Nginx启动以来，已经处理完成的连接总数量。正常情况下，这个数字应该和accepts非常接近。如果两者差距持续变大，说明有些连接被Nginx接受后，因为某种原因（如系统资源不足）未能正常处理，是潜在的风险信号。
• requests：自Nginx启动以来，总共处理过的客户端请求总数量。由于HTTP Keep-Alive特性，一个连接上可以发送多个请求，所以这个数通常远大于handled。
• Reading：当前正在读取客户端请求头或请求体的连接数量。如果这个值长时间较高，可能意味着客户端网络较慢或正在上传大文件。
• Writing：当前正在向客户端发送响应数据的连接数量。这是排查后端性能问题的关键指标。如果Writing数持续很高，通常表明后端应用处理请求耗时过长，Nginx在“等待”后端的同时，需要保持与客户端的连接以便回传数据。
• Waiting：当前处于空闲状态，正在等待下一次请求的持久连接（Keep-Alive）数量。这部分连接不消耗什么CPU资源，但会占用文件描述符。其数量主要受keepalive_timeout和客户端行为影响。

实战心得：在一次大促前的压测中，我们发现Writing连接数随着压测流量上升而线性增长，但Reading和Waiting变化不大。这立刻将怀疑指向了后端应用服务。通过进一步追踪，发现是某个数据库查询未用索引，导致单个请求处理时间从50ms恶化到2秒，大量请求堆积在Nginx的Writing状态。修复SQL后，Writing连接数迅速下降，系统吞吐量得到本质提升。所以，stub_status不仅是监控工具，更是性能瓶颈定位的“指南针”。

3. 核心方法二：使用系统级网络工具（netstat/ss）

当你想从操作系统层面，以更全局的视角查看所有与Nginx进程相关的网络连接时，netstat和它的现代替代品ss就派上用场了。这对于分析连接来源、目标端口、状态分布特别有用。

3.1 使用ss命令（推荐）

ss命令比传统的netstat更快，信息也更详细。它是现在排查网络问题的首选工具。

查看所有与Nginx工作进程相关的连接：

ss -tlnp | grep nginx

• -t：仅显示TCP连接。
• -l：仅显示监听（Listening）的套接字。
• -n：以数字形式显示地址和端口，不进行域名解析（更快）。
• -p：显示占用该套接字的进程信息。
• grep nginx：过滤出Nginx进程。

这条命令的输出能让你看到Nginx都在哪些端口上监听（如80, 443），以及每个监听套接字对应的进程PID。

查看Nginx建立的所有活动连接（包括非监听状态）：

ss -tan | grep ESTAB | grep -E ‘:80|:443’ | wc -l

• -a：显示所有套接字（包括监听和非监听）。
• -t：TCP。
• -n：数字格式。
• grep ESTAB：过滤出已建立（ESTABLISHED）的连接。
• grep -E ‘:80|:443’：过滤出目标或源端口是80或443的连接（假设你的Nginx服务在这两个端口）。
• wc -l：统计行数，即连接数。

这个命令的结果，理论上应该与stub_status中的Active connections接近，但它包含了所有TCP层连接，而Nginx自身统计的Active connections是应用层（HTTP）的活动连接，在连接刚建立或处于其他阶段时，两者可能会有细微差别。

3.2 深入分析连接状态分布

ss更强大的地方在于可以详细分析连接的状态。TCP连接有多种状态，对于Nginx这样的服务器，我们最关心的是ESTABLISHED（已建立）、TIME_WAIT、CLOSE_WAIT等。

ss -tan state established | grep -E ‘:80|:443’ | wc -l ss -tan state time-wait | grep -E ‘:80|:443’ | wc -l ss -tan state close-wait | grep -E ‘:80|:443’ | wc -l

• TIME_WAIT过多：这是TCP协议四次挥手后主动关闭方进入的状态，会持续2MSL（通常为60秒）。如果短时间内有大量短连接，会产生大量TIME_WAIT。可以通过调整内核参数net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle（注意，tcp_tw_recycle在NAT环境下可能有问题，Linux 4.12+已移除）或优化应用使用长连接来缓解。
• CLOSE_WAIT过多：这通常意味着你的服务器（Nginx或其后端）没有主动关闭连接，可能是代码bug导致连接泄漏。这是一个非常危险的信号，需要立即排查。

踩坑记录：有一次告警显示某台服务器连接数缓慢增长，ss查看发现CLOSE_WAIT状态的连接有上千个。通过lsof -p <nginx_worker_pid>发现大量连接到同一个后端服务的socket。最终定位到是后端某个服务实例因为Full GC卡死，无法发送FIN包来关闭连接，导致Nginx这边积累了大量的CLOSE_WAIT。重启问题后端实例后，CLOSE_WAIT连接被操作系统回收，问题解决。所以，定期用ss查看连接状态分布，是预防连接泄漏的重要手段。

4. 核心方法三：解析Nginx日志中的连接信息

Nginx的访问日志（access log）和错误日志（error log）是宝藏，里面蕴含着每个连接的详细故事。通过分析日志，我们可以进行更精细化的统计和回溯。

4.1 在日志格式中嵌入连接标识

Nginx默认的日志格式可能不包含连接级别的唯一标识。为了更好的追踪，我们可以自定义日志格式，加入$connection变量，它表示连接序列号，或者使用$connection_requests变量，表示该连接上已经处理过的请求数。

http { log_format detailed ‘$remote_addr - $remote_user [$time_local] “$request” ‘ ‘$status $body_bytes_sent “$http_referer” ‘ ‘“$http_user_agent” “$http_x_forwarded_for” ‘ ‘“$connection” “$connection_requests”’; access_log /var/log/nginx/access.log detailed; }

配置后，日志中会多出两个字段，例如“1256” “3”，表示这个请求发生在第1256号连接上，并且是该连接上的第3个请求。这对于分析Keep-Alive的使用情况非常有用。

4.2 使用命令行工具进行实时统计与分析

有了日志，我们就可以利用强大的Linux文本处理工具进行即时分析。

实时统计每秒的请求数（QPS）：

tail -f /var/log/nginx/access.log | awk ‘{print $4}’ | cut -d[ -f2 | uniq -c

这个命令会动态输出每秒的请求数量，是观察流量波动的利器。

统计当前最活跃的客户端IP（用于排查疑似攻击）：

tail -n 10000 /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -nr | head -20

这个命令分析最近1万条日志，统计出访问最频繁的前20个IP地址。

查找响应时间过长的请求（用于排查慢请求）：假设你的日志格式包含了$request_time变量（表示请求处理总时间）。

awk ‘($(NF) > 5){print $0}’ /var/log/nginx/access.log | head -20

这个命令会找出处理时间超过5秒的请求日志，并打印前20条。$(NF)代表最后一列，这里假设$request_time是最后一列。

实战技巧：线上曾遇到间歇性的接口超时告警。通过stub_status发现Writing连接数在告警时刻飙升。我们立刻去翻查对应时间段的错误日志（error_log），发现了大量的upstream timed out记录。同时，分析同一时间段的访问日志，用上述命令筛选出响应时间大于10秒的请求，发现它们都指向同一个上游服务接口。结合两者，迅速将问题范围缩小到特定的后端服务，后续的排查就有的放矢了。日志不是事后才看的“病历本”，而是实时诊断的“CT机”。

5. 核心方法四：利用第三方监控模块与API

对于生产环境，我们往往需要将Nginx的连接数指标集成到统一的监控告警平台（如Prometheus、Zabbix）中，实现自动化、可视化的监控。这就需要用到功能更强大的第三方模块。

5.1 Nginx Plus 商业版状态API

Nginx Plus提供了功能丰富的RESTful JSON API，可以获取远比stub_status详细的信息，包括连接数、请求率、上游服务器健康状态等，并且天然适合被监控系统抓取。当然，这是付费功能。

5.2 开源方案：nginx-module-vts 与 nginx-lua-prometheus

对于开源Nginx，社区有优秀的替代方案。

nginx-module-vts (nginx virtual host traffic status module)：这是一个非常流行的第三方模块，它提供了按虚拟主机（server）、按上游（upstream）分组统计的详细数据，包括连接数、请求数、流量、响应码分布等，并以JSON格式通过HTTP接口暴露。编译安装此模块后，配置类似stub_status，你能获得一个信息量巨大的监控面板。Prometheus可以通过nginx-vts-exporter来抓取这些指标。

使用nginx-lua-prometheus自行暴露指标：这是一个更灵活的方案。它利用Nginx的Lua模块（需要安装ngx_http_lua_module），允许你在Nginx配置中直接使用Lua脚本定义和更新Prometheus格式的指标。

http { lua_shared_dict prometheus_metrics 10M; init_worker_by_lua_block { prometheus = require(“prometheus”).init(“prometheus_metrics”) metric_connections = prometheus:gauge(“nginx_connections”, “Number of current connections”, {“state”}) } log_by_lua_block { -- 这里可以从ngx.var.connections_*等变量中获取值，更新metric_connections -- 但注意，获取全局连接数需要在单独的定时任务或特定location中，log_by_lua阶段可能不准确 } server { location /metrics { content_by_lua_block { metric_connections:set(ngx.var.connections_active, {“active”}) metric_connections:set(ngx.var.connections_reading, {“reading”}) metric_connections:set(ngx.var.connections_writing, {“writing”}) metric_connections:set(ngx.var.connections_waiting, {“waiting”}) prometheus:collect() } } } }

这种方式高度定制化，你可以暴露任何你关心的指标，并与现有的Prometheus + Grafana监控栈无缝集成。

5.3 系统级监控集成

除了Nginx自身的指标，系统级的资源监控也至关重要。连接数最终会消耗系统资源，主要是文件描述符（File Descriptor）。

• 监控进程打开文件数：使用ls -l /proc/<nginx_worker_pid>/fd | wc -l可以查看单个Nginx工作进程当前打开的文件描述符数量。确保其远低于系统或进程级别的限制（通过ulimit -n查看）。
• 监控系统总连接数：使用cat /proc/net/sockstat或ss -s可以查看系统级别的TCP socket统计信息，包括总使用量。这是防范连接耗尽导致系统瘫痪的最后一道防线。

配置建议：在生产环境中，我通常会采用组合方案：nginx-module-vts提供详细的Nginx内部指标，通过Prometheus抓取；node_exporter抓取系统级指标（包括从/proc读取的TCP连接统计）；再配置一套基础的stub_status作为备用和快速命令行检查。这样，无论是在Grafana仪表盘上纵观全局，还是在服务器上快速执行命令诊断，都能得心应手。

6. 连接数异常场景的排查思路与实战案例

掌握了查看方法，最终是为了解决问题。当连接数出现异常时，如何快速定位根因？下面分享一个典型的排查流程和案例。

6.1 系统性排查流程图

面对连接数飙升，一个清晰的排查思路能节省大量时间：

1. 确认现象：通过stub_status或监控图表，确认连接数增长的类型（是Active总体增长，还是Writing/Waiting某一项激增？）。
2. 定位源头：
   • 如果是Writing激增，重点排查后端应用性能（数据库、缓存、RPC调用）。
   • 如果是Reading激增，重点排查客户端网络或上传行为。
   • 如果是Waiting激增，检查keepalive_timeout配置和客户端行为。
   • 如果Active总体增长，使用ss或netstat结合tcpdump分析连接来源IP和端口，判断是正常业务流量还是异常攻击。
3. 深入分析：查看Nginx错误日志（error_log）寻找报错（如connect() failed,upstream timed out）；分析访问日志（access_log）寻找慢请求、高频IP或特定URL。
4. 资源检查：检查系统资源（CPU、内存、磁盘IO），特别是文件描述符使用量是否接近上限。
5. 联动下游：如果指向后端问题，使用相应工具（如Arthas for Java, pprof for Go）深入分析应用内部状态。

6.2 实战案例：TIME_WAIT连接数过多导致端口耗尽

现象：某活动页面上线后，监控发现服务器连接数缓慢上升，最终导致新用户无法访问，错误日志中出现connect() failed (99: Cannot assign requested address)。

排查过程：

1. stub_status显示Active connections正常，但ss -s显示TIME-WAIT数量极高，接近3万。
2. ss -tan state time-wait | grep :443 | wc -l确认大部分TIME_WAIT确实来自Nginx的443端口。
3. 分析业务，该活动页面由大量前端AJAX短请求构成，且未启用HTTP Keep-Alive（或配置超时过短）。
4. 检查内核参数net.ipv4.ip_local_port_range，范围是32768 60999，可用端口约2.8万个。Nginx作为客户端向后端服务请求时，每个短连接都会消耗一个本地临时端口，并在关闭后进入TIME_WAIT状态持续60秒。当瞬时并发高时，可用端口很快被耗尽。

解决方案：

1. 短期应急：扩大本地端口范围sysctl -w net.ipv4.ip_local_port_range=“1024 65000”，并启用端口快速复用sysctl -w net.ipv4.tcp_tw_reuse=1。
2. 根本解决：优化应用，启用并合理配置Nginx与后端服务之间的HTTP Keep-Alive连接，将多个请求复用在一个TCP连接上，从根本上减少短连接数量。同时，调整Nginx与后端服务的keepalive配置。

upstream backend { server 10.0.0.1:8080; keepalive 32; # 每个Worker进程与上游服务器保持的最大空闲连接数 } server { location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection “”; # 启用HTTP/1.1长连接 } }

这个案例告诉我们，连接数问题有时不是Nginx本身的问题，而是其作为客户端时的行为与系统配置共同作用的结果。理解整个TCP/IP协议栈和Nginx在其中的角色，是进行深度排查的基础。

7. 性能调优与配置建议

监控和排查的终极目的是为了优化和预防。以下是一些与连接数相关的关键配置项和调优建议，它们直接影响着Nginx的连接处理能力和资源消耗。

7.1 关键配置参数解析

• worker_connections：每个Nginx工作进程可以同时处理的最大连接数（包括客户端连接和到上游服务器的连接）。这个值直接限制了Nginx的并发处理能力。设置原则是：worker_connections * worker_processes应该大于系统最大文件描述符限制，并且能满足业务峰值并发需求。通常设置为65535或10240。

  events { worker_connections 10240; }

• keepalive_timeout：客户端连接在关闭前，服务器端将保持打开状态的最长时间。设置太短会增加连接建立的开销，设置太长会占用过多的Waiting连接和文件描述符。需要根据业务特性权衡。对于API服务器，可以设置短一些（如10-30秒）；对于包含大量静态资源、需要多请求加载的网页，可以设置长一些（如60秒）。

  http { keepalive_timeout 30s; # 客户端连接保持时间 keepalive_requests 100; # 一个连接上最多服务的请求数，达到后连接被关闭 }

• multi_accept：在events块中配置。如果设置为on，每个工作进程可以一次性接受所有的新连接。在高并发场景下开启可能有助于性能，但可能增加负载不均衡的风险。

  events { multi_accept on; }

• use：在events块中指定事件模型。在Linux 2.6+系统上，epoll是最高效的选择。

  events { use epoll; }

7.2 系统级参数调优

Nginx的性能也受限于操作系统。以下是一些关键的内核参数建议（在/etc/sysctl.conf中修改后执行sysctl -p生效）：

• net.core.somaxconn：定义了系统中每一个端口最大的监听队列长度。Nginx中listen指令的backlog参数受此值限制。对于高并发服务，建议增大。

  net.core.somaxconn = 65535

  在Nginx配置中对应：listen 80 backlog=65535;

• net.ipv4.tcp_max_syn_backlog：记录尚未收到客户端确认信息的连接请求的最大值。用于防御SYN Flood攻击，也应适当调高。

  net.ipv4.tcp_max_syn_backlog = 65535

• net.ipv4.tcp_tw_reuse / net.ipv4.tcp_tw_recycle：关于TIME_WAIT的回收重用。tcp_tw_reuse相对安全，允许将TIME_WAIT连接重新用于新的出站连接，在客户端角色（如Nginx代理请求到上游）时很有用。tcp_tw_recycle在NAT网络下有问题，已不推荐使用。

• 文件描述符限制：确保系统级别（/etc/security/limits.conf）和Nginx进程级别（worker_rlimit_nofile）的文件描述符限制足够大。

  user www-data; worker_processes auto; worker_rlimit_nofile 65535; # 每个worker进程能打开的文件数上限

个人经验：调优没有银弹。最好的做法是在模拟生产环境的压测中进行。使用工具（如wrk,jmeter）逐步增加并发连接数，同时观察stub_status的各项指标、系统负载和错误日志。你会找到适合你业务场景的最佳配置组合。记住一个原则：先理解，后调整。盲目复制网上的“最优配置”可能会引入新的问题。