财务说"系统卡了"，初级网工回了"网络正常"，高级网工先问了三个问题

周一早上九点二十，财务群里冒出一句：

“报销单又交不上去了。”

小王连上接入交换机。端口 up，没有错包。ping 一下 ERP 服务器，3ms，不丢包。

他回：“网络正常，清一下浏览器缓存试试。”

二十分钟后，财务又发了一句：“还是不行。”

这事转到了老陈手上。

ping 通了，问题其实才刚开始。小王用 ICMP 的结论去回答一个 HTTPS 的问题，两者对不上。

“只有你们卡，还是别的部门也卡？”

“打开页面就卡，还是做某一步才卡？”

“从什么时候开始的？”

财务回：就我们部门。页面能打开，填单也正常，一上传发票扫描件就一直转圈，最后报错。上周五下午开始的。

三个问题，问的是三件事：范围、动作、时间。

问完以后，要查的范围从"整个网络"缩成了一条线：财务网段访问 ERP 的 HTTPS 上传，大文件，上周五之后。

我刚工作那两年最吃亏的就是这一点。有一次园区网半夜出环路，我从核心开始一台一台登，四十多台交换机看下来，天快亮了。师傅过来只看了汇聚上的 MAC 漂移告警，顺着广播包暴涨的端口往下找，二十分钟就定位到会议室里一台小交换机，上面插了两根首尾相连的网线。

那一晚我很卖力，只是大部分力气花在了不用查的地方。

老陈在纸上画了一条线：

财务 PC → 接入交换机 → 汇聚交换机 → 防火墙 → 服务器区交换机 → ERP 服务器

然后对着这条线想：刚才那个 ping，证明了哪些，没证明哪些。

它能证明三层可达，ICMP 能走通。

它证明不了的更多：

默认的 ping 包只有几十字节。Windows 默认载荷 32 字节，Linux 默认 56 字节，1500 字节的整包过不过得去，它测不出来。

防火墙对 ICMP 和对 HTTPS 443，完全可以命中两条不同的策略。

TCP 建连、TLS 握手、HTTP 上传、服务器处理，这几步 ping 一步都没碰到。

所以"ping 通"只说明路是通的，这个业务请求在路上发生了什么，还得另外查。

第一步：抓住"大文件才卡"这个特征。

页面能开、小请求正常，唯独大文件上传失败。说明问题和"量"有关，不是完全不通。

和大小相关的，常见的有三类原因：路径 MTU 问题、中间设备对内容做了处理、服务器端的上传限制。

第二步：排除 MTU 和服务器。

在财务电脑上执行 ping -f -l 1472 ERP地址（Windows 下 -f 表示不分片，1472 加上 28 字节头部正好 1500）。能通，路径 MTU 没问题。

再找行政部同事上传一张同样大小的扫描件，秒传。服务器没问题，问题只出在财务这一段路径上。

第三步：看请求卡在哪一段。

浏览器按 F12，打开 Network，重新上传一次，点开那条上传请求看 Timing。

DNS、建连、TLS 都在几十毫秒内完成，数据也很快发出去了，然后就卡在 Waiting，二十多秒后报错。

这说明客户端这边没问题，文件交出去了，是交出去以后一直没等到回应。

第四步：看一眼证书。

老陈点开浏览器地址栏的锁，看 ERP 的证书颁发者。

颁发者不是 ERP 原来的证书机构，是公司防火墙的 CA。

也就是说，这条 HTTPS 流量正在被防火墙解密。

财务电脑早就装了防火墙的根证书，是上网行为审计用的，所以浏览器一点告警都没有。这个问题藏得深，原因就在这里。

第五步：去防火墙上找命中的策略。

查财务 PC 到 ERP 443 的会话，看它命中了哪条策略。

找到了。上周五新加了一条"财务网段上网审计"策略，开了 SSL 解密和文件检测，目的地址写的是 any，而且排在原来那条 ERP 放行策略的前面。

本来是给外网上网做审计的，结果把访问内部 ERP 的流量也一起兜了进去。

第六步：两端抓包，把证据坐实。

财务 PC 和 ERP 服务器两边同时抓包，对比着看。

客户端这边：握手正常，上传数据发出去后，ACK 回得很快。但这个 ACK 是防火墙回的，因为开了解密以后，防火墙相当于站在中间当代理，然后就是长时间没有应用层响应。

服务器这边：连接进来的源头是防火墙，上传的数据迟迟不到，或者到一半就断了。

客户端说"我发完了"，服务器说"我没收全"，东西卡在中间。

处理：在审计策略前面加一条内部业务系统的免解密放行策略，把审计策略的目的地址限定为外网。改完让财务重新上传，秒传。

这是很多人会追问的地方，也是面试里很好的加分点。

防火墙开了 SSL 解密，干的活就变多了：先和客户端完成一次 TLS 握手，再和服务器另建一次，中间把数据解开、检查、重新加密。每一个字节都要多算两遍。

解密以后如果还开了文件检测、防病毒，很多设备要先把文件缓存下来、还原成完整文件，检查完才决定放不放行。几 KB 的页面请求一闪就过，几十 MB 的扫描件就要在设备里排队。

偏偏财务是整个公司最爱传大附件的部门，月底报销的时候还会集中上传。

你可以去翻一下自家防火墙的规格书，对比一下"防火墙吞吐"和"开启 SSL 解密 / 防病毒后的吞吐"。两个数字差很多是常见的事。解密引擎的性能边界，要当成网络设计的一部分来考虑。

这张表可以存下来，下次排障对着看。

左边一列，是"网络正常"四个字最常见的来源。

问题解决后，老陈在群里是这么回的：

“财务网段到 ERP 三层可达，时延和丢包都正常。原因是上周五新增的上网审计策略误匹配了内部 ERP 流量，大附件上传被防火墙解密和检测拖住。已加内部系统免解密策略，麻烦再试一次。”

有范围，有证据，有原因，有处理动作。

小王那句"网络正常"，听起来是在下结论，其实是把问题推回给了用户。业务部门听过几次这四个字，下次出问题就不会先找网工了，会直接去找网工的领导。

领导不一定看得懂防火墙日志，但分得清谁说话有依据。

亲手画一遍公司拓扑，一直画到防火墙策略那一层。画到一半你大概会发现，有几条策略你讲不出是干什么的。那就是你下一步要补的地方。

找一台内网服务器，在两端同时抓一次包。看一遍三次握手、TLS 握手、数据传输、ACK 分别是谁发的。这一次比看十篇文章都管用。

每处理完一个故障，写三行字：现象、原因、下次怎么更快。写满一年，就是一本只属于你的排障手册。

原理也是在这些地方派上用场。考 HCIA、HCIP 背下来的 TCP 状态、策略匹配顺序、OSPF 状态机，到了现场，是用来一眼认出现象的。

下次群里再有人说"网卡了"，先别急着 ping。

先问三句：谁卡，卡在哪一步，从什么时候开始。

注： 案例来自SPOTO 思博学员真实排障现场。老陈是化名，any 是真坑。