ESP 解密一切正常，内层报文却仍然不知所踪

ESP 接收计数器在增长，隧道也保持在线，应用却始终看不到这个报文。解密跑过了，完整性校验也通过了，接下来接收端必须判断受保护的载荷到底是什么。格式不匹配恰恰出现在这最后一步，而从外部看，它一点也不像防火墙问题。

当标签说谎时你会看到什么

客户端日志里没有任何东西能把它和路由黑洞区分开。两者都会在健康隧道旁边制造应用超时，所以计数器总是第一个被怀疑的对象。

接收计数器上涨确实是好消息：报文到达了，也通过了认证。但这不能证明内层报文对加密层之上的任何东西有任何意义。

类型住在尾部报头里

在普通的 IPsec 隧道模式下，受 ESP 保护的载荷内含一个完整的内层 IP 报文。尾部报头中的下一首部字段指明该载荷是什么，它不是 TCP 端口，不是外层首部里的协议号，也不属于开头的 SPI 和序列号字段。 RFC 4303 第 2.6 节 把它定义为载荷类型字段，精确的名字对应精确的职责。

你会遇到的值都很小，值得记住：IPv4 是 4（0x04），IPv6 是 41（0x29）。

这些数字来自 IANA 的协议号分配，而不是本地约定。发送方声称是 IPv4 却封装了 IPv6 报文，就制造了格式不一致，任何防火墙规则都修不好与自身标签相矛盾的字节。

如何把它与常见嫌疑区分开

大多数丢包都不是编码缺陷。 先检查选择器，因为排除 IPv6 前缀的流量选择器会在任何封装发生之前就把流量丢掉。然后检查路由，再检查接收主机上的本地过滤。只有把这些都排除之后，载荷格式不匹配才成为站得住脚的解释。

加密抓包无法定论，因为受保护的下一个首部位于加密载荷内部。你需要实现侧的诊断，或者一个受支持的、已解密的观察点，而两者在使用前都需要授权。

如果没人拿得出这份证据，你就没有格式缺陷。你只有一个推测，而选择器仍然是更靠谱的赌注。

修复不是什么

不要为了让流量通过而关闭完整性校验。不要在中间路由器上改写加密报文，那不可能奏效，还会在抓包里看着有用的时候把流破坏掉。不要凭着端口被挡的猜测去放开更宽的应用防火墙规则。这些都不触及标签不匹配。

如果确认的不匹配来自对端实现，请保留一份最小化的、已脱敏的复现，并把它提交给该实现的支持渠道。

验证流，而不是计数器

修正之后，要端到端测试真实的 IPv6 流：一个穿过隧道的应用请求、它的响应，以及双方各自看到的地址对。ESP 计数器上涨只能证明报文在被接收和认证，它对内层报文是否可用一无所知。

把两个结果都记进工单。计数器变化加上可用的流才叫修复；只有计数器变化，那就是你动手之前的样子。