CLOUD技术博在使用阿里云 ECS（Elastic Compute Service）服务器和 SLB（Server Load Balancer，负载均衡）时，常常会遇到一个现象：SLB 的并发连接数与后端 ECS 实例的连接数不一致。这是正常情况，但很多用户对此表示疑惑。
🧩 问题描述
- SLB 显示的并发连接数较高
- ECS 实例显示的并发连接数较低
- 或者反过来：ECS 连接数高，SLB 并发低
✅ 原因分析
这种“不一致”通常是由以下几个原因造成的：
1. SLB 是 TCP 层（四层）或 HTTP 层（七层）
-
四层负载均衡（TCP）：SLB 会作为中间，分别与客户端和后端 ECS 建立连接。
- 客户端 → SLB：一条连接
- SLB → ECS：另一条连接
- 所以每条客户端连接会在 SLB 上体现为两条连接（如果启用了连接保持或长连接）
-
七层负载均衡（HTTP）：
- SLB 可能复用后端连接（如开启 Keepalive），即多个前端请求复用同一个后端连接。
- 此时 SLB 上的连接数可能比 ECS 少。
2. SLB 到 ECS 使用了连接池、Keepalive 等优化机制
- SLB 会缓存与 ECS 的连接（尤其是七层），避免频繁建立/断开连接。
- 导致 SLB 的连接数小于 ECS 的连接数。
3. ECS 上统计方式不同
- 使用
netstat或ss统计连接数时，包括：- ESTABLISHED
- TIME_WAIT
- CLOSE_WAIT
- SYN_RECV 等状态
- 而 SLB 只统计活跃的、正在处理的连接。
示例命令：
# 查看当前 TCP 连接状态数量 netstat -ant | awk '{print $6}' | sort | uniq -c | sort -nr
4. NAT 模式下的 SNAT 和 DNAT 影响
- 在某些部署模式下（如 VPC + NAT），连接会被转换，导致 IP 地址不一致，影响连接数统计。
5. 健康检查连接
- SLB 会对 ECS 做健康检查（默认每秒一次），这也会计入 SLB 的连接数，但不会体现在业务逻辑中。
📊 如何正确理解这些指标？
| 指标来源 | 描述 | 推荐用途 |
|---|---|---|
| SLB 控制台 / API | 显示 SLB 与客户端之间的连接数 | 用于监控整体负载和入口流量 |
| ECS netstat / ss | 显示从 SLB 到 ECS 的实际连接数 | 用于排查后端瓶颈或连接堆积 |
| ECS 应用日志 | 记录每个请求的处理时间、QPS 等 | 用于分析应用性能 |
🔍 解决建议
✅ 如果你关心的是系统性能瓶颈：
- 关注 ECS 上的
TIME_WAIT数量，是否超出系统限制。 - 检查是否有大量
CLOSE_WAIT，说明应用未正确关闭连接。 - 监控 CPU、内存、网络吞吐等资源使用率。
✅ 如果你关心的是 SLB 是否负载过高：
- 查看 SLB 控制台的 QPS、连接数、响应延迟等指标。
- 设置报警规则，当连接数接近上限时通知。
✅ 如果你希望连接数更一致：
- 在 SLB 上关闭连接复用（不推荐，会影响性能）。
- 调整 SLB 的空闲超时时间（默认 900s）。
📝 总结
| 项目 | SLB 连接数 | ECS 连接数 |
|---|---|---|
| 来源 | 客户端连接 | SLB 到 ECS 的连接 |
| 是否复用 | 支持连接复用（尤其七层） | 不受控制，由 SLB 决定 |
| 是否准确反映后端压力 | 否 | 是 |
| 是否包含健康检查 | 是 | 否 |
如果你有具体的配置信息（比如是 TCP 还是 HTTP、ECS 上的连接数统计截图等），我可以帮你进一步分析具体差异原因。
是否需要我帮你写一段脚本自动统计 ECS 上的连接数？