Linux怎么查看网络连接拦截原因

如何检查iptables或nftables是否拦截了流量呢？首先，你得运行sudo iptables -L -n -v来检查INPUT/FORWARD链以及默认策略，或者用sudo nft list ruleset查看drop/reject规则。然后，还得结合firewalld状态、conntrack表使用率以及云安全组等进行多层排查。

查 iptables 或 nftables 是否拦截流量

大多数 Linux 服务器默认用 iptables 或 nftables 做包过滤，连接被拒往往就卡在这层。别急着关防火墙，先看规则里有没有明确 DROP 或 REJECT 的条目。

• 运行 sudo iptables -L -n -v：重点看 INPUT 和 FORWARD 链，最后一行是默认策略（如 policy DROP），比规则本身更危险
• 若系统用 nftables（较新发行版默认），执行 sudo nft list ruleset；注意是否有 drop、reject 语句匹配目标端口或 IP
• 临时放通测试：比如想确认 80 端口是否被拦，可加一条 sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT，再试连接。成功即说明原规则在拦截

检查 firewalld 是否启用并限制端口

firewalld 是 CentOS/RHEL/Fedora 默认的防火墙管理器，它不直接暴露底层规则，容易让人误以为“没开防火墙”。实际它可能静默拦截，尤其对非标准端口。

• 确认状态：sudo firewall-cmd --state，输出 running 表示已启用
• 查当前开放端口：sudo firewall-cmd --list-ports，若目标端口（如 5574）不在列表中，就是被拦了
• 查服务级配置：sudo firewall-cmd --list-services，有些服务（如 http）会批量放行端口，但自定义服务需显式添加
• 临时放开端口测试：sudo firewall-cmd --add-port=5574/tcp --permanent && sudo firewall-cmd --reload

确认连接是否被 conntrack 或内核模块丢弃

某些场景下，连接看似“超时”或“拒绝”，其实不是防火墙干的，而是连接跟踪表满、SYN 包被内核丢弃，或 netfilter 模块异常。这类问题不会出现在 iptables 规则里，得看内核日志。

• 抓实时丢包信息：sudo dmesg -T | grep -i "dropped|nf_conntrack|synproxy"，常见提示如 nf_conntrack: table full 或 kernel: [xxx] TCP: drop open request
• 检查连接跟踪表使用率：cat /proc/sys/net/netfilter/nf_conntrack_count 对比上限 cat /proc/sys/net/netfilter/nf_conntrack_max，超 90% 就容易丢包
• 临时扩容（仅应急）：echo 65536 | sudo tee /proc/sys/net/netfilter/nf_conntrack_max

验证是否被云平台安全组或宿主机防火墙拦截

在云服务器（阿里云、腾讯云、AWS）或虚拟机环境中，Linux 本机的防火墙只是最后一道防线。前面还有安全组、VPC 网络 ACL、宿主机 iptables，它们优先级更高，且你根本看不到。

• 登录云控制台，检查对应实例的“安全组规则”，确认入方向（Inbound）是否放行目标协议+端口（如 TCP/5574）
• 特别注意：安全组规则是“白名单”，未显式允许的全部拒绝；哪怕 iptables 全放通，安全组没开照样不通
• 如果是 KVM/LXC 宿主机，运行 sudo iptables -t nat -L -n 查看 PREROUTING 链，宿主机可能做了 DNAT 或直接 DROP

真正难排查的，往往是“多层防火墙叠加”——比如安全组开了 22 端口，但宿主机 iptables DROP 了所有非 10.0.0.0/8 流量，而你的访问 IP 不在该网段。这种情况下，iptables -L 看起来干净，firewall-cmd 显示正常，但连接就是不通。得一层层往上翻，不能只盯着本机。