# 

上周帮一个团队查故障，现象很干净：一台 CVM 上的 HTTPS 服务突然全部超时。

奇怪的地方在于，服务本身是好的。登上机器敲 curl 打本机，200；看进程，活着；看端口，443 在监听。在机器上抓包，能看到客户端的 SYN 进来，也能看到服务端把 SYN-ACK 发出去。但客户端那边就是收不到，一直重试到超时。

问题出在他们前一天做的一次「隔离改造」：把子网的安全边界从安全组换成了网络 ACL，规则写得很符合直觉——入站放行 443 和 22，出站一条没加，理由是「服务器不需要主动往外连，全拒更安全」。

这条规则如果写在安全组上，业务一点事没有。写在网络 ACL 上，全站超时。差别不在规则内容，在两种东西对待「返回的数据流」的方式完全不同。

## 同样一条规则，为什么放在两个地方结果不一样？

腾讯云 VPC 的文档里有一张对照表，把这件事说得比任何博客都清楚。原文是这几句：

> 有无状态：有状态：返回数据流会被自动允许，不受任何规则的影响；无状态：返回数据流必须被规则明确允许

这句话的意思是，安全组判断的不是「包」，而是「连接」。一个连接只要入站方向被放行过，这个连接的回包就会被自动允许出去，哪怕你的出站规则写的是全拒绝。

网络 ACL 判断的是「包」。它不知道这个包属于哪个已经建立的连接，也不打算知道。每个包都要自己在规则列表里找到一条允许它的规则，找不到就丢。

所以同样的「只放入站 443」，在两种机制下的实际效果是：

| 机制 | 入站放行 443 | 出站全拒绝 | 实际结果 |
| --- | --- | --- | --- |
| 安全组 | 请求进来 | 回包被自动允许 | 正常访问 |
| 网络 ACL | 请求进来 | 回包被丢弃 | 客户端超时，服务端看起来一切正常 |

这就是那个团队踩的坑。他们以为自己在「复制」一套已有的安全组规则，实际上是在一个语义完全不同的对象上重写了一遍。

## 为什么表现是「服务端正常、客户端超时」？

因为回包丢在了服务端机器的网卡之外。

在机器上抓包，抓到的是本机协议栈收发的包。SYN-ACK 从协议栈出来、经过网卡驱动、发到虚拟网络里，这一步在本机看来是成功的，抓包自然抓得到。

丢包发生在虚拟网络的子网边界上，也就是网络 ACL 生效的那一层。这时候：

- 应用层：没有错误，日志正常
- 内核：没有错误，没收到 ICMP，没触发重传放弃（客户端在重传）
- 抓包：能看到包出去了
- 客户端：一直等到超时

这种「四层都看不出问题」的故障，最容易被误判成网络抖动或者对端问题，然后浪费几个小时。

## 连不上但服务活着，该按什么顺序往下切？

碰到「连不上但服务是活的」，别一上来就查应用。按这个顺序往下切，每一步只回答一个问题。

第一步，确认连接有没有建立。在服务端机器上看连接状态，如果只有 SYN_RECV 没有 ESTABLISHED，说明三次握手没走完，问题在传输层以下。

第二步，确认回包有没有离开本机。在服务端抓包，看 SYN-ACK 有没有发出去。发出去了，说明问题不在服务端协议栈。

第三步，确认回包有没有到达客户端。在客户端抓包。客户端抓不到 SYN-ACK，就说明包丢在了中间。

第四步，中间有哪些会丢包的东西。安全组、网络 ACL、子网路由、对端的安全组。按「连接」维度判断的（安全组）和按「包」维度判断的（网络 ACL）要分开想。

把服务端的这段抓包命令记下来，排查时会反复用到：

```bash
# 在服务端抓 443 的握手包，只看前 20 个
tcpdump -i eth0 -nn -c 20 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

# 只看连接状态分布，不抓包也能判断握手有没有完成
ss -tan state syn-recv | head
ss -tan state established | wc -l
```

如果第三步发现客户端没收到回包，而服务端确实发了，那基本可以锁定在子网级或实例级的过滤上。这时候再回去看网络 ACL 的出站规则，一眼就能看出问题。

## 网络 ACL 的出站规则该怎么写？

无状态意味着两件事都要写：请求方向、响应方向。

请求方向好写，就是业务端口。响应方向容易被漏掉，因为它的目的端口不是业务端口，而是客户端的临时端口（ephemeral port）。客户端用哪个端口发起连接，回包就往哪个端口去。

不同系统的临时端口范围不一样。Linux 常见的是 32768 到 60999，Windows 常见的是 49152 到 65535，一些老系统会用 1025 起步。写规则的时候没法精确到某一个值，只能放一个范围。

下面是一份能用的最小集合，假设这台机器只对外提供 443 和 22：

