服务器防火墙别再裸奔了！UFW 开放 80、443 和业务端口，这份配置指南比你想的更细

选型背景：为什么我们还需要手动配置 UFW？

很多站长在购买云服务器后，第一件事就是装宝塔面板或者用云平台自带的安全组。但说实话，安全组是云平台层面的“门卫”，而系统内部的防火墙（如 UFW）才是你服务器自己的“防盗门”。两者缺一不可，尤其是当你使用 Docker 映射端口、或者跑一些非标准业务端口时，UFW 的灵活性和精确度是安全组无法替代的。

笔者在过去几年运维过不下 50 台 Linux 服务器，踩过最大的坑就是：安全组全放行了，结果 UFW 默认策略是拒绝，导致网站 80 端口死活打不开。反过来，也有朋友把 UFW 直接禁用，结果服务器被爆破 SSH。今天这篇指南，咱们就把 UFW 这块硬骨头彻底啃下来，重点讲透如何正确开放 80、443 以及那些“特定业务端口”。

核心参数对比：UFW 与主流防火墙管理工具横向评测

💡 延伸阅读：WordPress 后台卡成幻灯片？数据库一直膨胀？清理修订版本和瞬态数据才是根治之道

在动手之前，我们先来直观地看一下 UFW 相较于其他防火墙工具（firewalld、iptables 原生、云安全组）的定位。这样你就能明白，为什么在 Ubuntu/Debian 环境下，UFW 是性价比最高的选择。

对比维度	UFW (Uncomplicated Firewall)	firewalld (CentOS/RHEL)	iptables (原生)	云平台安全组
上手难度	⭐ 极简（命令短，语法直白）	⭐⭐⭐ 中等（需要理解 zone 概念）	⭐⭐⭐⭐⭐ 极高（链、表、规则逻辑复杂）	⭐ 简单（网页点击配置）
性能开销	极低（底层还是调用 iptables，但规则优化好）	低（动态管理，但服务进程占用稍高）	极低（内核级直接执行）	无（在虚拟化层过滤）
适用场景	Debian/Ubuntu 单机防护、LNMP/LAMP 环境	RHEL 系服务器、需要动态 zone 切换的复杂网络	极客定制、网关路由、需要精确控制每个数据包	云服务器第一层防护、跨地域白名单
优势	配置直观，支持应用配置文件，适合新手和运维老手	支持运行时修改，不用 flush 所有规则	功能最强大，无任何封装	不占用系统资源，防 DDoS 基础能力
劣势	仅限 Linux 系，不支持 Windows	命令冗长，记忆成本高	规则重启即失，必须保存脚本，极易出错	无法控制容器内部流量，依赖网络环境

结论：对于绝大多数使用 Ubuntu 22.04/24.04 或 Debian 12 的站长来说，UFW 就是“最优解”。它既有 iptables 的硬核能力，又有类似安全组的傻瓜式操作。

方案 A 深度评测：基础 WEB 服务（80/443）开放实操

💡 深度技术指南：别再纠结2核2G还是2核4G了！实测数据告诉你性能差距，钱花得明明白白

这是最核心的需求。很多教程只告诉你 ufw allow 80，但忽略了前置条件——默认策略。

第一步：设置默认策略（拒绝一切入站）

这一步至关重要。如果不先设置 DROP 策略，你开放端口就失去了意义。

sudo ufw default deny incoming
sudo ufw default allow outgoing

这里解释一下逻辑：入站全拒，出站全放。这意味着除了你明确允许的端口，外部任何连接尝试都会被丢弃，而你的服务器主动访问外网（比如 yum 更新、API 回调）不受影响。

第二步：开放 80 和 443

这里推荐使用服务名而非端口号，UFW 会自动映射到 /etc/services 文件。

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

如果你需要同时开放 HTTP/HTTPS，也可以偷懒用 sudo ufw allow 'Nginx Full'（前提是你装了 Nginx）。但笔者更推荐手动写端口，因为有些环境用的是 Apache 或者 Caddy，服务名会识别失败。

进阶技巧：如果你只是临时测试，或者不想让搜索引擎抓取到未备案的 IP 访问，可以限制来源 IP：

sudo ufw allow from 114.114.114.114 to any port 80 proto tcp

