宝塔网站打不开但防火墙开着，首要检查80/443端口是否真被系统防火墙（firewalld或ufw）永久放行且生效，再确认云平台安全组、端口监听地址（如0.0.0.0:80）、Nginx服务状态及日志报错。
宝塔面板网站打不开，但防火墙开着：先确认80/443是否真被放行
系统防火墙（firewalld 或 ufw）开启后网站打不开，最常见的情况不是“没加规则”，而是规则加了但没生效、加错链、或被其他策略覆盖。比如用 firewall-cmd --add-port=80/tcp 临时添加，却忘了加 --permanent，重启后就消失；又或者在 ufw 里执行了 ufw allow 80，但之前已设 ufw default deny incoming，而规则顺序导致未命中。
- 检查当前生效规则：
firewall-cmd --list-all（CentOS/RHEL）或ufw status verbose（Ubuntu/Debian），重点看80/tcp和443/tcp是否出现在ports列表且状态为allowed - 若只看到临时规则（
firewall-cmd输出不含permanent字样），必须补加--permanent并执行firewall-cmd --reload -
ufw用户注意：规则按添加顺序匹配，deny在前、allow在后会导致后者无效；可用ufw status numbered查序号，必要时用ufw delete N调整
云厂商安全组和系统防火墙是两层独立过滤，缺一不可
很多人以为开了系统防火墙就不用管安全组，或反之——这是最大误区。云服务器流量路径是：公网 → 云平台安全组 → 系统防火墙 → 服务进程。任一层 DROP 都会导致连接失败，且错误现象完全一样（浏览器显示“拒绝连接”或超时）。
- 安全组规则必须显式放行
80和443端口，协议选TCP，源 IP 建议先设0.0.0.0/0测试，生产环境再收紧 - 阿里云/腾讯云等控制台中，“入方向”规则列表需手动刷新，新增规则有时存在 1–2 分钟延迟，不要刚点保存就立刻测试
- 若同时用了宝塔的“安全”页面开关防火墙，它只操作系统级规则（如
iptables），对云平台安全组无任何影响——这点极易被忽略
端口冲突或监听地址绑定错误，会让放行规则形同虚设
即使防火墙和安全组都放行了 80，如果 Nginx 没监听 0.0.0.0:80，或被其他进程（如 Apache、Python HTTP 服务）占着端口，外部请求根本到不了 Web 服务，放行再多也没用。
- 查端口占用：
netstat -tuln | grep ':80\|:443'，确认输出中LISTEN的 PID 属于nginx或httpd，而非python、node等意外进程 - 查 Nginx 实际监听地址：
nginx -T 2>/dev/null | grep "listen.*80"，确保含0.0.0.0:80或*:80，而非仅127.0.0.1:80（后者只能本地访问） - 宝塔建站后默认启用 HTTPS 强制跳转，若 SSL 证书未正确部署，
443端口可能监听失败，导致整个站点不可达——此时curl -I http://your-domain会卡住或返回 502
日志里藏着真实拦截点，别只盯着“防火墙已开”
很多用户反复确认“防火墙开了”“安全组放了”，但就是打不开，最后发现是日志里一句 connection refused 暴露了本质：请求压根没到 Web 服务。这时候该看三类日志：
-
/www/wwwlogs/error.log：Nginx 报错，如connect() failed (111: Connection refused) while connecting to upstream，说明 PHP-FPM 挂了，和防火墙无关 -
journalctl -u nginx -n 50 --no-pager：Nginx 启动失败原因，常见于配置语法错误或端口被占 -
sudo tail -f /var/log/ufw.log或sudo journalctl -u firewalld | grep drop：直接确认是不是防火墙在 DROP 请求——如果这里没日志，问题一定在更上层（安全组）或更下层（服务未监听）
真正麻烦的从来不是“要不要开防火墙”，而是“哪一层在拦、为什么拦、拦的是谁”。云环境的网络链路天然多层，每层都有自己的规则集和生效逻辑，同步不及时、配置不一致、日志不互通，才是日常排障最耗时间的地方。
