UDP 给 NAT 带来了一个问题，因为没有流量表明连接（端口对）是否不再使用。与 TCP 连接状态相比，UDP 反向路由通常必须过时，TCP 连接状态通常可以由流量跟踪，并且只需要一些超时来清理。

想象一个 DNS 请求：客户端向外部 IP 地址发送 UDP 数据报。NAT 路由器会转换源地址和端口，并且需要记住将任何回复转发到哪里 - 但它无法确定回复何时真正完成。过快地老化这些条目会破坏几个协议，过慢地老化它们会浪费路由器资源（以至于它不再可靠地工作）。

... udp 无连接的事实对他来说是个问题吗？

UDP 是无连接的，这并不是事实；问题是 NAT 能否找出传入数据包的目标计算机。

通常 NAT 假设当一个 UDP 数据包被发送到某个“服务器”并且一个 UDP 数据包从那个“服务器”（使用相同的端口号）返回时，发送第一个 UDP 数据包的计算机是 UDP 数据包的接收者回。

在这种情况下，UDP 使用大多数 NAT 运行良好。

但是，在诸如“端口号必须匹配”之类的简单规则不起作用的情况下， NAT 会出现问题 -即使在 TCP 的情况下：

使用文件传输协议 (FTP) 的原始变体，客户端建立到服务器的 TCP 连接，然后服务器建立返回到客户端的第二个 TCP 连接。

当客户端位于 NAT 之后时，这通常不起作用。

NAT 不“知道”的第 4 层协议（可能是 GRE，对于某些 NAT 甚至可能是 UDP！）无论如何都不起作用。

并且...... QUIC 解决了这个问题吗？

QUIC 基于 UDP，据我所知，服务器返回的数据包的端口号与客户端发送的数据包中的端口号相匹配。如果 NAT 支持 UDP，则上述方式 QUIC 将在该 NAT 上工作。