```text
入站规则（按顺序匹配，先命中先生效）
1. 协议 TCP，端口 443，源 0.0.0.0/0，允许
2. 协议 TCP，端口 22，源 10.0.0.0/8，允许
3. 协议 ALL，端口 ALL，源 0.0.0.0/0，拒绝

出站规则
1. 协议 TCP，端口 1024-65535，目的 0.0.0.0/0，允许
2. 协议 TCP，端口 443，目的 0.0.0.0/0，允许   # 服务器主动出网调接口
3. 协议 ALL，端口 ALL，目的 0.0.0.0/0，拒绝
```

第二条出站规则是按需加的。如果这台机器要调外部接口或者访问对象存储，443 出站就得放行，否则表现是「服务能收请求，但自己出不去」，故障形态又是另一套。

还有一个容易忽略的点：网络 ACL 的规则是**按位置从上往下匹配，命中就停**。文档的原话是「列表顶端的规则优先级最高，最先应用」，「如果匹配某一条规则成功，则允许通过，不再匹配该规则之后的规则」。

这意味着如果你把「全部拒绝」写在了第一条，后面写多少允许规则都没用。规则顺序错了，看起来配得很完整，实际一条都不生效。

## 这两种东西，什么时候该用哪个？

既然安全组能自动处理回包，那网络 ACL 是不是没必要？

不是。它们的位階不一样：安全组是实例级的第一道，网络 ACL 是子网级的第二道。文档里也是这么分的——安全组作用于「云服务器、数据库等实例」，网络 ACL 作用于「子网内的所有实例」。

我的用法是这样：

| 场景 | 用哪个 | 原因 |
| --- | --- | --- |
| 控制某台机器开哪些端口 | 安全组 | 实例级，粒度对，回包免配 |
| 整段子网禁止访问某个网段 | 网络 ACL | 子网级，一次配全部生效 |
| 临时封禁某个来源 IP | 安全组 | 快，改完立即生效 |
| 给整个子网做兜底拒绝 | 网络 ACL | 防止有人误开安全组 |
| 需要精确到连接状态的策略 | 安全组 | 无状态做不到 |

按这个分工，网络 ACL 只承担「粗粒度兜底」，规则数量少，漏配出站的风险也就小。反过来，如果把业务端口策略都搬到网络 ACL 上，每加一个服务就要记得加一条出站回包规则，迟早会漏。

那个团队后来把网络 ACL 简化成两条：入站放行内网段，出站放行全部，业务端口全部回到安全组里管。故障没再出现过。

## 改造前该对一遍哪几项？

改造网络策略之前，我会把这几项过一遍。都是踩过才知道要看的：

| 检查项 | 怎么看 | 漏了会怎样 |
| --- | --- | --- |
| 回包方向有没有放行 | 网络 ACL 出站规则里有没有临时端口段 | 请求能进来，回包出不去，客户端超时 |
| 规则顺序 | 「全拒绝」是否在最后 | 前面配得再全也不生效 |
| 子网绑了几个 ACL | 一个子网同时只能绑一个 | 以为改了，其实改的是另一个 |
| 安全组出站是否依赖回包 | 有状态，回包不用管 | 误加出站拒绝，误以为会影响业务 |
| 改完有没有在客户端验证 | 从外部 curl 一次，别只看控制台 | 控制台绿色，业务全红 |

最后一条最值得强调。控制台上的「规则已生效」和「业务能通」是两件事，中间隔着连接跟踪、路由、对端策略。改完网络策略，一定要从真实的客户端位置发起一次请求，而不是在机器上 curl 自己。

## 一个可以带走的判断句

碰到「服务是活的、抓包有回包、客户端收不到」，先问一句：这个策略是按连接判断的，还是按包判断的？

按连接判断的，回包不用管；按包判断的，回包必须显式放行。安全组是前者，网络 ACL 是后者。这句话能省掉很多次「明明是照抄的规则」的困惑。

我把这类「看起来一样、语义不一样」的云上对象整理成了一份对照表，包括安全组与网络 ACL、快照与备份、健康检查与监控告警。整理的时候用了 AI墨衍 把散在各处的笔记归拢成一份文档，条目还是逐条对着官方文档核的，因为这种细节一旦记错，排查时会被带偏很久。

顺便问一句：你们生产环境的网络 ACL，现在是真在用，还是建好之后一直空着？


上周帮一个团队查故障，现象很干净：一台 CVM 上的 HTTPS 服务突然全部超时。

安全组是有状态的，网络 ACL 不是：同一条规则，一个放行一个拦

网络与通信

服务端正常但客户端超时？罪魁祸首往往是网络ACL的无状态特性：回包必须显式放行。安全组自动允许回包，而网络ACL每个包都要匹配规则。排查按四步走：确认连接状态、抓包看SYN-ACK、客户端抓包定位丢包点、检查ACL出站规则。出站必须放行临时端口段（如1024-65535），规则顺序也关键。

云服务器

对象存储

代码解释

数据库

服务器

数据流

Windows

路由

Linux

ICMP

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

安全组是有状态的，网络 ACL 不是：同一条规则，一个放行一个拦-腾讯云开发者社区-腾讯云

安全组是有状态的，网络 ACL 不是：同一条规则，一个放行一个拦

安全组是有状态的，网络 ACL 不是：同一条规则，一个放行一个拦

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