接手一台线上 Linux 服务器，我最怕的不是宕机，而是那种“说不清道不明的慢”。流量一上来，请求偶尔超时，延迟忽高忽低，日志看一眼也没报错，带宽看着没用满，CPU 也不算高。很多运维朋友第一反应是加配置、扩带宽，结果钱花了问题还在。其实这类问题，十有八九是 Linux 网络栈的默认参数跟你实际流量模型不匹配，再加上缺少监控数据支撑，全靠猜当然没法下手。这篇内容就从 Linux 网络性能优化这个核心主题出发，把从参数调优到请求分析这条链路完整走一遍，覆盖内核参数、监控搭建、抓包分析和故障排查，适合正在搞服务器性能、想系统掌握网络排查思路的运维和后端开发。
1. 先定位再动手：把网络指标量化之后调优才有意义
1.1 判断瓶颈在网卡、内核还是应用层
我见过不少人拿到“网络慢”的问题，第一件事就是去改tcp_tw_reuse，或者去找一份“性能优化手册”整页贴到/etc/sysctl.conf里。这种操作不能说完全没用，但大概率是撞运气。正确做法是先量化：瓶颈到底出现在哪个层面。
先看网卡层，用sar采集设备流量：
sar -n DEV 1 10关注rxkB/s、txkB/s、rxerr/s、txerr/s、rxdrop/s、txdrop/s这几个字段。如果rxkB/s已经顶到网卡上限，那是带宽瓶颈，要么扩容，要么做限流；如果带宽没用满，但rxerr和txerr在持续增长，那多半是网卡硬件层面出问题，比如网线质量差、光模块故障、网卡过热，甚至接口协商速率不对。这时候调内核参数没用，得先解决物理层和链路层。
如果网卡层没问题，下一步看软中断和内核协议栈。用top看%si（软中断）的占比，如果持续很高，说明数据包处理已经消耗了大量 CPU。可以用mpstat -I CPU 5看具体是哪颗 CPU 被打满，然后考虑使用 RPS（Receive Packet Steering）做软中断负载均衡，或者直接升级多队列网卡驱动。
网卡和中断都没问题，再看应用层。用ss -s看全局 socket 统计，用ss -tan看连接状态分布。如果ESTAB数量远低于预期，但SYN_RECV很多，说明握手阶段的队列可能已经溢出；如果TIME_WAIT上万，那就要考虑端口复用参数。总之，每层都有每层的指标，先分清出问题的是哪层，再动手改参数。
1.2 常用监控命令组要形成肌肉记忆
既然要量化，就得有一套“肌肉记忆”式的命令组合。我不建议你临时去翻文档，最好把这些命令记成你自己的排查 SOP。
第一组看流量方向：iftop能看到每个对端 IP 的实时带宽，适合定位谁在占带宽；nethogs能按进程维度看带宽占用，适合判断是哪个业务进程在“偷跑”。两个命令叠加使用，能快速缩小范围。
第二组看连接状态：ss -s输出简洁版 socket 统计，netstat -s输出协议层统计，sar -n TCP,ETCP 1则能动态看着active/s（主动连接）、passive/s（被动连接）、retrans/s（重传）、isegerr/s（入站错误）、estabresets/s（连接重置）。我在排查连接超时问题时，几乎都是先开sar -n TCP,ETCP 1观察十秒，看retrans/s是否异常，看listenoverflows/s和listenfails/s是否涨得快。
第三组看具体建连细节：ss -tan state time-wait | wc -l统计 TIME_WAIT 数量；ss -lnt看监听队列的Recv-Q和Send-Q。很多人忽略了一个细节：ss -lnt里的Recv-Q表示 accept 队列里还没被应用取走的连接数，如果这个数字长期等于或者接近 backlog 上限，那说明应用层 accept 速度跟不上，光调内核参数是没用的。
1.3 /proc 文件是监控指标的源头
无论是 Zabbix 还是 Prometheus，它们的网络监控项最终都是从/proc下面读数据。理解这些文件，能帮你判断监控数据是否可靠。
/proc/net/dev就是网卡层的原始计数器，对应sar -n DEV，包含收发包数、字节数、错误数、丢包数。/proc/net/snmp是 TCP/UDP/ICMP 的协议层统计，/proc/net/netstat里还有一些扩展信息，比如TCP: ListenOverflows，这是判断 accept 队列溢出最直接的计数器。/proc/net/sockstat则给出了当前 socket 使用情况，Zabbix 的不少模板就是从这读取TCP: inuse、TCP: alloc、TCP: timewait等数值。
如果你发现监控系统里网络指标异常，第一件事就是看一眼对应/proc文件是否正常。比如/proc/net/snmp里RetransSegs一直在涨，那不管监控面板画出来的曲线好不好看，TCP 重传就是真实存在。别怀疑监控本身，先怀疑数据源，这是我踩过多次坑之后的经验。
2. 参数调优：绕不开的连接队列、缓冲区与连接跟踪
2.1 握手阶段的连接队列：somaxconn 与 tcp_max_syn_backlog
TCP 建连分两个阶段，半连接阶段由tcp_max_syn_backlog控制，完整连接阶段由应用 listen 时的 backlog 参数和内核net.core.somaxconn共同决定。高并发下，最容易出问题的就是 accept 队列太小。
典型故障是：服务刚上线时一切正常，峰值流量一到，客户端连接大量超时，但 CPU 和带宽都没满。用ss -lnt一看，监听端口的Recv-Q已经顶到 128，再查netstat -s里的listenoverflows，持续增长。这就是 accept 队列溢出了。
建议先调内核：
cat >> /etc/sysctl.conf <<EOF net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.core.netdev_max_backlog = 65535 EOF sysctl -p但这只是第一步。Nginx 默认listen 80的 backlog 可能还是 511 或更小，需要在配置里显式写listen 80 backlog=65535;。Java 的 Tomcat、Node.js 的 cluster 模式，也都有各自的 backlog 配置。内核把上限放宽了，应用自己不配合，队列照样会满。这个细节很多人会漏掉，结果参数改了没效果。
2.2 TIME_WAIT 多就等于端口不够用吗
TIME_WAIT 是 TCP 可靠关闭的代价，它保证最后一次 ACK 丢失时还能重传，也防止旧连接的数据污染新连接。但它有个副作用：主动关闭方在这个状态要等tcp_fin_timeout默认 60 秒，才能释放五元组。短连接创建量大时，TIME_WAIT 会堆积，客户端端口能很快被占光。
如果客户端日志报Cannot assign requested address，先数一下 TIME_WAIT：
ss -tan state time-wait | wc -l再确认本地端口范围：
cat /proc/sys/net/ipv4/ip_local_port_range默认往往是32768 60999，也就是不到 3 万个可用端口。短连接一多，端口耗尽很正常。调整思路有两条：一是扩大端口范围，二是复用 TIME_WAIT。
cat >> /etc/sysctl.conf <<EOF net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 EOF sysctl -p这里我要多说一句：tcp_tw_reuse只是允许内核在满足条件时复用 TIME_WAIT 连接，它只对出站连接有效，服务器端监听 socket 不受这个参数影响。另外，网上流传的tcp_tw_recycle千万不要随便开。它在 NAT 环境里会因为不同客户端时间戳不一致而导致连接被直接丢弃，新版内核已经把它移除了，旧内核上也别碰。我在这上面吃过亏：给一批 NAT 环境下的服务器开了tcp_tw_recycle，结果用户反馈“十分钟断一次”，最后排查到就是这个参数。
2.3 缓冲区与带宽时延积：大带宽不等于高吞吐
为什么带宽 1Gbps，实际传输只有几十 Mbps？很多时候是 TCP 窗口不够大。TCP 的发送速率受限于“窗口大小除以 RTT”，也就是著名的 BDP（带宽时延积）。举个例子，1Gbps 带宽、20ms RTT 的链路，BDP 大约是 1Gbps × 0.02s = 20Mbit = 2.5MB。如果 socket 缓冲区上限只有 256KB，那即使带宽再大，单连接最高也只能跑出约 100Mbps。这不是网卡的问题，是缓冲区限制了窗口，窗口限制了吞吐。
生产环境可以参考这样设置：
cat >> /etc/sysctl.conf <<EOF net.core.rmem_max = 67108864 net.core.wmem_max = 67108864 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 65536 33554432 net.ipv4.tcp_window_scaling = 1 EOF sysctl -ptcp_rmem三个值分别代表最小值、默认值、最大值。内核会根据实际连接情况自动调整，但上限必须够大。需要注意，缓冲区开太大也有副作用：内存占用上升，延迟上涨，TCP 窗口通告变大后对端可能一下挤出大量数据。所以别一味的把rmem_max和wmem_max设成 128MB，除非你算过 BDP 和内存预算。
2.4 拥塞控制算法：CUBIC 和 BBR 怎么选
默认的 CUBIC 在传统网络下表现稳定，但它的带宽探测方式在丢包环境下会大幅降低速率。BBR 是 Google 提出的基于瓶颈带宽和往返时延的拥塞控制算法，在高带宽高延迟、轻微丢包的链路上效果明显。
启用 BBR 前先确认内核支持：
modprobe tcp_bbr sysctl net.ipv4.tcp_available_congestion_control然后设置：
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p我的使用感受是，BBR 在长肥链路和跨地域公网传输场景下提升明显，能把那些因为中间链路丢包导致的吞吐下降救回来。但在内网低延迟环境，区别并没那么大。而且在一些老内核、定制内核、非 Linux 设备混用的网络里，BBR 的公平性可能会影响其他业务，建议先在灰度环境对比测试再全量开启。
2.5 连接跟踪表满载：新连接直接被丢
Linux 机器如果启用了 iptables 的 NAT 或者 state 模块，新建连接都会进nf_conntrack表。这个表默认上限往往只有几万条，高并发下很容易满载。满载后内核会在/var/log/messages或/var/log/kern.log里刷：
nf_conntrack: table full, dropping packet.业务表现就是新连接无法建立，但已建立的连接还能维持。处理方式分两步，一是调大上限：
cat >> /etc/sysctl.conf <<EOF net.netfilter.nf_conntrack_max = 1048576 net.netfilter.nf_conntrack_buckets = 262144 EOF sysctl -p注意nf_conntrack_buckets影响哈希表大小，是在模块加载时确定的，很多场景下需要修改/etc/modprobe.d/下对应配置才能永久生效。二是减少不必要的连接跟踪，如果某些端口是纯公网服务，没有 NAT 需求，可以用NOTRACK规则让它跳过追踪。但这个要谨慎，NOTRACK会把该连接从 conntrack 体系里摘出去，后续依赖 conntrack 状态的规则可能全部失效。我通常只对明确不需要 NAT 的高并发 UDP 端口做这种处理，TCP 业务优先靠扩容解决。
3. 监控体系搭建：别等出问题了才看日志
3.1 用 Zabbix 7 监控 Linux 主机和 Nginx 请求状态
Zabbix 仍然是很多企业里最主力的监控平台，到了 7.0 版本，模板和 Agent 的更新都更顺手。要监控 Linux 主机的网络性能，至少要采集几类指标：网卡流量和错误数、TCP 连接状态、socket 使用情况、系统负载和内存。Zabbix 自带的Template Module Linux network interfaces和Template Module Linux TCP基本都能覆盖，但默认的触发器阈值偏保守，最好根据你的业务流量重新设置告警线。
Nginx 是另一个重点。开启状态页：
server { listen 80; server_name _; location /nginx_status { stub_status; access_log off; allow 127.0.0.1; deny all; } }stub_status返回的内容很简单：
Active connections: 291 server accepts handled requests 16630948 16630948 31070465 Reading: 6 Writing: 179 Waiting: 106这几个数字能说明不少问题。Reading高，说明客户端有大量请求头还没发完，可能是慢客户端攻击或者应用处理不过来；Writing高，说明 Nginx 正在向上游读取数据并回写响应，如果持续很高，要关注后端服务的响应速度；Waiting是空闲 keep-alive 连接数，Waiting 很低可能意味着长连接配置不足。
Zabbix 采集方式可以写一个自定义脚本把stub_status解析成单个数值，或者用 Agent 的web.page.get获取内容再配合预处理提取。先把curl -s http://127.0.0.1/nginx_status能正常返回并加上日志告警结合起来。关于进程监控，Zabbix 7 的 agent2 对 nginx 也有更原生支持的插件，但国内很多场景还在用老版本，脚本采集法是兼容性最稳的路子。
3.2 Prometheus + node_exporter：细粒度网络指标怎么抓
如果团队已经用 Prometheus 做监控，网络指标直接从 node_exporter 拿就行。需要关注的核心指标有这么几个：
node_network_receive_bytes_total和node_network_transmit_bytes_total：网卡收发字节数，通常配合rate( ... [5m])计算实时速率。node_network_receive_errs_total、node_network_receive_drop_total：错误包和丢包计数，曲线一旦出现阶梯状增长就要立刻查。node_sockstat_TCP_alloc、node_sockstat_TCP_inuse：TCP socket 使用情况，内存压力下这些值会异常飙升。node_netstat_Tcp_CurrEstab：当前 ESTABLISHED 连接数。node_netstat_Tcp_RetransSegs：TCP 重传段数。
PromQL 示例：
rate(node_network_receive_bytes_total{instance="10.0.0.5", device="eth0"}[5m]) rate(node_network_receive_errs_total{instance="10.0.0.5", device="eth0"}[5m])如果还做拨测，blackbox_exporter 是你的好朋友。它能探测 ICMP ping、TCP 端口、HTTP/HTTPS 状态码和 TLS 证书过期时间，其中probe_http_duration_seconds可以看请求耗时分布。我通常把拨测频率设为 30 秒，再配合probe_success0/1 数据做告警，比单纯盯服务器本地指标更能反映用户侧真实体验。
3.3 没有监控平台时，先靠脚本攒一份实时数据
不是所有环境都方便立刻上 Zabbix 或 Prometheus。临时排查时，我经常直接在服务器后台起一个简单的请求计时脚本，把结果追加到文件：
while true; do curl -o /dev/null -s -w "%{http_code} %{time_total}\n" http://127.0.0.1/api/health >> /tmp/api_health.log 2>&1 sleep 5 done过几分钟后可以快速统计平均耗时和成功率：
awk '{sum+=$2; count++} END {print "avg:", sum/count}' /tmp/api_health.log这个脚本虽然简陋，但在问题复现期间能留下最原始的证据。一般我会在早晚高峰各跑半小时，既能对比不同时段的差异，又能顺手验证参数调优前后的耗时变化。临时脚本做到“能留证据、能保存日志、能自动覆盖”即可，真正长周期监控还是得靠平台化的东西。
4. 请求分析：抓包和耗时拆解是验证优化的关键一步
4.1 tcpdump 抓包：用网络层数据说话
应用日志只能告诉你“谁在什么时候调用了什么接口”，但网络层是否发生了重传、乱序、重复 ACK，应用层完全感知不到。tcpdump 是这里最有力的工具。
比如要分析访问 443 端口的请求，可以：
tcpdump -i eth0 -nn -s 0 -c 5000 'tcp port 443' -w /tmp/443.pcap抓完后先简单看一眼 TCP 握手：
tcpdump -nn -r /tmp/443.pcap 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' | head -20输出里的 Flags[S]是 SYN，[S.]是 SYN-ACK，[.]是 ACK，[F.]是 FIN-ACK，[R]是 RST。如果在握手过程中反复出现[S]重传，比如同一个序列号发了多次，那基本就是链路丢包或者防火墙丢包；如果 SYN 发出去了但一直收不到[S.]，那问题往往在中间链路或者对端防火墙。如果[R]直接出现且序列号对得上，说明对端主动 reset 了连接，可能是连接队列满，也可能是应用层主动关闭。
4.2 curl 计时变量：把一次请求拆成四段
我几乎每次都靠 curl 的计时变量做初步定位，因为它的输出能直接告诉你时间浪费在哪一段：
curl -o /dev/null -s -w "DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s Total:%{time_total}s CODE:%{http_code}\n" https://api.example.com/health每个变量的含义：
time_namelookup：DNS 解析耗时。如果这个值异常高，问题在本地 DNS 配置或者上游 DNS 服务器。time_connect：TCP 三次握手完成耗时。如果time_connect比time_namelookup大很多，可能是链路延迟高、SYN 被丢、客户端和服务器之间的中间设备性能不行。time_appconnect：TLS 握手完成耗时。证书链越长、加解密越慢，这个值越大。time_starttransfer：从开始到现在“服务器返回的第一个字节”到达的耗时。TTFB 高，代表服务端处理或响应头生成很慢。
判断逻辑：TCP 连接耗时高，多半是链路层或防火墙问题；TTFB 高，问题大概率在应用或上游服务；Total - TTFB 大，说明响应体下载慢，可能是带宽小或传输缓冲不足。这套四段拆法在实际定位中能节省大量时间。
4.3 用 Wireshark 的统计功能观察重传与零窗口
服务器上抓完包，一般我会把 pcap 拉回本地用 Wireshark 打开。登录服务器执行：
tshark -r /tmp/443.pcap -q -z io,stat,10可以看每 10 秒的流量趋势。如果要快速看 TCP 对话统计：
tshark -r /tmp/443.pcap -q -z conv,tcp重点看四组东西：重传包数量、Dup ACK 数量、零窗口（ZeroWindow）现象、乱序包数量。
重传和 Dup ACK 多，说明网络存在丢包，或者中间有设备做了奇怪的队列调度；零窗口多，说明接收端应用层处理不过来，TCP 窗口通告减到了 0，这是应用层问题，不是网络问题；乱序多，有可能是多路径导致，也可能跟多队列网卡的哈希策略有关。
有一次我查一个“下载慢但 ping 很低”的问题，抓包统计里没有重传也没有乱序，就是一堆 ZeroWindow。当时还被带宽曲线骗了，一直以为是链路带宽问题，后来看到零窗口才反应过来，是 Nginx 后面的业务应用读数据太慢，把接收窗口给堵死了。这类问题，只看服务端 CPU 和带宽是根本发现不了的。
5. 高频故障复盘与排查速查
5.1 故障一：连接量一上来就大量超时
症状：压力测试或者业务高峰时，客户端频繁报连接超时，服务端负载不高。排查：
ss -lnt | head ss -tan state syn-recv | wc -l sar -n TCP,ETCP 1 5如果ss -lnt看到某个端口Recv-Q数值很大，比如等于甚至超过 backlog，那就是 accept 队列满了。先调net.core.somaxconn和应用配置的 backlog，再看netstat -s中的listenoverflows是否还在涨。注意，很多框架的默认 backlog 很小，比如某些版本 Tomcat 默认只有 100，改内核参数的同时必须同步改应用。
5.2 故障二：TCP 重传率高但带宽没满
症状：接口平均耗时上升，用户感知明显卡顿，但服务器 CPU、内存都正常。先看网卡错误：
sar -n EDEV 1 5 ethtool -S eth0 | grep -E "rx_errors|rx_dropped|rx_missed|tx_errors|tx_dropped" ethtool -g eth0rx_missed持续增长，说明网卡环形缓冲区不够用了，用ethtool -G eth0 rx 4096调大。rx_dropped和rx_errors如果涨得快，还要检查中断是否集中在单个 CPU 上，必要时开 RPS 做负载均衡。内核侧可以适当调大net.core.netdev_max_backlog。这类问题我建议优先处理硬件和队列，比无脑换 BBR 更靠谱。
5.3 故障三：新连接进不来，系统日志疯狂刷 conntrack
症状：服务进程正常，但外部大量新连接超时，执行dmesg -T | tail能看到：
nf_conntrack: table full, dropping packet.这就是连接跟踪表满了。执行sysctl net.netfilter.nf_conntrack_max和sysctl net.netfilter.nf_conntrack_count对比一下。如果 count 已经接近 max，调大是必须的：
sysctl -w net.netfilter.nf_conntrack_max=1048576同时把/etc/sysctl.conf持久化。内存方面要算一下：每条 conntrack 记录大约占用 300 字节左右，100 万条差不多要 300MB 内存，别在内存小的机器上盲调。如果流量模型里大量是短连接且不需要 NAT，可以考虑用 NOTRACK 跳过追踪，但改动前必须有清晰的防火墙策略梳理。
5.4 故障四：客户端报“Cannot assign requested address”
症状：应用日志里大量出现无法分配本地端口的报错，ss -tan state time-wait | wc -l显示 TIME_WAIT 好几万。处理思路：
- 扩大本地端口范围：
net.ipv4.ip_local_port_range = 1024 65535。 - 开启
tcp_tw_reuse。 - 缩短
tcp_fin_timeout。 - 业务侧使用连接池或长连接，减少新建连接频率。
端口耗尽本质上是“短连接风暴”。只调参数不断根，之后的方案是在业务代码里做连接复用。还有一点容易被忽视：如果客户端也跑在同一台机器上，回环地址的端口耗尽同样会报这个错误，排查时别只看外部出口。
5.5 问题排查速查表
| 现象 | 优先命令 | 关键调整 |
|---|---|---|
| 连接超时/大量 SYN_RECV | ss -lnt、netstat -s | somaxconn、tcp_max_syn_backlog、应用 backlog |
| 高带宽利用率但吞吐上不去 | sar -n DEV | 检查网卡速率、调整 rmem/wmem、开启 window scaling |
| TCP 重传率升高 | sar -n EDEV、tcpdump | 调大网卡环形缓冲区、检查中间链路丢包 |
| 应用长时间不读数据 | tshark看 ZeroWindow | 优化应用响应逻辑，不是网络调参能解决的 |
| conntrack 表满 | dmesg、sysctl net.netfilter.nf_conntrack_* | 调大nf_conntrack_max、必要时 NOTRACK |
| TIME_WAIT 过多 | ss -tan state time-wait | ip_local_port_range、tcp_tw_reuse、连接池 |
6. 最后分享一点经验
调参这件事，我最大的体会是“一次只改一组，改完必须留基线”。网络上有一堆 Linux “优化大全”，整页整页往服务器上贴，然后过几天出了问题根本不知道是哪条参数导致的。我现在习惯每次调整前先把/proc/sys下相关值打出来存一份备份，调整后记录业务指标变化，至少观察一个业务周期再决定是否保留。
另外，监控数据的作用不是让你在故障后复盘，而是让你在故障发生前看到趋势。很多人是在收到报警才去开 Zabbix、抓包、查日志，那已经属于救火模式。像sar其实可以一直开着，/var/log/sa里天然保留着历史数据；Prometheus 的告警规则也建议提前配好重传率、丢包率、连接数突增这几类指标，这样再出现网络性能问题，手里才有能拿来对照的历史图像。
最后，请记得把 Zabbix、Prometheus 这些系统本身也纳入资源监控。监控组件把宿主机磁盘打满、网络带宽吃光的案例，我在不少公司都见过。先确保监控系统可靠，再谈优化，这可能是这条链路里最容易被忽略的一环。
