云安全组 + 系统防火墙：双层防护详解
大厂云都有云防火墙/安全组，很多人开了机器却从来没配过。小够详解云安全组的工作原理、和 UFW/iptables 的关系、入站出站规则怎么写、实战配置一套 Web 服务器的双层防护，以及两个最常见的配错案例。
我是小够。用 Vultr、DigitalOcean、Linode、Hetzner 这类大厂云的人注意：你买的机器自带一层免费防火墙——云安全组（有的叫 Cloud Firewall），在商家控制台里配，很多人开通机器后从来没点开过。今天把它讲透。
云安全组是什么
一句话：在流量到达你的 VPS 之前，先在机房入口处过滤一遍。它是独立于你系统之外的网络层设备，你在控制台上配规则，实时生效，不需要登录服务器。最大的好处：即使你的系统防火墙配错了、甚至系统被玩坏了，云安全组这道门还立着。
和 UFW 是什么关系
不冲突，是纵深防御的两层：
- 云安全组：机房入口，拦掉明显恶意的流量，保护"整台机器"。
- UFW/iptables：系统内部，精细控制每个服务的访问，保护"每个端口"。
打个比方：云安全组是小区大门保安，UFW 是你家防盗门。两个都要有，规则保持一致：大门放行的，防盗门也要放行；大门拦掉的，到不了防盗门。
入站规则怎么写
云安全组的规则一般分方向、协议、端口、来源。给一台 Web 服务器写规则：
- 入站：TCP 22（或你的 SSH 端口），来源=你的 IP → 允许
- 入站：TCP 80、443，来源=全部 → 允许
- 入站：其他，一律拒绝（默认）
- 出站：全部允许（默认，建站服务器一般不需要限制出站）
来源 IP 能写多严写多严：SSH 管理端口只允许你自己的 IP（或跳板机 IP），这是云安全组最有价值的一条规则。你的家庭宽带 IP 会变？那就配个范围，或者配合 VPN/跳板机的固定出口 IP。
出站要不要限制
个人和中小站点：出站默认全放行，省心。要求高的场景（比如防止被入侵后对外发包当肉鸡），可以收紧到只允许 80/443/DNS。但收紧出站容易误伤（更新源、API 调用都可能被拦），先保证入站是对的，出站等你有精力再说。
两个最常见的配错案例
案例一：云安全组开了，UFW 没开对应端口。 症状：网站打不开。排查：两层是"与"关系，必须同时放行。记住检查顺序：先看云安全组，再看 UFW，最后看服务本身有没有在监听。
案例二：把自己锁外面。 云安全组里把 SSH 来源写错了 IP，或者规则顺序搞反。救法：大多数商家控制台支持"临时放行"或直接改规则，不需要 VNC。但教训一样：改之前确认好当前出口 IP（搜"我的 IP"就能看到）。
和 UFW 联动的小技巧
- 云安全组做"粗过滤"：只放行业务大类端口。
- UFW 做"细过滤"：fail2ban 动态封禁、限流、按 IP 段微调。
- 两边都开了日志，排查时先看云安全组的流量日志（如果商家提供），再看系统日志，分层定位快得多。
三套规则模板：照抄就行
模板 A：Web 服务器（博客/企业站）
| 方向 | 协议/端口 | 来源 | 动作 |
|---|---|---|---|
| 入站 | TCP 22（或自定义 SSH 端口） | 你的 IP | 允许 |
| 入站 | TCP 80、443 | 全部 | 允许 |
| 入站 | 其余 | 全部 | 拒绝 |
模板 B：应用服务器（Web + 数据库同机）
在模板 A 基础上，数据库端口（3306/5432）不要出现在入站规则里——本机应用连数据库走 127.0.0.1，不需要经过安全组。记住：安全组里看不到的端口，不代表服务没在跑；服务绑 127.0.0.1 和安全组拒绝是两回事，都要做。
模板 C：跳板机
| 方向 | 协议/端口 | 来源 | 动作 |
|---|---|---|---|
| 入站 | TCP SSH 端口 | 你的 IP（尽量窄） | 允许 |
| 入站 | 其余 | 全部 | 拒绝 |
跳板机只干一件事：让你跳过去。所以它只需要 SSH 端口，80/443 都不需要。越纯粹越安全。
三套模板覆盖了 90% 的个人和小团队场景。对号入座，别自己从零设计——从零设计容易漏，模板是前人踩坑换来的。
规则命名规范
规则一多，命名就重要了。推荐格式：方向-端口-来源-用途，比如：
in-2222-home-ssh：入站，2222 端口，家庭 IP，SSH 管理in-443-any-web：入站，443 端口，全部，Web 服务in-3306-deny-all：入站，3306，全部拒绝（显式拒绝，防手滑）
命名规范的好处：三个月后回来看，一眼知道每条规则是干嘛的；交接给别人，对方不用逐条猜。控制台支持 description 的，把"添加日期 + 原因"也写进去，和巡检报告对得上。规则名别用"test1"“temp"这种，用三个月后自己还能看懂的名字——你未来的自己会感谢现在的你。
IPv6 安全组别漏
很多云的安全组规则分 IPv4 和 IPv6 两套，或者一条规则要分别写 v4/v6 来源。::/0 是 IPv6 的"全部”。检查清单：你的 SSH 限制是不是 v4/v6 都写了？Web 端口的放行是不是两套都有？只配 v4 不配 v6，等于给 IPv6 留了后门。用 ping6 或在线 IPv6 检测工具验证一下，别靠猜。
规则变更要留痕
安全组规则会越加越多，“临时放行一下"是最常见的规则膨胀来源。建议：
- 每条规则写备注（控制台一般支持 description）：
2025-05-19 临时排查，排查完删除。 - 带日期的临时规则，设个日历提醒，到期删。
- 每季度导出来看一遍（截图或控制台导出），删掉过期的。
规则膨胀的危害：半年后你自己都不知道哪条是干嘛的，不敢删，越积越多，攻击面悄悄变大。定期清理和定期巡检一样重要。
没有云安全组的小商家怎么办
便宜 VPS 商家很多不提供云防火墙，那就把 UFW 配好，效果是一样的，只是少了一层"系统坏了还能挡"的保险。这种情况下，fail2ban + UFW + 密钥登录三件套更要配齐，别偷懒。
小够的总结：云安全组是白送的，别浪费。大厂云用户花 10 分钟配好它，等于多了一道独立于系统的防线。记住纵深防御的思路：没有哪一道门是万无一失的，但每多一道门，攻击者的成本就翻一番。配好、验证、文档化，三步走完，这道防线才算真正立起来了，之后每月巡检时顺带看一眼规则有没有膨胀。
实战：从零配一台 Web 服务器
假设你刚开了一台大厂云的 VPS，要跑博客。跟着走一遍：
第 1 步：先别急着装东西，配云安全组。 在商家控制台找到安全组/防火墙入口（一般在实例详情页或网络菜单下，截至撰写时各家叫法略有不同：Firewall、Security Group、防火墙，认准这类词）。新建一条规则组，起名 web-server，写三条入站：SSH 端口来源写你的 IP、80/443 来源写全部、其余默认拒绝。把这条规则组绑定到你的实例。
第 2 步：登录机器，配 UFW。 和云安全组写一样的规则：
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 你的IP to any port 2222
sudo ufw allow 80,443/tcp
sudo ufw enable
第 3 步：装应用，但数据库绑内网。 装 Nginx、MySQL，MySQL 配置文件里 bind-address = 127.0.0.1，确认 ss -tlnp 里 3306 只监听在 127.0.0.1。
第 4 步：验证。 从外网 nmap 扫：应该只看到 80、443 和你的 SSH 端口（如果你的 IP 不在扫描源里，SSH 端口应该是 filtered 状态）。从手机流量（换个 IP）试连 SSH，应该连不上——证明来源限制生效了。
第 5 步：文档化。 把规则截图或抄下来存档：哪条规则、为什么加、什么时候加的。三个月后你会感谢现在的自己。
走完这 5 步，一台"双层防护"的 Web 服务器就上线了。全程 20 分钟，其中 15 分钟在等系统更新。
安全组和 NACL 的区别
有些云（比如 AWS 系）还有个 NACL（网络 ACL），容易和安全组搞混。一句话区别：安全组是有状态的，NACL 是无状态的。有状态指：你允许了入站的 80 端口，返回的流量自动放行，不用再写出站规则；无状态的 NACL 则要入站出站各写一条。个人用的大厂云（Vultr/DO/Linode/Hetzner）一般只有安全组这一层，知道有 NACL 这个概念就行，遇到再说。
排查清单：连不上了按这个顺序查
配完安全组发现连不上，别慌，按这个顺序查，90% 的问题出在前两步：
- 云安全组：规则绑对实例了吗？端口写对了吗？来源 IP 是不是你当前的出口 IP（搜"我的 IP"确认）？
- 系统防火墙：
ufw status，规则和云安全组对得上吗？ - 服务监听：
ss -tlnp，服务真的在监听那个端口吗？监听地址是 0.0.0.0 还是 127.0.0.1？ - 服务本身：
systemctl status 服务名，服务在运行吗？配置文件改完重启了吗？ - 本地网络：换个网络（手机热点）试试，排除本地运营商的问题。
这个顺序是从外到内：先查最外层的门，再查里面的门。乱查一气最浪费时间。
出站规则实战：要不要收紧
前面说个人站点出站默认放行就行，这里补充"想收紧怎么做”。以只需要 Web 服务的机器为例：
| 方向 | 端口 | 用途 |
|---|---|---|
| 出站 | 80、443 | 更新软件、调 API、Let’s Encrypt 验证 |
| 出站 | 53 | DNS 解析 |
| 出站 | 123 | NTP 对时 |
| 出站 | 其余 | 拒绝 |
NTP（123/UDP）最容易漏：时间不对会导致 HTTPS 证书校验失败、日志时间错乱，莫名其妙的问题一大堆。DNS（53）也别忘，不然 apt update 都跑不通。收紧出站后，先跑一遍日常操作（更新、备份、发邮件），确认都没问题再算完工。
小够的建议：出站收紧是"进阶中的进阶"。入站先做到 100 分，出站保持默认放行，对 99% 的个人用户已经够用了。等你对自己的业务流量了如指掌，再收紧不迟。记住顺序：先把门守好，再考虑要不要给窗户加锁，一步一步来。
常见问题
Q：云安全组和 UFW 规则冲突了听谁的？ A：听"最严"的。流量要同时通过两层，任何一层拒绝就进不来。所以配的时候两边对照着写，别只改一边。排查连通性问题时，按"云安全组 → UFW → 服务监听"的顺序查。
Q：SSH 只允许我的 IP，那我在外面用手机流量连不上怎么办？ A：三个办法：1）在云安全组里临时加一条手机出口 IP 的规则，用完删掉；2）走跳板机，跳板机 IP 固定，只给跳板机放行；3）用 Tailscale 这类组网工具，管理流量走内网。推荐第 2 种，一劳永逸。
Q：出站全放行，会不会被拿去发垃圾邮件？ A：这是另一个问题：很多商家默认封 25 端口（SMTP），和你安全组没关系。正常建站、API 调用走 80/443/587 等端口，出站放行是标准做法。真担心被当肉鸡，重点是把入站守好、不让入侵发生。
Q：安全组规则数量有限制吗？ A：各家不一样，一般几十到上百条，个人用绰绰有余。规则写得越少越清晰，别堆几十条"临时测试"规则，定期清理。
Q：换了商家，安全组规则能迁移吗？ A：各家格式不通用，但逻辑通用：把"端口-来源-动作"三列整理成表格，换商家时照着填一遍，10 分钟的事。建议把规则文档化存下来，换机器、排查都用得上。