为何使用host网络命名空间的两个Docker容器可绑定同一端口？

这个问题我之前排查过类似的情况，核心原因其实和Docker的host网络关系不大，而是你容器里用的nc命令的特性，以及Linux套接字的选项设置。

关键原因：容器内的nc默认启用了特殊套接字选项 #

你在容器里用的是Debian自带的BSD风格nc，它默认会启用SO_REUSEADDR和SO_REUSEPORT这两个套接字选项：

• SO_REUSEADDR：允许绑定到处于TIME_WAIT状态的端口，也支持同一端口被不同IP绑定的场景；
• SO_REUSEPORT（Linux内核3.9+支持）：允许多个进程同时绑定到同一个IP:端口组合，内核会自动把新连接负载均衡到各个监听进程。

而你在主机上测试时，要么用的是GNU风格的nc（比如RHEL默认的ncat），要么是像Nginx、SSH这类服务，它们默认不会启用SO_REUSEPORT，所以当尝试绑定已被监听的端口时，内核会直接返回Address already in use错误。

对应你场景的具体流程 #

1. 第一个容器启动时，nc -l -p 80绑定0.0.0.0:80，同时启用了上述两个选项，进入监听状态；
2. 第二个容器启动时，同样的nc命令尝试绑定同一端口，因为SO_REUSEPORT已启用，内核允许这个绑定操作；
3. 此时两个nc进程都在监听0.0.0.0:80：已存在的连接会继续由第一个进程处理（因为连接是和第一个进程的套接字关联的），而新发起的连接会被内核分配给第二个进程（你看到的netstat显示第二个PID，是因为它是最后一个绑定的进程，或者内核的负载均衡策略偏向新进程）；
4. 当你尝试让容器绑定主机已在监听的端口时失败，是因为主机上的进程没有启用SO_REUSEPORT，内核不允许跨进程的重复绑定。

验证方法 #

你可以在主机上安装BSD风格的nc（比如RHEL上执行dnf install nc-openbsd），然后在两个终端分别运行：

nc -l -p 80

你会发现第二个命令也能成功启动，和容器里的现象完全一致，这就证明了问题出在nc的实现，而非Docker的host网络特性。

备注：内容来源于stack exchange，提问作者Benibr