严格 mTLS 部署中的兼容性排查方法

严格 mTLS 出问题，最常见的误判是把连接失败当成策略写错。实际上，当接收方策略收紧之后，第一个要回答的问题不是“规则对不对”，而是“这条连接里的双方身份，网格能不能验证”。兼容性排查应当围绕这个前提展开，而不是在报错日志里反复改授权规则。

先确认谁在网格里

工作负载纳管不等于网格纳管。判断标准是流量是否真的经过数据平面：旁路代理的调用、直接访问 Pod IP 的客户端、网格外遗留系统与外部依赖，都不在严格策略的覆盖范围内，也不会因为开通了 mTLS 就自动获得保护或放行。排查时按命名空间、控制器、ServiceAccount 逐个对照实际调用关系，把探针、批处理任务和运维工具单独列出来——它们最容易被遗漏，也往往在策略收紧后第一批失败。

证书、代理与连接行为

严格模式要求接收方验证对端证书，因此证书签发链路、信任关系、轮换机制和代理健康状况是必须满足的前提条件。证书无法正常签发或轮换中断时，症状通常表现为握手失败或验证错误，而非授权拒绝；这两类日志必须分开判断，因为处置方向完全不同。

协议层面的兼容性同样容易被低估。应用是否依赖非预期协议或端口、长连接是否复用、客户端是否在连接建立阶段就开始传输，这些在宽松模式下不会暴露，但在严格模式下会直接放大成连接不稳定。还有一个常见混淆：mTLS 只解决传输加密与对端认证，并不授予调用权限。只收紧传输而放任授权，仍然会放行本不该放行的调用；反过来，授权规则也无法替代加密。

验证要正反都测

策略对象创建成功不代表配置已经下发到数据平面。至少要凑齐三组证据：已授权工作负载的调用成功；不符合授权规则的网格内调用被拒绝；网格外测试端无法以明文连接受保护服务。这里最容易出错的是把客户端超时当作 mTLS 生效的证据——网络策略、服务发现异常和应用故障都会产生几乎一样的现象。

故障处置的原则是缩小范围，尤其是不要放大权限。影响局限在试点，就先恢复试点变更前保存的策略，不要动共享策略；回滚到允许明文只是有时限的恢复手段，需要限定影响范围并安排重新启用与复测。最终需要能清晰区分两件事：连接已加密并完成对端认证，以及这次调用本来就被授权。