为何未发布UDP端口时Docker容器仍可接收UDP响应数据？

已观测到的网络现象 #

• 第一类场景（容器主动访问主机）：容器内应用通过host.docker.internal向主机指定端口发送UDP数据报，主机侧对应端口的监听应用无需Docker配置任何端口发布规则即可正常接收数据，表现符合预期。
• 第二类场景（主机主动访问容器）：主机侧应用通过localhost向环回网卡指定端口发送UDP数据报，容器内对应端口的监听应用必须在容器启动时添加-p <端口号>:<端口号>/udp参数发布端口，才能正常接收数据，表现符合预期。
• 第三类场景（UDP请求-响应双向通信）：容器内运行名为Requestor的应用，先向主机指定端口发送UDP请求报文，随后阻塞等待响应；主机侧运行名为Responder的应用，监听对应端口收到请求后，直接读取请求报文携带的源端点地址回发UDP响应报文。该场景下无需为容器发布响应对应的UDP端口，通信即可正常完成，该表现无法通过已知的端口映射规则解释。

补充说明：已知容器内执行curl www.google.com访问外网时无需发布端口即可接收返回数据，但该场景依赖TCP的连接建立状态机；UDP是无连接协议，无法直接套用TCP连接机制解释该现象。

底层原理说明 #

这里首先纠正一个普遍的认知偏差：状态NAT/防火墙的流量跟踪能力不是TCP专属。UDP虽然没有协议层面的连接握手、断开机制，不代表中间转发的网络设备不会为其维护虚拟的会话状态。
Docker Desktop在Windows环境下并没有直接把容器网络桥接到宿主机网络，所有跨宿主机和容器边界的流量都会经过Docker内置的一层状态NAT网关，这层网关维护的会话表同时覆盖TCP、UDP两种传输层协议：

• 当网关检测到从容器侧（受信任内网侧）主动发出的UDP报文时，会自动生成一条UDP会话记录，条目内会存储四个核心信息：容器内部的源IP+源端口、经过NAT地址转换后在主机侧暴露的临时源IP+端口、该报文的目的IP+端口、会话老化时间（默认通常为30秒到2分钟，无流量持续命中条目就会自动删除）。
• 会话条目存活期间，只要收到符合「源IP为之前记录的报文目的IP、目的IP为NAT转换后的临时IP+端口」特征的反向报文，网关就会自动把报文的目的地址改回对应的容器内部IP+端口，直接转发到对应容器，这个过程不需要任何静态配置的端口映射规则。

对应三类场景的转发逻辑可以完全对齐：

• 第二类主机主动访问容器的场景下，流量到达网关时，会话表中没有任何匹配的容器主动出站记录，网关默认会直接丢弃这类未被授权的主动入站流量；只有添加-p参数配置静态端口映射，网关才会为对应端口添加永久的入站允许规则，将流量定向转发到指定容器，这和普通硬件防火墙的默认拦截逻辑完全一致。
• 第三类请求-响应场景下，容器内Requestor先发请求的动作，已经提前在NAT网关中生成了对应的UDP会话记录。主机上的Responder收到请求后，按照报文携带的源地址回包，这个回包正好命中之前生成的会话条目，属于被允许的反向关联流量，因此会被网关直接转发到容器内的Requestor进程，不需要提前配置静态端口映射。
• 容器内执行curl访问外网无需端口映射的场景，底层逻辑和该UDP场景完全一致：状态NAT不关心上层承载的是TCP还是UDP，只关心流量的发起方向。TCP的会话条目靠SYN、FIN、RST等协议标志位触发创建、销毁，UDP的会话条目靠出站流量触发创建、靠超时自动删除，两者对反向流量的放行逻辑没有本质区别。

额外说明：该场景中使用的host.docker.internal域名，解析出的地址本身就是Docker NAT网关在容器侧的虚拟接口地址，经过该地址的流量会完整经过NAT状态跟踪模块，不会出现流量旁路导致的会话记录遗漏，只要回包在会话老化时间内到达，就可以正常转发到容器内进程。

内容的提问来源于stack exchange，提问作者17tmh