## 为什么 CVM 上的 TCP 连接问题比物理机更容易误判

腾讯云 CVM 的网络链路在物理机的基础上多了一层虚拟化网络（VPC 内部转发 + ENI + 云上安全组）。当 CVM 出现 TCP 连接异常时，工程师面对两个干扰因素：

**一是症状不直观**：应用报"连接超时"或"Connection refused"，但 CVM 监控里带宽和 CPU 都正常，让人误以为是应用层问题。

**二是排查路径被多一层隔断**：物理机上可以看到网卡层的实际数据包，CVM 上需要先判断问题在云上安全组 / VPC 路由层，还是在 CVM 内部的 TCP 协议栈层，再决定用哪条排查路径。

过去几年，TCP 连接异常是 CVM 生产环境报障频率最高的网络类问题之一。TIME_WAIT 堆积是最常见但最容易被误处理的（很多人一看 TIME_WAIT 多就开始调内核参数，实际上不一定要动）；CLOSE_WAIT 泄漏几乎100%是应用层 bug，调内核参数没用；连接数耗尽可能是 limit 配置也可能是 fd 泄漏；SYN Flood 在公网 CVM 上发生率比内网高，但不一定要上防火墙，先开 syncookies 往往更快。

本文还原 4 类 TCP 故障的完整排查路径，附内核参数速查表，适合在 CVM 生产环境直接参考使用。

---

## 一、TCP 状态机速览：先知道正常流程，才能识别异常

