我经常被同事问一个问题“咱们的进出口流量到底通不通”这个问法听起来很直白但真上手排查时往往发现没这么简单。前一阵有个新业务上线出口方向流量告警频繁内网Ping网关一切正常业务却时断时续。后来我从链路、路由、策略一层层剥开才发现问题出在防火墙策略命中顺序和NAT会话超时上和物理链路一点关系都没有。这篇文章我想把平时判断进出口流量能否通行的一套方法完整梳理一遍包括命令、抓包思路、防火墙策略审计和几个经典故障复盘适合网络运维、系统管理员以及刚接手网络排查的朋友参考。1. 判断进出口流量之前先把“通行”拆成三个层次1.1 入口流量和出口流量先别混为一谈“进出口流量”在不同场景下含义不一样。这里聊的是网络侧的进出口流量更准确地说是数据中心或企业内部网络两个方向的数据流出口流量内网终端或服务器发往外部业务系统的流量。入口流量外部用户或合作伙伴访问内网服务的流量。这两个方向往往不是同一条路径。就算物理上走的都是同一个出口设备入口流量要经过的外部路由、NAT映射、防火墙规则和出口流量也完全可能不一样。很多故障只出现在一个方向内部访问外部一切正常外部访问内部就是连不上或者外部访问没问题内部发外部却被某种策略卡住。所以在开始排查之前先确认你是在判断“出去能不能通”还是在判断“进来能不能通”方向都搞错后边全是白忙。1.2 把“通行”拆成三层排查才不会乱我习惯把“能否通行”拆成三个层次连通性链路通不通端口 up 没 upIP 能不能互相 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 对端 IPping -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 和核心端口探测结果追加到日志文件出问题时翻出最近一小时的记录对照比到处问人靠谱得多。 
长河君 · 2026/10/18 3:36:10 · 阅读 1.2k 进出口流量不通？从物理层到应用层一步步排查
我经常被同事问一个问题“咱们的进出口流量到底通不通”这个问法听起来很直白但真上手排查时往往发现没这么简单。前一阵有个新业务上线出口方向流量告警频繁内网Ping网关一切正常业务却时断时续。后来我从链路、路由、策略一层层剥开才发现问题出在防火墙策略命中顺序和NAT会话超时上和物理链路一点关系都没有。这篇文章我想把平时判断进出口流量能否通行的一套方法完整梳理一遍包括命令、抓包思路、防火墙策略审计和几个经典故障复盘适合网络运维、系统管理员以及刚接手网络排查的朋友参考。1. 判断进出口流量之前先把“通行”拆成三个层次1.1 入口流量和出口流量先别混为一谈“进出口流量”在不同场景下含义不一样。这里聊的是网络侧的进出口流量更准确地说是数据中心或企业内部网络两个方向的数据流出口流量内网终端或服务器发往外部业务系统的流量。入口流量外部用户或合作伙伴访问内网服务的流量。这两个方向往往不是同一条路径。就算物理上走的都是同一个出口设备入口流量要经过的外部路由、NAT映射、防火墙规则和出口流量也完全可能不一样。很多故障只出现在一个方向内部访问外部一切正常外部访问内部就是连不上或者外部访问没问题内部发外部却被某种策略卡住。所以在开始排查之前先确认你是在判断“出去能不能通”还是在判断“进来能不能通”方向都搞错后边全是白忙。1.2 把“通行”拆成三层排查才不会乱我习惯把“能否通行”拆成三个层次连通性链路通不通端口 up 没 upIP 能不能互相 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 对端 IPping -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 和核心端口探测结果追加到日志文件出问题时翻出最近一小时的记录对照比到处问人靠谱得多。