常见安装与防火墙故障排查方法

在企业内部经常会碰到新服务上线后端口不通的尴尬，往往不是代码本身的毛病，而是安装步骤或防火墙策略的细节被忽略了。下面把几种最常见的场景拆开来聊，既有新手常踩的坑，也有经验丰富的同事会忽视的细节。

安装阶段的“盲点”

• RPM 包来源不一致：有的系统默认仓库里根本没有最新版本，直接 yum install 会得到旧版依赖，导致服务启动后报错。建议先检查 /etc/yum.repos.d 中是否已经添加官方或可信的第三方 repo。
• 系统服务未注册：在 CentOS 7 之后，systemctl 接管所有守护进程。即便手动执行了二进制文件，若没有创建对应的 .service 单元，重启后会“消失”。快速检查方式是 systemctl list-unit-files | grep -i yourservice。
• SELinux 仍然处于 enforcing 模式：很多文档只提醒关闭防火墙，却忘了 SELinux 同样会拦截端口绑定。通过 getenforce 看状态，必要时用 setsebool -P httpd_can_network_connect on 放通。

防火墙故障排查的“三步走”

• 确认防火墙是否激活：firewall-cmd --state 返回 running 则说明在生效，否则所有端口检测都毫无意义。
• 核对服务对应的 zone 与端口：firewall-cmd --list-all 会列出当前 zone 的开放端口与服务名。常见误区是把 http（80）和 https（443）写成了 tcp/8080，导致实际监听的 8080 被误拦。
• 即时测试：curl -I http://127.0.0.1:8080 能通则说明本机防火墙放通，若失败则用 firewall-cmd --add-port=8080/tcp --permanent 再 --reload。

有一次同事部署了一个基于 Node.js 的 API，日志里全是 EADDRINUSE，结果却在 netstat 看不到占用的端口。追根溯源后发现防火墙的 rich rule 把该端口的入站流量直接丢弃，服务虽然成功绑定，却收不到任何请求。把规则删掉后，API 瞬间恢复。

“在排查网络连通性时，先把防火墙当成‘黑盒子’，把所有可能的过滤规则列出来，再逐项验证，这比盲目重启服务更省事”。

所以，别把安装成功当作结束，也别把防火墙的默认状态当作理所当然。把每一步都写进检查清单，哪怕是一次小小的 --list-all，也能在问题爆发前给你留出修正的余地。