mihomo 的 TUN 文档没有给出用固定外部目标做前后对比的命令、工具或步骤，只说明 mtu 是最大传输单元、会影响极限状态下的速率，一般用户默认即可。因此所谓比较，只能做成“只改 mtu、其余官方字段保持不动，然后观察是否出现文档所描述的极限速率差异”。不能引入文档未记载的探测方式，否则比较结果无法对应回官方说明。
变更前固定配置并留下可回放的基线
适用条件是 tun 已启用且准备改 mtu。操作步骤是先完整保存当前 tun 段，确认 mtu 现有值或处于默认、stack、device、gso、auto-route、auto-redirect、auto-detect-interface、dns-hijack、strict-route 全部不变。判断依据是文档示例与字段列表：只有保证其余项固定，前后差异才可能被解释为 mtu。同时记录操作系统、防火墙是否已按要求放行（否则 system/mixed 根本不可用）、以及 inet6-address、udp-timeout、iproute2 索引等。所谓固定目标，在文档语境下是指同一套配置环境和同一类流量，而不是未说明的某个测试地址。
只改 mtu 后观察是否落入极限速率描述
写入新的 mtu 值并重新加载配置。比较时只看极限状态下的速率是否出现文档提到的那种影响，日常使用上的快慢变化不能当作依据。判断标准仍然是官方那句话：一般用户默认即可，因此若观察窗口并非极限，比较本身没有文档意义。Linux 上还要保持 gso 与 gso-max-size、nftables 相关 route-address-set 前后一致；Windows 上保持 strict-route 带来的防火墙规则一致；Android 上保持用户与包名过滤一致。任何额外改动都会让前后无法对比。
比较得不出文档意义上的结论时如何收场
如果前后看不到与极限速率相关的明确差异，或无法证明当时处于极限状态，则比较失败。下一步是马上把 mtu 改回变更前的值或删除该键，因为文档并不把调整当作常规操作。随后把注意力转到栈切换、接口指定、dns-hijack 在各系统的限制、endpoint-independent-nat、congestion-controller（仅 mips）以及路由排除项。保留两份纯文本配置和观察笔记，但停止任何文档未写的额外测量。只有这样，整个过程才仍然落在官方资料范围内。