这样只有你指定的 IP 能访问 80 端口，其他人全部超时。

第三步：验证与重启

sudo ufw enable
sudo ufw status verbose

看到 Status: active 且 80、443 规则前有 ALLOW 字样，说明配置成功。此时记得去云控制台把安全组的 80/443 也放行，双层保险。

方案 B 深度评测：特定业务端口（如 3000、8080、数据库）的高危管控

业务端口是重灾区。很多站长图省事，直接 ufw allow 3000，结果把 Redis、MongoDB 暴露在公网，被勒索病毒盯上。正确的姿势必须结合 IP 白名单。

场景一：Node.js 应用端口（3000）仅限本机反代访问

如果你的 Nginx 在 80 端口，Node.js 在 3000 端口，那么 3000 端口完全不需要对公网开放。只需要让 Nginx 能访问即可。

# 只允许来自本机的连接访问 3000 端口
sudo ufw allow from 127.0.0.1 to any port 3000 proto tcp
# 如果你有内网其他服务器需要直接访问，加上内网 IP
sudo ufw allow from 192.168.1.100 to any port 3000 proto tcp

注意：绝对不要执行 ufw allow 3000，除非你想让全世界的人都能扫到你的应用调试端口。

场景二：MySQL/MariaDB 数据库端口（3306）

数据库端口必须绑定内网 IP。假设你的应用服务器是 10.0.0.2，数据库服务器是 10.0.0.3：

# 在数据库服务器上执行，仅允许应用服务器连接
sudo ufw allow from 10.0.0.2 to any port 3306 proto tcp

这样配置后，即使数据库密码泄露，外部黑客也无法直接连接，因为 UDP/TCP 握手直接被系统防火墙丢弃。

场景三：SSH 端口（22）防爆破

这是老生常谈。强烈建议修改默认 SSH 端口，并在 UFW 中做双重限制。

# 假设你已将 SSH 改为 2222 端口，且办公网 IP 为 8.8.8.8
sudo ufw allow from 8.8.8.8 to any port 2222 proto tcp

评测心得：UFW 对 IP 段的支持也极好，比如你公司是动态 IP，可以写 sudo ufw allow from 8.8.8.0/24 来覆盖整个 C 段。

选型建议与最终配置清单

基于上述实操对比，笔者给出以下最终建议，你可以直接复制使用。

生产环境一键配置脚本（Ubuntu/Debian）

#!/bin/bash
# 重置 UFW（如有旧规则）
sudo ufw --force reset

# 设置默认策略
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 开放核心 Web 端口
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 开放 SSH（请将 2222 替换为你实际的 SSH 端口）
sudo ufw allow from 你的办公IP/32 to any port 2222 proto tcp

# 开放内网数据库端口（按需取消注释）
# sudo ufw allow from 10.0.0.2 to any port 3306 proto tcp

# 开放内网 Redis 端口（务必绑定内网）
# sudo ufw allow from 10.0.0.2 to any port 6379 proto tcp

# 启用并查看状态
sudo ufw enable
sudo ufw status numbered

为什么强烈建议你买台靠谱的服务器？

UFW 配置得再好，如果底层 VPS 厂商频繁掉线、数据丢包，那也是白搭。防火墙只是软件层面的第一道防线，硬件的稳定性（CPU 主频、NVMe 磁盘 IO、网络线路质量）才是业务长跑的基石。笔者建议大家在选购云服务器时，不要只盯着 99 元一年的低价款，要重点关注云厂商的 SLA 承诺和带宽是否 BGP 多线。毕竟，你花半小时配好的 UFW 规则，如果因为服务器宕机而无法生效，那才是真正的损失。

写在最后

UFW 并不复杂，复杂的是你对业务端口的梳理习惯。很多“莫名其妙”的安全事故，追根溯源都是因为懒——ufw allow 8080 一键放行，图一时痛快。希望这篇文章能帮你建立起“最小化暴露”的防火墙思维：能不开的端口坚决不开，能绑定 IP 的坚决不绑 0.0.0.0。配置好 UFW 后，记得用 nmap -sS 你的服务器IP 从外部扫一遍，看看是否还有遗漏的高危端口。安全无小事，共勉。