![Gemini_Generated_Image_nz1phjnz1phjnz1p.png](https://developer.qcloudimg.com/http-save/yehe-12466791/8f072e2ae2e0c0c8b40010eea1b13cda.png)

```
# 快速查看 CVM 上各 TCP 状态的连接数
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 典型正常输出（高并发服务器）
#   8432 ESTABLISHED
#    246 TIME_WAIT
#      3 CLOSE_WAIT
#      1 LISTEN

# 异常信号
# TIME_WAIT > 10000  → 可能堆积，需判断是否影响业务
# CLOSE_WAIT > 100   → 几乎确定有应用层连接未关闭的 bug
# SYN_RECV > 500     → 可能正在遭受 SYN Flood
```

---

## 二、TIME_WAIT 堆积：先判断是否真的影响业务

### 2.1 现象识别

```bash
# 确认 TIME_WAIT 数量
ss -ant | grep TIME-WAIT | wc -l

# 查看本地端口使用情况（高并发短连接场景容易耗尽端口）
ss -ant | grep TIME-WAIT | awk '{print $4}' | cut -d: -f2 | sort -n | uniq -c | tail -20

# 检查本地端口范围配置
cat /proc/sys/net/ipv4/ip_local_port_range
# 默认 32768 60999，可用端口约 28231 个
# TIME_WAIT 数量接近这个数时才会影响新连接建立
```

### 2.2 根因判断：TIME_WAIT 多，到底要不要处理

**TIME_WAIT 是 TCP 协议的设计，不是 bug**。主动关闭连接的一端必须在 TIME_WAIT 状态等待 2×MSL（通常 60~120 秒），确保对端的 FIN 包已经被确认。

**要处理的情况**：TIME_WAIT 数量接近 `ip_local_port_range` 的端口范围上限，导致新建连接报 `bind: address already in use` 或 `Cannot assign requested address`。

**不需要处理的情况**：TIME_WAIT 数量即使几千上万，但还没有影响新连接建立（`ss -s` 里 `failed` 计数为 0），这是正常的高并发现象，不需要动内核参数。

### 2.3 修复方案

```bash
# 方案一（推荐）：扩大本地端口范围
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 方案二：开启 TIME_WAIT 快速回收（仅限内网，公网 + NAT 场景有风险）
# 注意：net.ipv4.tcp_tw_recycle 在 Linux 4.12+ 已被移除
sysctl -w net.ipv4.tcp_tw_reuse=1    # 允许将 TIME_WAIT 连接复用于新连接（客户端侧）

# 方案三：缩短 FIN_TIMEOUT（TIME_WAIT 等待时间）
sysctl -w net.ipv4.tcp_fin_timeout=30    # 默认 60，可缩短到 30

# 永久生效，写入 /etc/sysctl.conf
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf
sysctl -p
```

**CVM 特别注意**：腾讯云 CVM 的 VPC 安全组和 NAT 网关不会保留 TIME_WAIT 状态，在 CVM 外部的连接已经断开。TIME_WAIT 是 CVM 内核自己维护的状态，安全组看不到它，不需要在安全组层面做任何配置。

---

## 三、CLOSE_WAIT 泄漏：一定是应用层 Bug

### 3.1 现象识别

```bash
# 确认 CLOSE_WAIT 数量（正常不超过 10，超过 100 就是问题）
ss -ant | grep CLOSE-WAIT | wc -l

# 找出哪个进程持有 CLOSE_WAIT 连接
ss -antp | grep CLOSE-WAIT
# 输出中的 pid=xxx 就是持有连接的进程 ID

# 查看该进程的详细连接
ss -antp | grep CLOSE-WAIT | awk '{print $6}' | grep -oP 'pid=\K[0-9]+'
```

### 3.2 根因分析

CLOSE_WAIT 表示：对端（通常是客户端或上游）已经发送了 FIN 关闭连接，但本端（你的服务）**没有发送 FIN 响应**——即服务端没有正确关闭 socket。

**根因一定在应用层**：
- 连接池实现有 bug，连接归还后没有正确关闭
- 异常处理分支里遗漏了 `conn.close()`
- 框架配置了 `keep-alive` 但没有正确处理对端主动关闭

```bash
# 查看进程打开的文件描述符数量（CLOSE_WAIT 多，fd 也会很多）
ls -la /proc/$(pidof your_app)/fd | wc -l

# 对比 ulimit 限制
ulimit -n    # 当前进程的 fd 上限（默认 1024，高并发需调大到 65535+）
cat /proc/$(pidof your_app)/limits | grep "open files"
```

### 3.3 临时处置与根本修复

```bash
# 临时：重启应用进程（清空泄漏连接），但 CLOSE_WAIT 会重新积累
systemctl restart your-app

# 根本修复：检查代码，确保所有退出路径都有 conn.close()
# 特别关注：异常捕获 + return 前是否关闭了连接
# Java 示例（try-with-resources 自动关闭）:
# try (Connection conn = dataSource.getConnection()) {
#     // ... 
# }  // 自动调用 conn.close()
```

---

## 四、连接数耗尽：fd 上限 vs TCP 连接数上限

### 4.1 现象识别

```bash
# 应用报错 "too many open files" 或 "cannot open more files"
# 查看当前系统文件描述符使用情况
cat /proc/sys/fs/file-nr
# 输出：已分配 已释放（不再用） 最大值
# 如：4096  0  65536  → 已用4096，上限65536

# 查看某进程当前 fd 数量
ls /proc/$(pidof nginx)/fd | wc -l

# 查看进程 fd 上限
cat /proc/$(pidof nginx)/limits | grep "open files"
```

### 4.2 fd 上限调整

```bash
# 临时调整（当前会话）
ulimit -n 65535

# 永久调整（所有进程）
echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf

# systemd 管理的服务，在 service 文件里加：
# [Service]
# LimitNOFILE=65535

# 系统级最大 fd 数
sysctl -w fs.file-max=2097152
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
```

### 4.3 TCP 连接数上限

```bash
# TCP 连接数受 "本地IP:port + 远端IP:port" 四元组唯一性限制
# 通常瓶颈在本地端口范围，而不是 TCP 连接数本身

# 检查本地端口范围
cat /proc/sys/net/ipv4/ip_local_port_range

# 增大：
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 检查 TCP 连接跟踪表（NAT 场景下更关键）
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# 如果 count 接近 max，增大 nf_conntrack_max
sysctl -w net.netfilter.nf_conntrack_max=1048576
```

---

## 五、SYN Flood：公网 CVM 的高频攻击

### 5.1 现象识别

```bash
# SYN_RECV 状态连接异常多
ss -ant | grep SYN-RECV | wc -l
# 正常 < 50，超过 500 开始怀疑 SYN Flood

# 查看来源 IP 分布
ss -ant | grep SYN-RECV | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# 用 netstat 看 SYN 队列积压（半连接队列）
netstat -s | grep "SYNs to LISTEN"
# 输出：152 SYNs to LISTEN sockets dropped  ← 半连接队列已满，正常连接被丢弃
```

### 5.2 快速缓解：开启 syncookies

```bash
# 开启 TCP SYN Cookies（最快的缓解手段，无需重启）
sysctl -w net.ipv4.tcp_syncookies=1

# 增大半连接队列（SYN backlog）
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

# 增大完成连接队列（accept backlog）
sysctl -w net.core.somaxconn=65535
```

**CVM 场景下的优先顺序**：

1. **先开 syncookies**（30 秒内生效，对正常连接无影响）
2. **在腾讯云安全组里限制来源 IP**（如果攻击 IP 集中）
3. **使用腾讯云 DDoS 防护**（BGP 高防）处理大流量攻击
4. **最后才考虑防火墙 iptables 规则**（维护成本高）

```bash
# iptables 限速（作为补充，不作为主要手段）
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
```

---

## 六、内核参数速查表

![Gemini_Generated_Image_q3nsl7q3nsl7q3ns.png](https://developer.qcloudimg.com/http-save/yehe-12466791/693c3f2ccc48e2b0ec7ac5f1c191f6a5.png)

| 参数 | 默认值 | 推荐值 | 风险 | 说明 |
|------|--------|--------|------|------|
| `net.ipv4.ip_local_port_range` | 32768 60999 | 1024 65535 | 低 | 扩大客户端可用端口范围 |
| `net.ipv4.tcp_tw_reuse` | 0 | 1 | 低 | 允许 TIME_WAIT 连接复用（客户端侧） |
| `net.ipv4.tcp_fin_timeout` | 60 | 30 | 低 | 缩短 FIN_WAIT_2 等待时间 |
| `net.ipv4.tcp_max_tw_buckets` | 32768 | 5000 | 中 | TIME_WAIT 最大数量，超过直接销毁（可能导致 RST） |
| `net.ipv4.tcp_syncookies` | 1（现代内核默认开） | 1 | 无 | SYN Flood 防护，必须开启 |
| `net.ipv4.tcp_max_syn_backlog` | 1024 | 8192 | 低 | 半连接队列大小 |
| `net.core.somaxconn` | 128 | 65535 | 低 | 完成连接（accept）队列大小 |
| `net.core.netdev_max_backlog` | 1000 | 10000 | 低 | 网卡接收队列 |
| `fs.file-max` | 65536 | 2097152 | 低 | 系统级最大 fd 数 |
| `net.ipv4.tcp_keepalive_time` | 7200 | 1800 | 低 | TCP keepalive 探测开始时间（秒） |
| `net.ipv4.tcp_keepalive_intvl` | 75 | 30 | 低 | keepalive 探测间隔 |
| `net.ipv4.tcp_keepalive_probes` | 9 | 5 | 低 | keepalive 探测失败次数后断开 |

> ⚠️ **不推荐在 CVM 上使用的参数**：
> - `net.ipv4.tcp_tw_recycle`：Linux 4.12+ 已移除，之前版本在 NAT 环境下有严重 bug（导致正常连接被拒绝）
> - 在公网 CVM 上几乎都在 NAT 后面，`tcp_tw_recycle` 会导致 NAT 后的客户端连接被拒绝

---

## 七、排查流程速查卡（直接用）

```bash
# === Step 1：快速了解当前 TCP 状态分布 ===
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# === Step 2：根据异常状态进入对应分支 ===

# TIME_WAIT 过多 → 确认是否影响新连接
ss -ant | grep TIME-WAIT | wc -l
# 超过端口范围上限才需要处理

# CLOSE_WAIT 过多 → 找进程，找代码 bug
ss -antp | grep CLOSE-WAIT
# 重点看哪个 pid 持有，去查对应应用的连接关闭逻辑

# 连接数耗尽 → 检查 fd 上限和端口范围
ls /proc/$(pidof your_app)/fd | wc -l
ulimit -n
cat /proc/sys/net/ipv4/ip_local_port_range

# SYN Flood → 立即开 syncookies
ss -ant | grep SYN-RECV | wc -l
sysctl -w net.ipv4.tcp_syncookies=1
netstat -s | grep "SYNs to LISTEN"

# === Step 3：修改后验证 ===
sysctl net.ipv4.tcp_syncookies     # 确认参数已生效
ss -s                               # 再次查看状态分布
dmesg | grep -i "syn\|tcp\|conntrack" | tail -20  # 内核日志验证
```

---

## 八、与运维平台结合

TCP 连接异常排查的难点之一，是"能发现，但不知道何时发生过，过了才知道"。

我们跑了 60 多台 CVM，排查过几次 CLOSE_WAIT 泄漏，每次都是应用已经报警才发现。后来在冠服云EMS平台的 ITOM 监控里配置了 TCP 连接状态的定期采集——每 60 秒采集一次各状态连接数，CLOSE_WAIT 持续 >100 立即触发 Warning，SYN_RECV >500 立即触发 High 并自动创建工单。这样从"出事才发现"变成了"积累到预警就响应"，CLOSE_WAIT 泄漏的平均发现时间从 40 分钟缩短到了 3 分钟以内。

腾讯云 CVM 的网络链路在物理机的基础上多了一层虚拟化网络（VPC 内部转发 + ENI + 云上安全组）。当 CVM 出现 TCP 连接异常时，工程师面对两个干扰因素：

腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案

CVM 的 TCP 连接异常比物理机更容易误判——多了一层 VPC 虚拟化网络，症状不直观、排查路径被隔断。本文还原 TIME_WAIT 堆积、CLOSE_WAIT 泄漏、连接数耗尽、SYN Flood 四类故障的完整排查路径：从现象识别→根因判断→修复方案→验证确认，附内核参数速查表和排查命令卡，可在 CVM 生产环境直接参考使用。

产品经理

网络与通信

云计算

运维

腾讯云CVM上TCP连接问题比物理机更易误判，主要由于虚拟化网络层干扰。常见4类故障：TIME_WAIT堆积需判断是否影响业务；CLOSE_WAIT泄漏必是应用层bug；连接数耗尽需检查fd限制；SYN Flood优先开启syncookies。提供完整排查路径和内核参数速查表，帮助快速定位CVM网络问题。

NAT 网关

服务器

虚拟化

云安全

防火墙

路由

Linux

Java

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案-腾讯云开发者社区-腾讯云

腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案

腾讯云运维实战：CLB健康检查联动告警与弹性伸缩的故障自愈方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