Node.js在Docker占用端口时未抛出EADDRINUSE错误的原因排查

这是个挺典型的跨网络栈+容器转发问题，核心差异在于Docker for macOS的端口处理方式，以及Node.js默认的绑定策略，我来一步步拆解清楚：

1. Node.js默认绑定的地址是什么？ #

当你只传端口调用server.listen(3000)时，Node.js默认会绑定IPv6的::地址（也就是所有IPv6网络接口）。虽然很多系统会让IPv6绑定兼容IPv4流量，但macOS的网络栈默认是把IPv4和IPv6分开处理的，这是关键前提。

2. Docker for macOS的端口映射不只是“绑定端口” #

当你运行docker run -d -p 3000:80 nginx时，Docker并没有在你的Mac宿主系统上直接启动一个进程监听3000端口——它用的是macOS内置的pf（Packet Filter）防火墙来做流量转发：

• 所有发往Mac宿主0.0.0.0:3000（IPv4）和[::]:3000（IPv6）的流量，都会被pf规则直接截获，转发到Docker后台的Linux虚拟机里的nginx容器。
• 划重点：Docker没有在Mac宿主的端口上真正绑定监听进程，只是通过防火墙规则“抢”走了所有发往这个端口的流量。

3. 为什么Node.js能启动却收不到请求？ #

• 当Node.js绑定:::3000（IPv6）时，系统检测到这个端口并没有被其他进程占用（因为Docker没在宿主绑定IPv6端口，只是转发流量），所以Node.js顺利启动，打印Server running.。
• 但不管你访问http://localhost:3000、http://127.0.0.1:3000还是http://[::1]:3000，所有流量都被pf规则优先转发到了Docker容器，Node.js的服务器根本碰不到这些请求，自然就“无响应”了。

4. 为什么绑定0.0.0.0会触发EADDRINUSE？ #

当你显式指定server.listen(3000, '0.0.0.0')时，Node.js会绑定IPv4的0.0.0.0地址（所有IPv4网络接口）。这时候，Docker for macOS实际上会在Mac宿主的IPv4端口上启动一个代理进程来处理转发，这个进程已经牢牢绑定了0.0.0.0:3000，所以Node.js尝试绑定同一个端口时，就会触发EADDRINUSE错误，这才符合你预期的“端口被占用”表现。

快速验证方法 #

你可以在Mac上用lsof -i :3000命令查看端口占用：

• 运行Docker容器后，会看到com.docker.backend进程绑定了0.0.0.0:3000（IPv4），但找不到IPv6的:::3000绑定记录。
• 启动Node.js默认服务器后，lsof会显示Node.js进程绑定了:::3000（IPv6），但这个端口的流量已经被pf转走了，所以服务器收不到请求。

内容的提问来源于stack exchange，提问作者Golo Roden