症状：TCP 跑得欢，UDP 就装死
兄弟们，今天聊个让人血压飙升的坑。
你辛辛苦苦配好了 Docker 容器，-p 5005:5005/udp 写得明明白白，TCP 端口转发丝般顺滑，唯独 UDP 数据包就是死活进不去容器。
更邪门的是——在 Linux 宿主上跑得好好的，一模一样的镜像，一到 Windows 10 就翻车。
我上周在监控系统里部署一个 SNMP trap 接收器（snmptrapd），本地用 Python 往 127.0.0.1:5005 发 UDP 包，Wireshark 抓包一看——空空如也。数据包就像被黑洞吸走了一样。
这不是你配置写错了，这是 Docker Desktop on Windows 的一个已知顽疾。
Root Cause：WinNAT 和 Loopback 的世纪恩怨
问题的根子在于 Windows 的网络栈设计。
Docker Desktop 在 Windows 上依赖 WinNAT（Windows Network Address Translation） 来做端口映射。这个组件对 TCP 处理得还行，但对 UDP 的支持就是个半成品。
具体来说，当你用 -p 5005:5005/udp 暴露端口时，Docker 会在 WinNAT 里创建一条 UDP 转发规则。但问题来了——WinNAT 默认不转发发往 127.0.0.1 的 UDP 流量。
这就意味着：
- 从外部 IP 发来的 UDP 包 → 能进（经过物理网卡 → WinNAT → 容器）
- 从 本机 发往 127.0.0.1 的 UDP 包 → 死路一条（WinNAT 直接忽略）
Reddit 上有人用 Wireshark 验证过这个现象：本机发 UDP 到 127.0.0.1:5005，抓包根本看不到任何流量。不是被防火墙拦了，是数据包根本没经过 WinNAT 的转发路径。
另一个更蛋疼的问题是 WinNAT 服务（winnat）偶尔会卡死，导致所有 UDP 端口映射全部失效，但 TCP 却一切正常。这种现象在 Windows 10 的某些版本更新后尤其频繁。
修复方案：五步走，从软重启到硬核改网
方案一：重启 WinNAT 服务（最快速，但治标不治本）
# 管理员权限运行
net stop winnat
net start winnat
这个操作会清空 WinNAT 的所有 NAT 规则并重建。执行完后重启 Docker Desktop，UDP 端口映射大概率能恢复。
但注意——这只是临时方案。winnat 服务重启后，过一段时间可能又会挂掉。我见过最离谱的情况是每两小时就要重启一次。
方案二：强制重建 Docker 的 NAT 网络
当 WinNAT 重启无效时，问题可能出在 Docker 创建的默认 NAT 网络损坏。
# 1. 停止所有容器
docker stop $(docker ps -aq)
# 2. 删除 Docker 的默认 NAT 网络
docker network rm nat
# 3. 重启 Docker Desktop（这会自动重建 nat 网络）
执行完这套操作后，Docker 会重新向 WinNAT 注册端口映射规则，通常能解决持久性的 UDP 转发问题。
方案三：改用 host 网络模式（绕过 WinNAT，但有限制）
如果容器只需要监听 UDP，可以直接用 --network host 模式，让容器直接绑定宿主机的网络栈：
docker run --network host -d your-image
这样 UDP 流量直接到达容器内的进程，完全绕过 WinNAT 的转发。
但有个坑：Windows 上 Docker 的 host 网络模式限制很多，某些版本的 Docker Desktop 甚至不支持。而且 host 模式会失去端口隔离，所有端口都暴露在宿主机上。
方案四：使用 docker-compose 显式指定协议（防呆配置）
有时候问题出在 Docker 默认将端口同时绑定 TCP 和 UDP，导致冲突。
version: '3.8'
services:
snmptrapd:
image: your-snmp-image
ports:
- "162:162/udp" # 只绑定 UDP
# 不要写 "162:162" 不加协议后缀，这会同时绑定 TCP 和 UDP
在 docker-compose 里显式只绑定 UDP 端口，可以避免 Docker Desktop 在端口注册时产生的协议冲突。
方案五：终极方案——改用 Linux 容器或 WSL2 原生模式
如果以上方案全翻车，说明 Windows 的 WinNAT 实现有底层 bug，只能换跑道。
推荐做法：将 Docker Desktop 切换到 WSL2 后端，然后在 WSL2 的 Linux 发行版中运行 Docker 守护进程。
# 1. 确保 Docker Desktop 使用 WSL2 引擎
# 设置 → General → Use the WSL 2 based engine (勾选)
# 2. 在 WSL2 中直接运行 Docker
wsl --set-default-version 2
wsl
# 在 WSL2 终端里：
sudo dockerd &
docker run -p 5005:5005/udp your-image
在 WSL2 里，Docker 跑的是原生的 Linux 网络栈，UDP 转发完全遵循 Linux 内核的行为——稳定、可靠、没有 WinNAT 的幺蛾子。
对比：各方案优缺点
| 方案 | 修复成功率 | 持久性 | 操作复杂度 | 是否影响其他容器 |
|---|---|---|---|---|
| 重启 WinNAT | 60% | 低（几小时到几天） | 低 | 短暂中断 |
| 重建 NAT 网络 | 80% | 中（数天到数周） | 中 | 需重启所有容器 |
| host 网络模式 | 95% | 高 | 低 | 失去端口隔离 |
| docker-compose 显式协议 | 40% | 取决于根本原因 | 低 | 无 |
| 迁移到 WSL2 | 99% | 永久 | 高（需迁移环境） | 需重新部署 |
FAQ
Q: UDP 端口转发在 Windows 上为什么比 TCP 更容易出问题？
A: Windows 的 WinNAT 组件对 TCP 的状态跟踪（stateful tracking）实现得比较完善，但 UDP 是无连接的，WinNAT 的 NAT 会话表对 UDP 条目的管理和超时处理有缺陷。具体来说，当 UDP 端口映射条目在 WinNAT 内部损坏或超时后，不会自动重建，导致后续的 UDP 数据包无法被正确转发。
Q: 如何验证 UDP 端口转发是否真的在工作？
A: 两步验证法。第一步，在容器内启动一个 UDP 监听器（如 nc -ul 5005），在宿主机上用 Test-NetConnection -ComputerName 127.0.0.1 -Port 5005 -Protocol UDP（PowerShell）测试。第二步，用 Wireshark 抓取 loopback 接口的流量，如果能看到 UDP 包但容器收不到，说明问题在 WinNAT 层；如果 Wireshark 都看不到包，说明问题在更底层。
Q: Docker Desktop 的端口绑定报错 “Ports are not available” 怎么解决？
A: 这个错误通常是因为之前运行的容器没有正确释放端口。执行 net stop winnat && net start winnat 清空 NAT 状态表，然后重启 Docker Desktop。如果问题依旧，检查是否有其他进程（如 Hyper-V 的 VM 或 Windows 的某些服务）占用了该 UDP 端口。用 netstat -an | findstr :5005 查看端口占用情况。
Q: 为什么在 Linux 上没这个问题？
A: Linux 的 Docker 直接使用内核的 iptables/nftables 做端口转发，这是 Linux 网络栈的原生能力，对 UDP 的支持非常成熟。Windows 的 Docker Desktop 需要经过 Hyper-V 虚拟化层和 WinNAT 两层转换，每多一层就多一个故障点。
社区灵感与参考 (References & Community Insights)
本文探讨的架构演进与技术实现方案，深度提炼自 Hacker News、Reddit 等极客社区的真实工程师讨论、线上事故复盘（Post-mortems）以及一线技术博客的实战经验分享。
