我经常被同事问一个问题：“咱们的进出口流量到底通不通？”这个问法听起来很直白，但真上手排查时，往往发现没这么简单。前一阵有个新业务上线，出口方向流量告警频繁，内网Ping网关一切正常，业务却时断时续。后来我从链路、路由、策略一层层剥开，才发现问题出在防火墙策略命中顺序和NAT会话超时上，和物理链路一点关系都没有。这篇文章我想把平时判断进出口流量能否通行的一套方法完整梳理一遍，包括命令、抓包思路、防火墙策略审计和几个经典故障复盘，适合网络运维、系统管理员，以及刚接手网络排查的朋友参考。
1. 判断进出口流量之前，先把“通行”拆成三个层次
1.1 入口流量和出口流量，先别混为一谈
“进出口流量”在不同场景下含义不一样。这里聊的是网络侧的进出口流量，更准确地说，是数据中心或企业内部网络两个方向的数据流：
- 出口流量：内网终端或服务器发往外部业务系统的流量。
- 入口流量：外部用户或合作伙伴访问内网服务的流量。
这两个方向往往不是同一条路径。就算物理上走的都是同一个出口设备，入口流量要经过的外部路由、NAT映射、防火墙规则，和出口流量也完全可能不一样。很多故障只出现在一个方向：内部访问外部一切正常，外部访问内部就是连不上；或者外部访问没问题，内部发外部却被某种策略卡住。所以在开始排查之前，先确认你是在判断“出去能不能通”，还是在判断“进来能不能通”，方向都搞错，后边全是白忙。
1.2 把“通行”拆成三层，排查才不会乱
我习惯把“能否通行”拆成三个层次：
- 连通性：链路通不通，端口 up 没 up，IP 能不能互相 Ping 通。
- 路径正确性：数据包有没有走到预想的下一跳，有没有被策略路由绕到别处，有没有被 ACL 或防火墙拦截。
- 承载质量：通了之后是否顺畅，丢包率、延迟、抖动、带宽利用率、会话数是否在合理范围内。
这三层用一个开车出行的例子很好理解。第一层是“路有没有断”，第二层是“导航路线对不对”，第三层是“路上堵不堵”。很多故障并不是“全不通”，而是“通但不顺”。如果一上来就只关注 Ping 通没通，很可能漏掉真正的问题。
1.3 没有历史基线，很多判断都是猜
我踩过几次坑之后，现在特别强调基线数据。没有正常时段的延迟、丢包率、接口带宽和会话数，排查时根本分不清当前是“一直如此”还是“刚刚发生变化”。比如一条链路延迟平时就是 50 毫秒，故障时还是 50 毫秒，那就不是链路质量问题；但如果没有历史数据，看到 50 毫秒可能也会怀疑。
建议日常把以下内容保存起来：
- 关键节点之间双向的 Ping 延迟和丢包结果。
- 重要路径的 MTR 输出。
- 核心业务端口 TCP 连通性状态。
- 出口设备的接口速率、带宽利用率和并发会话数。
- 防火墙会话表总量和 NAT 地址池使用率。
这些数据不需要复杂平台，写一个定时脚本把命令输出追加到日志文件就够用。配置变更前还要另外导出当前配置和会话状态。有了这些，再遇到“进出口流量是否通行”之类的问题时，你就是在做对比分析，而不是现场猜谜。
2. 从物理链路到应用层，逐层确认“通行”状态
2.1 先看物理层：端口状态、光模块、错误计数
如果物理端口都 down 了，判断通行为零。首先要确认端口状态、速率和双工模式。常见问题是对端设备自协商失败，端口显示 up，但跑在 100M 半双工，导致大量冲突和错包。
光模块也比较容易忽视。光功率过高或过低，都会造成信号劣化，进而产生 CRC 错误、FCS 错误和输入丢包。在 Linux 上可以用 ethtool 查看光模块信息，也可以直接看接口统计：
ethtool eth0 ip -s link show eth0重点看 TX/RX errors、dropped、CRC errors，以及重传计数。如果有持续的 CRC 增长，多半是光纤跳线接头脏了、弯曲半径太小或者光模块老化。重新插拔清洁、更换跳线后，错误计数不再增长，问题通常就解决了。
2.2 二层链路：VLAN 与 Trunk 经常成为隐形断路
很多出/入口流量并不只是经过一台路由器，而是先从接入交换机跑到汇聚交换机，再上行到防火墙或出口路由设备。中间通常有 VLAN 和 Trunk 配置。这类问题最典型的表现是：只有部分终端访问外部异常，其他终端正常。
排查时在每台交换机上确认接口的链路类型、允许通过的 VLAN、PVID 是否正确。比如 Trunk 口只放行了 VLAN 10，而出口网关实际在 VLAN 20 里，那流量到了汇聚就会被丢掉。生成树阻塞也可能是原因，接口反复 up/down 或处于 Blocking 状态，二层转发就不通。
还要看 MAC 地址表有没有漂移。如果同一台终端的 MAC 在多个接口之间反复出现，说明网络可能存在环路，或者两个接口误接了同一根线，导致数据帧乱跳。
2.3 三层路由：默认路由、ARP、路由优先级
三层连通性是判断通行最核心的一环。在出口设备上查看路由表，确认是否有去往目标网段的路由，以及默认路由是否指向正确的下一跳。
ip route show如果路由表里有条目，但 Ping 下一跳不通，就需要检查 ARP。查看 ARP 表，确认能否解析到下一跳设备的 MAC 地址：
ip neigh show解析不到通常是下一跳 IP 不在同一个网段、VLAN 不对，或者对端设备接口被你隔离了。还要注意多路由场景下的优先级：配置了多条默认路由时，如果管理距离或优先级设置不合理，流量可能走了备用的错误路径，表现就是“能通但不该这么走”，或者“通一阵断一阵”。
2.4 传输层和应用层：端口、DNS、HTTP 响应
三层通了，不代表业务一定能通。还要在传输层和应用层做验证：
- 测试 TCP 端口：
nc -vz -w 3 <目标IP> <端口> - 测试 HTTP 服务：
curl -sv https://目标域名/health - 检查域名解析：
dig @<DNS服务器> 目标域名或nslookup 目标域名
很多“进出口不通”的案例，查到最后是 DNS 解析超时。服务器配置的 DNS 地址不可达，或者上游 DNS 只允许特定接口访问，UDP 53 被防火墙拦掉，都会导致域名解析失败。业务连着连着就说“网络断了”，实际问题是域名解析压根没返回。
3. 上手最快的五条诊断命令和实战解读
3.1 ping：只能证明小包能通，不能证明业务能通
Ping 是所有人第一个想到的工具。步骤一般是先 Ping 网关，再 Ping 对端 IP：
ping -c 4 10.0.0.1 ping -c 4 202.96.128.86Ping 通能够排除物理链路和基本 IP 配置问题，但它的能力有限。ICMP 走的是网络层协议，和 TCP 80/443 走的是不同协议栈；而且很多设备会优先处理或限速 ICMP 报文。你 Ping 通了，只能说明路没断，不能说明业务端口放行了，更不能说明应用层可以正常工作。所以 Ping 只作为第一步，不要拿它当最终结论。
3.2 MTR：把每一跳的丢包和延迟一起看
MTR 是 traceroute 和 ping 的结合体，能一次性看到从源到目的每一跳的丢包和延迟。推荐用法：
mtr -rwz -c 100 目标IP输出中每一跳都有 Loss% 和延迟统计。读 MTR 结果有个很重要的经验：中间某一跳丢包高，不一定代表链路有问题，因为它可能只是不回复 ICMP，或者管理面被限速。关键是看最后几跳，以及最终目标地址那一跳的丢包和延迟。
如果最后一跳持续丢包超过 1%，且延迟忽高忽低，就要怀疑链路质量或带宽瓶颈。另外要记住做双向测试，因为在复杂网络里，回程路径可能和去程完全不同。
3.3 TCP 端口探测：最接近真实业务的通行测试
判断某个业务能不能通，做 TCP 端口探测比 Ping 靠谱得多：
nc -vz -w 5 目标IP 目标端口返回 succeeded 说明 TCP 三次握手成功，中间防火墙或网络设备至少放行了这个端口的入向包，也放行了回程包。如果想一次测试多个端口，可以写个简单的循环脚本，把常用端口都跑一遍，能快速定位是“全不通”还是“某个特定端口不通”。
需要提醒的是，握手成功只代表端口处于监听状态，不代表应用逻辑正常。比如 Web 服务返回 500 错误，TCP 握手照样是成功的。但作为“能否通行”的判断，TCP 端口探测已经足够说明网络层放行状态了。
3.4 抓包：在网关两侧对比，看流量到底有没有“过”
排查“通一半”或者“时通时断”的问题，我最后都会用抓包来收口。最常用的就是在网关或防火墙的内网口和外网口同时抓包：
tcpdump -i eth0 -nn host 目标IP and tcp port 8080 -c 100抓包的核心思路是对比：内网口能不能看到请求包，外网口能不能看到同一个请求包。如果内网口有 SYN，外网口没有，说明包被设备丢弃了；如果外网口能看到 SYN，但看不到 SYN-ACK，说明对端没响应，或回程包在别处被丢掉。抓包是“用证据说话”的方式，比翻几百行配置直观得多。
注意生产环境不要长时间抓包，尽量加-c限制包数量，或只抓特定 IP 和端口，避免抓包导致 CPU 冲高。
3.5 吞吐与带宽：通行不等于够用
连通性 OK、路径正确，但业务就是卡，这时候就要看带宽和吞吐。可以在出口设备上查看接口实时速率：
sar -n DEV 1 5也可以在防火墙上查带宽利用率和会话并发数。如果接口流量长期接近物理带宽上限，TCP 窗口会收缩，延迟会飙升，表现为“能通但是慢到没法用”。这时需要扩容带宽，或者做 QoS 优先级调度，保证核心业务的带宽。
另外别忽略设备自身的 CPU 和会话表资源。会话表塞满、CPU 达到 80% 以上，设备转发能力下降，也会出现进出口流量时通时断。这种问题看链路是看不出来的。
4. 策略审计：防火墙、ACL 与 NAT 的隐形闸门
4.1 会话表往往比配置文件先暴露问题
防火墙或网关设备维护的会话表，是当前真实流量的快照。排查“通不通”的时候，我习惯先看会话表，再看配置。因为配置描述的是“期望状态”，而会话表描述的是“现实状态”。
在防火墙上过滤源 IP、目的 IP、端口，查看对应会话状态：
- 如果会话表里完全查不到，说明流量根本没到这台设备，或被更前置的接口策略丢弃。
- 如果会话停在 SYN_SENT，说明 TCP 握手没完成，包可能发出了但没收到回应。
- 如果会话是 ESTABLISHED，但业务层超时，问题大概率在链路质量或应用本身。
会话表能直接告诉你流量被卡在哪一步，比对着规则一条条看高效得多。
4.2 逐条核对 ACL 放行策略，别被默认放行骗了
很多设备的默认策略是 Deny，或者存在历史遗留的冲突规则。核对策略时要注意几个点：
- 源地址、目的地址、端口、协议是否匹配业务真实流量。
- 规则顺序是否合理：曾经见过一条前向 deny 把后边所有 allow 全盖住了，流量全被静默丢弃。
- 有没有放行回程流量：无状态 ACL 需要显式放行返回包，有状态防火墙一般自动建立回程会话，但也要看安全域和区域策略是否配置正确。
- 有没有放行 UDP：常见故障是只放行了 TCP 80/443，结果 DNS 用 UDP 53，解析直接失败。
设备如果有“策略命中计数”功能，一定要用起来。可以指定源目地址匹配后看计数器增长，如果一直不增长，说明策略顺序或者地址匹配并不正确。
4.3 NAT 地址池和端口耗尽，出口变“假死”
出口方向做了源 NAT 后，外部看到的都是公网地址。如果地址池里只有一个公网地址，并发连接数一高，源端口很快被占满，新连接就无法建立。表现是：业务偶尔能通，但大部分时间连接超时，防火墙日志里全是 NAT 租约或端口资源不足的报错。
排查方式：
display nat session all # 或其他设备对应的查看命令重点看公网地址对应的会话数和端口占用率。如果端口占用长期超过 70%，就要增加地址池、调整端口复用策略，或者优化应用的连接复用。
入口方向的 DNAT 也要核对：映射的内网服务器 IP、端口、协议是否正确。曾经遇到外部访问端口映射到了已下线服务器，会话建到空地址上，自然进不来。
4.4 双机设备和负载均衡的会话一致性问题
主备防火墙或负载均衡设备切换时，经常出现“进得来、出不去”或“新连接正常、老连接断掉”的情况。因为如果两台设备的会话表没有同步，流量从主设备进来，回包却从备设备走，备设备没有对应会话，直接丢弃。
判断方法：在主备两台设备上都查一下是否能看到同一组会话。如果只在主设备看到，备设备没有，那就是会话同步没生效。解决方法是配置开启会话同步，并做切换演练，确认切换过程中在线会话不断。多链路负载均衡场景也一样，要配置会话保持，避免同一会话被散列到不同路径。
5. 真实故障复盘与避坑指南
5.1 能 Ping 通但业务端口连不上
某次外部用户访问内网服务，从内网 Ping 公网地址正常，从外部测试业务端口却一直失败。抓包后发现 TCP SYN 反复重传，但外部入口始终看不到正常握手。最后查策略，发现只放行了 ICMP，没有放行 TCP 443。这个案例说明：业务上线前必须从外部做真实端口测试，不能只在内部 Ping 一下就算“通”。
5.2 出方向上传正常，下载却频繁中断
有个案例是分公司到总部的内部链路，小文件上传没问题，下载大文件必然卡住。查链路带宽、延迟都正常，后来抓包发现大包超过链路 MTU，并且路径上有设备屏蔽了 ICMP 不可达消息，导致路径 MTU 发现失效。TCP 连续发送分片过大的报文，全部被静默丢弃，表现就是“大流量不通，小流量正常”。
解决方法是统一规划链路 MTU，或者在网络设备上调整 MSS，限制 TCP 报文段大小，避免超过传输路径的 MTU。这个坑特别容易出现在两端 MTU 不一致的传送链路上。
5.3 出方向正常、入方向不通的非对称路由
某多出口场景，内网主动发起的访问出方向正常，但外部回包经过另一条备份路径进入，状态防火墙上没有对应会话，于是被丢弃。现象是“我这边访问对方没问题，对方回包却丢得厉害”。排查时做双向 MTR，发现回程路径经过的设备和去程完全不一致。
解决办法是调整路由策略，让回程流量走同一台状态检测设备；或者在所有入口设备上打通会话同步机制，保证无论流量从哪台进，都能识别相同会话。非对称路由本身不一定有问题，但遇到状态防火墙就必须保证会话可见性。
5.4 DNS 缓存错误导致“域名不通”
某业务对外提供接口，外网用户反馈解析超时。内部测试解析正常，但外部始终无法获取正确地址。排查时先在外部用指定公共 DNS 查询，再查内部 DNS 服务器到上游 DNS 链路的连通性，最后发现防火墙只放行了 TCP，没有放行 UDP 53，导致 DNS 迭代查询无法返回。
这类问题隐蔽性很强，现象就是“网络通、域名不通”。排查时一定要把 DNS 单独拿出来测，不要默认“能上得了网 DNS 就一定正常”。
| 故障现象 | 可能原因 | 优先排查方向 |
|---|---|---|
| Ping 通但业务端口不通 | 防火墙未放行对应协议和端口 | 抓包、策略命中计数、会话表 |
| 出方向正常，入方向超时 | 非对称路由、DNAT 错误 | 双向 MTR、防火墙会话表 |
| 大包不通、小包通 | MTU 不一致或路径 MTU 发现被阻断 | 抓包、调整 MTU/MSS |
| 时通时断、连接无法建立 | NAT 地址池或端口耗尽 | NAT 会话数、接口速率、CPU |
| 域名解析失败 | DNS 不可达或 UDP 53 被拦截 | dig 指定 DNS、检查策略 |
| 双机切换后业务中断 | 会话表未同步 | 主备设备会话对比 |
5.5 我的几条避坑经验
排查进出口流量是否通行，有几点我每次都会提醒自己：
- 先看会话表，后翻配置文件。会话表反映当前发生了什么，配置文件只反映你“以为”应该发生什么。
- 抓包一定要双向抓。只抓一端，根本不知道包是被对端丢弃，还是回程丢掉的。
- 配置变更前务必保存 baseline，变更后立刻做端口连通性测试。很多事故都是改完没测，或者只测了 Ping。
- 用最小复现思路收敛问题。如果只是某个网段不通、某个应用不通，就缩小到一台终端、一个端口、一条流去测，不要全网乱抓。
- 不要迷信单一工具。Ping、MTR、端口探测、抓包各有局限，组合起来才能拼出完整链路视图。
我个人在实际排查中最深的一点体会是：别把“判断能不能通行”做成一次性的通断测试，它更像一次体检，要看链路质量、策略状态、会话表、历史基线和业务可用性。每次上线新业务前把这套检查走一遍，能避免大量“上线后发现通一半”的尴尬。最后留一个小技巧：如果手头没有监控平台，就写一个简单的定时任务，每五分钟把双向 MTR 和核心端口探测结果追加到日志文件，出问题时翻出最近一小时的记录对照，比到处问人靠谱得多。
