Java应用网络不通需按链路顺序排查：先确认firewalld或iptables服务状态及默认策略，再检查OUTPUT/INPUT链对目标端口和ESTABLISHED连接的放行规则，结合nc/telnet验证TCP连通性，辅以conntrack和dmesg日志定位真实拦截点。
Java 应用部署在 Linux 线上环境后出现网络不通（比如调用外部 HTTP 接口超时、数据库连不上、注册中心失联），不能只盯着应用日志——很多问题根源在系统网络层，尤其是 iptables 或 firewalld 防火墙规则的拦截。排查要从“是否能通”转向“为什么被拦”，按真实链路顺序验证。
确认防火墙服务状态和基础规则
先看防火墙有没有在运行，再快速扫一眼默认策略和关键链：
- 查 firewalld 是否启用：
sudo firewall-cmd --state；若返回running，继续执行sudo firewall-cmd --list-all查当前 zone 规则 - 查 iptables 是否生效：
sudo iptables -L -n -v（加-v看命中计数）；重点关注INPUT和OUTPUT链的policy（默认是 ACCEPT 还是 DROP） - 注意：firewalld 和 iptables 不应共存；若 firewalld 正在运行，
iptables -L可能显示空或过时规则，实际生效的是 firewalld 后端的 nftables 或 iptables-wrapper 规则
定位 Java 进程的出向流量是否被拦
Java 应用发起的请求属于 本机出向（OUTPUT）+ 外部入向响应（INPUT） 流量，重点检查这两类规则：
- 查看 OUTPUT 链是否限制了目标端口或协议：
sudo iptables -L OUTPUT -n -v | grep -E "(80|443|3306|2181|8080)"（根据你调用的服务替换端口） - 检查是否有基于状态的拦截：
sudo iptables -L INPUT -n -v | grep "RELATED,ESTABLISHED"—— 若缺失这条 ACCEPT 规则，返回包会被丢弃，导致“请求发出去但没响应” - 用
sudo ss -tunlp | grep java确认 Java 进程监听的端口（如 8080），再查对应 INPUT 规则是否放行该端口
用 netcat 和 telnet 模拟 Java 的实际连接行为
ping 只测 ICMP，而 Java 调用走的是 TCP；必须用 TCP 工具验证端到端连通性：
- 测试目标服务端口是否可达：
nc -zv api.example.com 443或telnet redis.host 6379 - 若失败但 ping IP 成功，说明不是路由问题，而是防火墙或目标服务未监听/拒绝连接
- 特别注意：有些云厂商安全组或主机防火墙会拦截
nc的探测包；可加-w 3设置超时，避免卡住
临时绕过防火墙验证是否为根因
不是为了长期关闭，而是快速闭环判断：
- firewalld 临时清空：
sudo firewall-cmd --panic-on（开启紧急模式，立刻阻断所有非白名单流量）→ 若此时 Java 调用恢复，说明原规则有问题；再用--panic-off恢复 - iptables 临时放行所有出向：
sudo iptables -I OUTPUT -j ACCEPT，测试后立即删掉：sudo iptables -D OUTPUT 1 - ⚠️ 生产环境慎用；建议在测试窗口期操作，并配合
iptables-save > /tmp/iptables.bak备份原始规则
结合 conntrack 和日志交叉验证
仅看规则不够，要看实际数据包是否被 drop：
- 查连接跟踪状态：
sudo conntrack -L | grep "dport=443" | head -10，观察 state 是否为ESTABLISHED或大量INVALID - 查内核丢包日志：
sudo dmesg -T | grep -i "drop\|reject\|iptables"，常有类似IN= OUT=eth0 SRC=... DST=... PROTO=TCP SPT=... DPT=443 ... DROP的记录 - 检查
/var/log/ufw.log（Ubuntu）或/var/log/firewalld（CentOS/RHEL），确认是否有匹配日志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
