首先得说，你碰到的这个随机成功/失败的情况，其实和Full-cone NAT的动态映射生效逻辑以及STUN CHANGE-REQUEST扩展的作用直接相关，不是什么玄学问题——咱们一步步拆解：

核心原因分析 #

1. Full-cone NAT的端口映射“激活窗口期” #

虽然Full-cone NAT理论上允许任意外部IP访问映射后的端口，但很多路由器的实现并不是在创建映射的瞬间就完全开放权限。当你第一次发送基础binding请求时，路由器只会把这个新生成的端口映射和STUN服务器的初始请求IP绑定，只有来自这个IP的流量才能通过。这时候如果第二个客户端立刻发起连接，路由器会因为这个端口还没对其他IP开放而拒绝流量，导致连接失败。

而当你发送带CHANGE-REQUEST的请求后，STUN服务器会用第二个IP回复响应，这相当于给路由器发了一个“信号”：这个端口需要接受来自其他IP的流量。路由器收到这个跨IP的响应后，会更新端口映射的权限列表，把服务器的第二个IP也加入允许范围——更关键的是，很多Full-cone NAT在这个时候会直接把端口映射设置为全局开放，后续任何外部IP的请求都能通过，这也是为什么之后P2P连接会稳定。

2. NAT映射的“状态确认机制” #

部分路由器的NAT实现有个隐性逻辑：新创建的端口映射需要收到至少一次来自非请求源IP的流量，才能确认这个映射是“合法”的全局映射，否则只会限制在请求源IP范围内。你的初始binding请求只有服务器一个IP的回复，满足不了这个“确认条件”，所以映射处于半开放状态；而CHANGE-REQUEST的跨IP响应刚好触发了这个确认机制，让映射彻底生效。

3. “随机”的本质是NAT内部状态的不确定性 #

你觉得“随机”，其实是不同路由器（甚至同一路由器不同时间）的状态更新时机不一样：

• 有时候路由器刚好在第二个客户端发起连接前，自动完成了映射的全局开放（比如内部定时器触发），这时候首次尝试就成功；
• 有时候需要等待外部跨IP流量触发，这时候就需要多次重试，直到CHANGE-REQUEST的响应完成了映射激活。

解决方案 #

要把随机成功率变成100%稳定，你可以这么做：

• 强制先完成CHANGE-REQUEST流程：在两个客户端开始交换地址、发起P2P连接前，必须先发送带CHANGE-REQUEST扩展的binding请求，并且等待收到来自STUN服务器非初始IP的响应。只有确认这个响应收到后，再进行后续的P2P握手。
• 优化CHANGE-REQUEST参数：如果STUN服务器支持，在CHANGE-REQUEST扩展中同时设置change-ip和change-port标志（对应STUN协议中的0x0001和0x0002位），这样能更彻底地触发NAT的映射更新。
• 增加映射有效性验证：收到CHANGE-REQUEST响应后，可以额外发送一个测试数据包到服务器的第二个IP，确认端口映射确实已经开放，再进入P2P连接阶段。

内容的提问来源于stack exchange，提问作者Evil Activity