1. 从"能 ping 通"到"下载失败"的认知断层
很多人第一次遇到这个问题时，脑子里蹦出来的第一个念头是"网络没问题啊，ping 都通了"。这个判断本身没错，但结论下错了。ping 通只证明了一件事：ICMP 报文在两端之间能完成一次往返。它证明不了 TCP 握手能成功，更证明不了几百字节到几 KB 的工程数据包能完整穿过整条链路。
PLC 远程维护场景里，"ping 通但下载失败"几乎是最高频的一类故障。它的典型表现是：工程师在办公室或家里，通过远程通道连到现场路由器，ping 一下 PLC 的 IP，延迟正常、不丢包，心里一松；然后打开编程软件点"下载"，进度条卡在某个百分比，或者干脆弹出一个"连接中断""目标不可达""通信超时"的报错。反复重试，偶尔能成一次，大部分时候失败。
这里的关键认知是：ping 用的是小包，下载用的是大包。默认情况下，Windows 的 ping 只发 32 字节的数据，加上 IP 头和 ICMP 头也就 60 字节左右。而 PLC 程序下载、固件更新、在线监控这些操作，单个 TCP 报文的数据载荷动辄 1400 字节以上。当链路的 MTU（最大传输单元）被某种隧道封装压缩之后，小包能过，大包过不去，就出现了"ping 通但下载失败"这个看似矛盾的现象。
我先把结论摆在这里：这类问题的排查顺序应该是 MTU 优先，而不是先怀疑 PLC、先怀疑编程软件、先怀疑防火墙。因为 MTU 问题是唯一一个能完美解释"小包通、大包挂"这个特征的。下面我把整个排查链路拆开讲，包括每一步为什么这么做、怎么验证、以及我实际踩过的坑。
2. 为什么隧道封装会把 MTU 悄悄吃掉
2.1 标准以太网的 1500 字节是怎么来的
要理解 MTU 问题，得先知道 1500 这个数字的来历。以太网帧的标准最大载荷是 1500 字节，这是几十年前定下来的规矩，一直沿用至今。一个完整的以太网帧结构大致是：14 字节以太网头 + 1500 字节载荷 + 4 字节 FCS 校验，总共 1518 字节。这个 1500 就是所谓的 MTU。
当两台设备在同一个局域网内直接通信时，MTU 就是 1500，谁也不用改。但一旦中间加了隧道，事情就变了。隧道的工作方式是：把原始的数据包整个塞进一个新的数据包里，再发出去。这个"塞进去"的动作，需要额外的头部空间。
2.2 隧道封装到底占了多少字节
不同的隧道协议，额外开销不一样。我列一个常见的对照表，方便你心里有数：
| 封装类型 | 额外开销（约） | 有效 MTU |
|---|---|---|
| 无封装（纯以太网） | 0 | 1500 |
| GRE | 24 字节 | 1476 |
| IPsec（传输模式） | 50-60 字节 | 1440-1450 |
| IPsec（隧道模式） | 60-80 字节 | 1420-1440 |
| 双层封装（隧道套隧道） | 100+ 字节 | 1400 以下 |
注意，这里的开销是叠加的。如果你的远程通道本身就是"隧道套隧道"——比如先有一层加密隧道，里面又跑了一层 GRE——那有效 MTU 可能只剩 1360 甚至更低。
问题的核心在于：路径上的设备并不会自动协商出一个大家都满意的 MTU。发送端默认按自己的 MTU（通常是 1500）发包，包到了隧道入口，如果包太大塞不进去，理想情况下应该回一个 ICMP "需要分片"的消息，告诉发送端"你把包改小点"。但现实是，很多网络设备出于安全策略，直接把这类 ICMP 消息拦掉了。发送端收不到反馈，就傻乎乎地一直发大包，一直失败。
2.3 为什么 ping 通不代表大包能通
现在回到那个矛盾现象。你 ping PLC 的时候，发的是 32 字节的小包，加上各种头也就 60 字节左右，远小于任何隧道的有效 MTU，所以畅通无阻。但下载程序时，TCP 会尝试发送 MSS（最大报文段长度）大小的数据，通常是 1460 字节。这个包加上 TCP 头、IP 头，正好 1500 字节，到了隧道入口塞不进去，被丢弃。TCP 有重传机制，会重试几次，但如果每次都失败，最终就超时断开。
更隐蔽的一种情况是：TCP 三次握手能成功，但数据传输阶段失败。因为握手包很小，能过；一旦开始传数据，大包被丢，连接就卡死。这解释了为什么有些工程师看到"能连上"就以为网络没问题，结果下载到一半崩掉。
这里有个经验判断：如果 ping 通、能建立连接、但一传数据就断，且断的位置每次都在差不多的进度，那基本可以锁定是 MTU 问题，而不是 PLC 或软件的问题。
3. 一套可复现的 MTU 排查顺序
3.1 第一步：用带 DF 标志的 ping 探出真实 MTU
这是整个排查里最关键的一步，也是最容易被跳过的一步。普通 ping 探不出 MTU，必须用"禁止分片"（DF）标志。原理是：如果包的大小超过了路径 MTU，且设置了 DF 标志，那么路径上的设备就不能分片，只能丢弃并返回错误。这样你就能通过逐步调整包大小，找到那个"刚好能过"的临界值。
Windows 下的命令是这样的：
ping -f -l 1472 192.168.1.10这里的-f是禁止分片，-l 1472是数据载荷大小。为什么是 1472 而不是 1500？因为 1472 + 8 字节 ICMP 头 + 20 字节 IP 头 = 1500。也就是说，-l的值加上 28，才是实际的 IP 包大小。
如果返回"需要拆分数据包但设置 DF"，说明 1472 太大了，往下调。如果返回正常回复，说明这个大小能过。我的习惯是从 1472 开始，每次减 8，直到能通为止。比如：
ping -f -l 1400 192.168.1.10 ping -f -l 1300 192.168.1.10 ping -f -l 1200 192.168.1.10找到能通的最大值后，加上 28，就是这条路径的实际 MTU。比如-l 1372能通，那实际 MTU 就是 1400。
Linux 下的命令略有不同：
ping -M do -s 1472 192.168.1.10-M do对应禁止分片，-s指定包大小。逻辑完全一样。
3.2 第二步：区分是"路径 MTU 小"还是"某一跳 MTU 小"
有时候你会发现，从 A 点 ping PLC 能通的最大包，和从 B 点 ping 能通的最大包不一样。这说明路径上不同位置的 MTU 不一致。这时候需要分段测试：先 ping 隧道入口，再 ping 隧道出口，最后 ping PLC。每一段都测一遍最大可通包大小，就能定位到是哪一段把 MTU 压低了。
我遇到过一个案例：办公室到现场路由器这一段 MTU 是 1500，但现场路由器到 PLC 这一段因为中间有个老旧的交换机，MTU 只有 1400。结果就是，从办公室直接 ping PLC，最大只能到 1400 左右；但 ping 现场路由器本身，能到 1472。这个差异直接指向了问题所在。
3.3 第三步：确认 ICMP 是否被拦截
有一种情况会让上面的方法失效：路径上的设备把 ICMP 全拦了，包括"需要分片"的消息。这时候你用 DF ping 会一直失败，但失败原因不是 MTU 小，而是 ICMP 根本不通。怎么区分？很简单，先不加 DF 标志 ping 一下，如果普通 ping 能通，加 DF 就全挂，那可能是 ICMP 被选择性拦截，也可能是 MTU 问题。这时候需要换一种验证方式。
可以用tracert（Windows）或traceroute（Linux）配合不同包大小来探测。Windows 下：
tracert -f 1 -l 1472 192.168.1.10如果某一跳之后全部超时，而那一跳之前正常，说明问题出在那一跳之后。Linux 下可以用traceroute的-F参数禁止分片。
3.4 第四步：在 PLC 侧抓包确认
如果条件允许，在现场侧做一次抓包是最直接的证据。用科来或者 Wireshark，过滤 ICMP 和 TCP。你会看到：小包正常往返，大包发出后没有回应，或者收到 ICMP "需要分片"但发送端没有调整。抓包能一锤定音，避免在错误的方向上浪费时间。
抓包时重点看两个东西：一是大包是否真的发出去了，二是是否有 ICMP 错误返回。如果大包发出去了但没回应，且没有 ICMP 错误，那基本就是路径上某处静默丢弃了大包，MTU 问题坐实。
4. 找到 MTU 之后，怎么改才有效
4.1 改哪里：发送端、隧道端还是 PLC 端
找到实际 MTU 之后，下一步是决定在哪里改。这里有个原则：优先在发送端改，其次在隧道端改，最后才考虑 PLC 端。原因是 PLC 作为工业设备，它的网络参数往往不是随便能动的，而且改了可能影响其他通信。
发送端改 MTU 是最直接的。Windows 下可以用 netsh 命令：
netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent把"以太网"换成你实际使用的网卡名称。这个命令会把该网卡的 MTU 永久设为 1400。改完之后，所有从这个网卡发出的包都会按 1400 来分片，大包问题自然消失。
Linux 下：
ip link set dev eth0 mtu 1400如果要永久生效，需要写进配置文件，不同发行版位置不一样。麒麟系统一般在/etc/sysconfig/network-scripts/ifcfg-eth0里加一行MTU=1400，CentOS 7 也是类似的位置。
4.2 改 MTU 和改 MSS 的区别
这里要澄清一个常见混淆：MTU 是链路层的概念，MSS 是 TCP 层的概念。改 MTU 会影响所有协议，改 MSS 只影响 TCP。对于 PLC 下载这种 TCP 通信，改 MSS 有时候更精准。
Linux 下可以用 iptables 做 MSS 钳制：
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu这条规则的意思是：对所有转发的 TCP SYN 包，把 MSS 自动钳制到路径 MTU 对应的值。这样发送端在握手时就会知道该用多大的 MSS，从源头避免大包问题。
Windows 下没有直接对应的命令，但可以通过改 MTU 达到类似效果。因为 TCP 的 MSS 是根据 MTU 自动计算的，MTU 改了，MSS 自然跟着变。
4.3 改完之后必须验证的三件事
改完 MTU 不是就完事了，必须验证三件事：
第一，用 DF ping 确认新的 MTU 下大包能通。比如你设了 1400，那就 ping-f -l 1372，应该能通。
第二，实际做一次 PLC 程序下载，看是否还断。这是最终验证，不能省。
第三，观察一段时间，确认没有引入新的问题。有时候 MTU 改小了，虽然解决了大包问题，但可能让某些依赖大包的应用变慢。不过对于 PLC 维护场景，这点性能损失完全可以接受。
我个人的习惯是，改完 MTU 后至少做两次完整的下载测试，中间间隔几分钟，确认稳定性。因为有些 MTU 问题是间歇性的，一次成功不代表次次成功。
5. 那些年我在 MTU 上踩过的坑
5.1 坑一：以为 ping 通就万事大吉
这是我早期最常犯的错误。看到 ping 通，就排除了网络问题，转头去折腾 PLC 的通信设置、编程软件的驱动、甚至重装软件。折腾半天，问题依旧。后来才明白，ping 通只是最低门槛，真正的验证要用大包。
这个坑的教训是：排查顺序错了，后面全是无用功。现在我遇到"能 ping 通但连不上"的问题，第一反应就是测 MTU，五分钟就能排除或确认，效率完全不一样。
5.2 坑二：改了 MTU 但没改对地方
有一次我在办公室的电脑上改了 MTU，测试也通了，但现场另一台电脑下载还是失败。后来发现，现场那台电脑走的是另一条路径，MTU 限制不一样。这提醒我：MTU 是路径相关的，不是设备相关的。同一条链路的不同端点，可能因为路由不同而有不同的有效 MTU。
所以改 MTU 之前，一定要确认你改的是实际出问题的那条路径的发送端。如果有多条路径，每条都要单独测、单独改。
5.3 坑三：忽略了 ICMP 被拦截的情况
有一次用 DF ping 怎么都不通，我以为 MTU 小到离谱，结果发现是路径上的防火墙把 ICMP 全拦了。这种情况下，DF ping 的结果完全不可信。后来我改用 TCP 层的方法验证：用telnet或nc连 PLC 的端口，看能不能建立连接，再传一些数据看会不会断。
Linux 下可以用nc测试：
nc -v 192.168.1.10 102102 是西门子 PLC 常用的 ISO-TSAP 端口。如果连接能建立但传数据就断，结合前面的分析，基本能确认是 MTU 问题。
5.4 坑四：MTU 改得太小
有人一发现 MTU 问题，就干脆把 MTU 改成 1200 甚至 1000，觉得"小一点总没错"。这确实能解决大包问题，但会带来新问题：包变小了，同样的数据需要更多的包来传，传输效率下降，下载时间变长。而且有些应用对 MTU 有下限要求，改太小可能导致其他异常。
我的建议是：找到实际能通的最大值，然后留 20-40 字节的余量。比如实测 1400 能通，那就设 1380 或 1360。留余量是因为网络状况可能变化，留点缓冲更稳。
5.5 坑五：忘了 PLC 侧也可能有 MTU 限制
虽然大多数时候问题出在发送端或隧道端，但 PLC 侧也不是完全无辜。有些 PLC 的网口 MTU 是可配的，如果被设成了很小的值，也会导致大包过不去。这种情况比较少见，但如果前面都排查完了还是不行，值得去 PLC 的网络设置里看一眼。
6. 把 MTU 排查固化成流程
6.1 一张排查顺序表
我把整个排查过程整理成一张表，方便你按顺序执行：
| 步骤 | 操作 | 判断依据 | 下一步 |
|---|---|---|---|
| 1 | 普通 ping PLC | 通/不通 | 不通先查基础网络 |
| 2 | DF ping 逐步减小包 | 找到最大可通包 | 算出实际 MTU |
| 3 | 分段 DF ping | 定位瓶颈段 | 确定改哪里 |
| 4 | 抓包确认 | 看大包是否被丢 | 坐实 MTU 问题 |
| 5 | 改发送端 MTU | 设为实测值减余量 | 验证 |
| 6 | 实际下载测试 | 成功/失败 | 失败回到步骤 2 |
这张表的价值在于：它把"凭感觉排查"变成了"按流程排查"。每一步都有明确的判断依据和下一步动作，不会卡在某个环节反复试错。
6.2 几个能省时间的命令
除了前面提到的 ping 和 netsh，还有几个命令在排查时很有用：
查看当前网卡 MTU：
netsh interface ipv4 show subinterfacesLinux 下：
ip link show查看路由表，确认走的是哪条路径：
route printLinux 下：
ip route show这些命令能帮你快速了解当前的网络配置，避免在错误的前提上做判断。
6.3 什么时候该放弃 MTU 方向
虽然 MTU 是这类问题的头号嫌疑，但也不是唯一可能。如果 DF ping 显示大包能通，实际下载还是失败，那就要考虑其他方向了：比如 PLC 的连接数限制、编程软件的版本兼容性、防火墙的应用层策略等。这时候 MTU 排查的结论"大包能通"本身就是一个有价值的信息，它帮你排除了一个方向，让你能集中精力查别的。
我一般给自己设一个时间盒：MTU 排查不超过 30 分钟。如果 30 分钟内没找到明确的 MTU 证据，就暂时放下，转去查其他方向。因为 MTU 问题的特征是"小包通大包挂"，如果这个特征不明显，硬磕 MTU 就是浪费时间。
7. 远程维护场景下的额外注意事项
7.1 远程通道本身的稳定性
远程维护和现场维护最大的区别是：中间多了一条不受你控制的通道。这条通道的 MTU 可能随时变化，比如运营商调整了线路、隧道软件更新了协议、中间某台设备重启了。所以远程维护时，MTU 问题可能不是一次性的，而是反复出现的。
我的做法是：在第一次排查出 MTU 值之后，把它记下来，写进维护文档。下次再遇到类似问题，直接从那个值开始测，能省不少时间。如果发现 MTU 值变了，说明通道有变动，需要重新评估。
7.2 不同编程软件的差异
不同 PLC 编程软件对 MTU 的敏感度不一样。有的软件在 MTU 不够时会自动重试并调整包大小，表现是"慢但能成"；有的软件直接报错断开，表现是"完全不行"。所以同样的 MTU 问题，在不同软件上表现可能不同。排查时不要因为"换个软件就好了"就以为问题解决了，那只是软件容错能力不同，根因还在。
7.3 安全策略与 MTU 的交互
有些安全策略会主动拦截 ICMP，包括"需要分片"的消息。这种情况下，即使 MTU 有问题，发送端也收不到反馈，表现就是"莫名其妙地断"。这时候需要在安全策略上放行 ICMP 类型 3 代码 4（需要分片但设置了 DF），或者直接在发送端把 MTU 改小，绕过这个问题。
注意：放行 ICMP 需要评估安全影响，不是所有环境都适合。如果安全要求高，优先选择改 MTU 的方案。
8. 我个人的经验收尾
这套 MTU 排查方法，我从第一次踩坑到现在用了好几年，基本上每次遇到"ping 通但下载失败"都能在半小时内定位。最深的体会是：网络排查最怕的不是问题难，而是方向错。ping 通这个假象太容易让人跑偏，把时间浪费在 PLC 和软件上。
如果你只记一件事，就记这个：遇到"能 ping 通但连不上/传不了数据"，先测带 DF 标志的大包 ping。这一个动作，就能帮你排除掉一大半的可能性。剩下的，按我上面那张表一步步走，基本都能找到答案。
最后分享一个小技巧：在远程维护的电脑上，把常用的 MTU 测试命令做成一个批处理脚本，一键执行，自动从 1472 往下试到 1200，把能通的最大值打印出来。这样每次遇到问题，双击一下，几秒钟就知道结果，比手动一条条敲命令快得多。这个脚本我用了两年多，省下的时间相当可观。
