公司内网突然打不开某个合作方的API接口，但手机用同一Wi-Fi却能访问——十有八九是防火墙在“悄悄拦截”。别急着重启设备，先搞清楚防火墙到底在查什么、怎么查，比盲目调配置管用得多。
一、看日志，是最直接的“审讯记录”
防火墙不像人会说话，但它会记账。几乎所有主流防火墙（华为USG、深信服AF、FortiGate、甚至Windows自带防火墙）都支持日志输出。重点盯三类字段：
- 源IP/目的IP：确认是不是你本机发出去的包被拦了；
- 协议+端口：比如TCP 443通了但UDP 53不通，DNS就可能卡住；
- 动作（Action）：deny、drop、reject 是关键信号，不是“没反应”，而是明确拒绝了。
以Linux iptables为例，查实时拦截记录可以这样：
sudo iptables -L -n -v | grep DROP如果看到大量匹配某条规则的包计数猛增，基本就是它干的。
二、抓包验证：让流量自己开口说话
日志只说“拒了”，但未必知道包到底有没有发出去、发到哪一层。这时候就得上抓包工具。
在客户端（比如你的开发机）用Wireshark或tcpdump抓本地出口流量：
tcpdump -i eth0 'host 192.168.10.50 and port 8080' -w debug.pcap然后发起一次请求。如果pcap里只有SYN包、没有收到SYN-ACK，说明连接在半路被掐了——大概率是防火墙丢包；如果SYN-ACK回来了但应用层没响应，问题可能出在后端服务或中间代理上。
三、绕过策略，做最小化验证
临时放行一个测试规则，是最粗暴也最有效的验证方式。
比如你在排查“为什么微信小程序后台收不到回调”，而回调地址是 https://api.example.com/webhook，可以临时加一条允许规则：
iptables -I INPUT -p tcp --dport 443 -s 119.29.29.29 -j ACCEPT（注：119.29.29.29 是腾讯云部分出口IP，实际请查微信官方文档提供的IP段）
加完立刻试一次回调。通了，说明原策略太严；不通，问题就不在防火墙本身。
四、别忘了状态检测这回事
很多现代防火墙默认开启连接状态跟踪（stateful inspection）。它不单看单个包，还看整个会话是否合法。
典型症状：HTTP能通，FTP被动模式死活连不上；或者UDP语音通话前几秒正常，之后断流。这是因为FTP的data port、UDP的回包端口不在初始规则范围内，状态机判定为“非法返回流量”直接丢弃。
临时解决办法：启用对应协议的ALG（应用层网关）模块，或手动放行相关端口范围，比如FTP的20-21 + 1024-65535。
五、检查顺序建议（按优先级）
遇到连不通的问题，照这个顺序查，少走弯路：
- 目标服务器是否真在线？（先ping、telnet端口）
- 本机防火墙（Windows Defender / macOS Firewall / iptables）是否挡路？
- 出口网关或企业防火墙是否有策略拦截？
- 中间设备（如负载均衡、WAF）是否做了额外过滤？
- 最后才怀疑目标服务本身挂了。
记住：防火墙不会“猜你想干什么”，它只忠实地执行你写的每一条规则。查它，本质是查你自己写的策略有没有漏、有没有错、有没有过时。