我知道“连接”这个词在谈论 UDP 时并不合适，但是......
服务器（具有已知 IP 的服务器）如何通过 Internet 将其 UDP 数据包发送到位于 NAT 后面的客户端？
例如：假设客户端使用 TCP 上的一些消息连接并验证服务器。此时，服务器已准备好开始通过 UDP 将数据流式传输到客户端，但服务器如何知道将 UDP 数据包寻址到何处，以便它们可以通过任何 NAT 路由器到达客户端？
如果客户端通过 UDP 发送“我已准备好进行流式传输”消息，NAT 路由器是否会保持端口打开，以便服务器可以使用其 UDP 数据流进行响应？
还是我在这里偏离轨道？
忽略在您的路由器（提供 NAT）中提供已知端口转换（即此端口上的数据到此地址），您可以使用UDP Hole Punching。
我假设您不是在谈论多播，其中每个对等方都加入一个组并向感兴趣的各方（在这种情况下是路由器）宣布，然后可以执行适当的路由。尽管这通常用于将流量有效地路由到多个主机，但按组路由机制将适用于您在上面描述的。
通常，客户端前面的 TCP 级别的 NAT 将能够确定 UDP 上的连接已创建。话虽如此，客户端的 NAT 必须配置为接受来自 SRC 服务器端口的 UDP 数据包，然后将它们转发到内部目标 IP（客户端）。如果 NAT 是谁是呼叫者，谁是被呼叫者，请记住重要的事情。NAT 在实现和功能上有所不同，因此您可能想要实现一个易于实现的通用解决方案，具体取决于您的需要。
我认为，您的假设是正确的，在您的情况下，客户端将无法接收信息中的 UDP 流。在您的情况下，您的客户端必须将其 WAN IP 发送到您的服务器以启动 UDP 连接。找到您的客户 WAN IP 可能会很棘手，但是有些网站可以通过在文本页面中返回它来帮助您确定您的 WAN IP。
如果 UDP 连接是在 TCP 连接之后由服务器向客户端打开一个已知 UDP 端口的套接字创建的，那么 UPnP 可能值得研究一下，它将允许您在 NAT 上自动设置端口转发，这只是如果您的 NAT 像 DSL 路由器一样支持 UPnP。
一个工作是让客户端打开服务器的 TCP 和 UDP 套接字。由于 NAT 后面的客户端发起了连接，因此 TCP 和 UDP 连接的状态都将添加到 NAT 的连接表中。
如果您在谈论像 SIP 或 RTSP 这样的流协议，那么它的工作方式是客户端希望服务器发送到的 UDP 端口在呼叫建立请求中指定。
服务器将发送到该端口，流量可能会或可能不会通过客户端，这取决于 NAT 是否已将客户端选择的端口转换为不同的数字。
当服务器从客户端接收到它的第一个 UDP 流数据包时，如果它在与它发送的端口不同的端口上，那么它将切换到它。这使得来自服务器的 UDP 可以通过 NAT，因为客户端已经通过发送到服务器来创建 NAT 映射。