很多站长把服务器买回来之后，第一件事就是装 Nginx、跑 Docker、部署数据库，然后发现外网访问不了，才想起来还有个防火墙。于是随手一条 sudo ufw allow 80，能通就行，至于为什么通、会不会有隐患，一概不管。笔者早年也这么干过，直到有一次被扫描器盯上，才回过头认真梳理 UFW 的配置逻辑。这篇文章就把我这些年的配置经验整理成一套 SOP，希望能帮你少走点弯路。
一、先搞懂 UFW 到底在做什么
💡 推荐阅读：别再用那些老掉牙的教程了：Nginx 反代 + 免费证书自动续签，我踩过的坑都在这了
UFW，全称 Uncomplicated Firewall，本质上是 iptables 的前端封装。它把复杂的链式规则抽象成「允许/拒绝某端口」的直观指令，但底层依然是内核的 netfilter 在干活。理解这一点很关键，因为它决定了三件事：
- 规则是有顺序的：UFW 按规则加入的先后顺序匹配，先命中的生效，后面的不再看。
- 默认策略决定底线：如果默认入站是 deny，那么没显式放行的端口一律进不来；反之则形同虚设。
- 它只管本机：云厂商的安全组在更外层，两层都要放行才通。很多人卡在这里，以为 UFW 没生效，其实是安全组没开。
所以配置 UFW 的第一步，永远不是急着敲 allow，而是先把默认策略定下来。
sudo ufw default deny incoming
sudo ufw default allow outgoing这两条是整个安全模型的基石：入站默认拒绝，出站默认放行。做完这一步，你的服务器对外就是「关着的门」，后面每开一个端口，都是你主动、明确的选择。
二、生产环境的端口开放规范
💡 延伸阅读：别再手动传包了：从裸机到生产级容器，站长手把手教你Docker部署项目的正确姿势
2.1 先放行 SSH，再启用防火墙
这是血泪教训。笔者见过不止一个新手，兴冲冲地 ufw enable 之后，SSH 连不上了，只能去云控制台开 VNC 救火。正确顺序是：先确认 SSH 端口，再放行，最后才启用。
# 如果你改过 SSH 端口，比如 22222
sudo ufw allow 22222/tcp
# 如果还是默认 22
sudo ufw allow 22/tcp
# 确认规则已加入，再启用
sudo ufw enable强烈建议生产环境不要用默认 22 端口。换一个高位端口，配合密钥登录，能挡掉绝大部分自动化爆破。这一步的收益，比装任何防护软件都直接。
2.2 开放 80 与 443：Web 服务的基本盘
HTTP 和 HTTPS 是绝大多数站点必须开放的端口。写法有两种，效果一样，但推荐带上协议：
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp这里有个细节值得展开：80 和 443 是否都要开？ 如果你的站点已经全站 HTTPS，并且配置了 80 到 443 的 301 跳转，那么 80 仍然需要开——因为跳转动作本身就要先建立 HTTP 连接。除非你用 HSTS 预加载，否则别把 80 关死。另外，Let’s Encrypt 的 HTTP-01 验证也依赖 80 端口，证书自动续期时如果 80 不通，续期就会失败，某天突然发现证书过期，站点报警，那就尴尬了。
2.3 业务端口的开放策略
数据库、缓存、内部 API 这类业务端口，原则只有一条：能不开公网就不开公网。MySQL 的 3306、Redis 的 6379，一旦暴露在公网，被扫到只是时间问题。如果应用和数据库在同一台机器，直接监听 127.0.0.1，UFW 都不用动。
如果确实需要跨机访问，正确的做法是限制来源 IP：
# 只允许指定 IP 访问 3306
sudo ufw allow from 203.0.113.45 to any port 3306 proto tcp
# 允许整个内网段访问 Redis
sudo ufw allow from 10.0.0.0/24 to any port 6379 proto tcp这种「白名单式」开放，比单纯 allow 端口安全得多。下面这张表是我常用的端口开放参考：
| 端口 | 用途 | 建议策略 |
|---|---|---|
| 22 / 自定义 | SSH 管理 | 改高位端口 + 密钥登录 |
| 80 | HTTP / 证书验证 | 公网放行 |
| 443 | HTTPS | 公网放行 |
| 3306 | MySQL | 仅内网或指定 IP |
| 6379 | Redis | 仅内网，禁用公网绑定 |
| 8080 等 | 业务 API | 优先走 Nginx 反代，不直接暴露 |
三、加固与调优清单
💡 深度技术指南：Docker 容器又双叒叕起不来？别慌，这几个高频报错我帮你踩平了
基础规则配好之后，下面这几项是我每台服务器都会做的加固动作。
3.1 开启日志，别做睁眼瞎
sudo ufw logging on
sudo ufw logging medium日志默认在 /var/log/ufw.log，被拦截的连接都会记录。配合 fail2ban 使用，能自动封禁反复尝试的 IP。这一步几乎零成本，但排查问题时价值极高。
3.2 限速防爆破
sudo ufw limit 22/tcplimit 会在 30 秒内同一 IP 连接超过 6 次时自动拒绝，对付 SSH 暴力破解很有效。注意它和 allow 是互斥的，同一个端口不要重复配置。
3.3 定期审计规则
sudo ufw status numbered
sudo ufw delete [编号]规则是会腐烂的。半年前临时开的端口，项目下线了却忘了关，这种「僵尸规则」是常见的安全盲区。笔者习惯每季度过一遍，把不再需要的规则删掉。
3.4 IPv6 别漏了
在 /etc/default/ufw 里确认 IPV6=yes。很多服务器 IPv6 是通的，但 UFW 没管，等于开了个后门。
四、验证测试与 SOP 总结
配置完一定要验证，别凭感觉。本地用 ss -tlnp 看监听，外部用 telnet 或在线端口检测工具测连通性。特别注意：本机 telnet 127.0.0.1 通，不代表外网通，因为 UFW 管的是外部入站，本地回环不受影响。测外网要从另一台机器发起。
最后，把整套流程固化成 SOP：
- 新机到手，先设默认策略 deny incoming / allow outgoing。
- 改 SSH 端口，放行新端口，确认能连，再 enable。
- 按业务需求开放 80/443，业务端口一律走白名单或内网。
- 开启日志，配 fail2ban，SSH 加 limit。
- 每季度审计规则，清理僵尸端口。
顺便提一句，防火墙只是第一道门。选一台网络质量靠谱的云服务器、配一个正规备案的域名，这些基础打好了，后面的运维才省心。别为了省几十块钱选来路不明的小商家，真出问题时，丢的数据和时间远比差价贵。
UFW 本身不复杂，复杂的是「想清楚每个端口为什么开」。把这件事想明白了，你的服务器安全水平就已经超过大多数人了。