应用 profile 省掉了什么
手写端口放行容易漏项：Nginx 要开 80 与 443，邮件服务要开若干端口，写错一个就会出现「部分能用」。ufw 的应用 profile 把常用服务的端口组合固化成模板，放行时按服务名操作，减少手工出错面，也让规则更易读。
基本信息
| 适用平台 | Linux（Ubuntu/Debian 系，ufw） |
|---|---|
| profile 目录 | /etc/ufw/applications.d/ |
| 常用命令 | ufw app list、ufw app info、ufw allow <profile> |
| 基线 | 仅放行实际安装并对外提供服务的端口组合 |
典型使用场景
- 新服务上线：直接按 profile 放行标准端口组合，避免漏端口
- 规则复盘：用 ufw status 看到的是服务名，阅读成本更低
- 自研服务：仿照内置文件格式定义自有 profile，统一团队写法
- 容器宿主：容器映射的端口仍需显式放行，profile 不能替代
查看与应用
查看与应用
# 列出可用的应用模板
sudo ufw app list
# 查看某个模板包含哪些端口
sudo ufw app info 'Nginx Full'
# 按模板放行
sudo ufw allow 'Nginx Full'
# 复核当前规则
sudo ufw status verbose常见模板读法
| 模板名 | 包含端口 | 放行前要确认 |
|---|---|---|
| OpenSSH | 22 | 管理入口，建议配合 limit |
| Nginx HTTP | 80 | 是否真的对外提供 HTTP |
| Nginx Full | 80 与 443 | 两项都要开吗，多余端口应拆开 |
| Nginx HTTPS | 443 | 证书与协议版本是否就绪 |
自定义服务可仿照 /etc/ufw/applications.d/openssh-server 的格式添加 profile：把业务的端口组合固化成模板，团队内规则写法就能统一。
profile 只是端口组合的别名，不代表服务安全：放行之后服务本身的加固、版本更新与访问来源限制一样都不能省。
自定义 profile 示例
自定义 profile 示例
# 自研服务也可以定义模板，统一团队写法
# /etc/ufw/applications.d/qiqicto-app
# [qiqicto-app]
# title=业务应用
# description=对外提供 HTTP 与 HTTPS
# ports=80,443/tcp
# 生效后即可按名称放行
sudo ufw app list | grep -i qiqicto放行后做一次外部可达性验证：从另一台机器探测端口，确认规则真正生效，避免因 profile 名拼写或规则顺序问题造成「看起来配好了但外部不通」。
规则数量增长后改用 profile 更能看清意图：ufw status 里显示服务名比一串端口号更易复核，交接时也更省沟通成本，团队内务必要用同一套写法。