WebSocket服务需绑定0.0.0.0而非127.0.0.1，容器访问宿主机服务应使用host.docker.internal或宿主机真实IP，Linux需手动添加extra_hosts，同时检查防火墙及监听配置。
WebSocket服务绑定的是127.0.0.1，容器内根本连不到宿主机
这是最常被忽略的根源：代码里写 ws://127.0.0.1:8888 或 http://localhost:8888，在 Docker 容器里运行时，127.0.0.1 指的是容器自己，不是宿主机。哪怕你用了 -p 8988:8888，这个映射只解决「外部访问容器」，不解决「容器访问宿主机」。
必须改代码，把监听地址从 127.0.0.1 改成 0.0.0.0（或具体网卡 IP），否则 WebSocket Server 根本不接收来自宿主机的连接请求。
- Node.js 的
ws库：启动 server 时传{ host: '0.0.0.0' } - .NET 的
WebSocketServer：监听地址不能是127.0.0.1，得用IPAddress.Any - Python 的
websockets.serve：第一个参数是host，别写死'localhost'，写'0.0.0.0'
Docker容器要访问宿主机上的WebSocket服务，不能靠-p映射
-p 8988:8888 这类端口映射，方向是「宿主机 → 容器」，而容器主动连宿主机的 WS 服务，需要反向通路。这时候 -p 完全无效。
可行方案只有两个：
- Linux 下用
--network=host：容器直接共享宿主机网络栈，ws://localhost:8888就能连上宿主机进程（注意：此模式下ports配置失效，且有安全风险） - 通用方案：用宿主机真实 IP（如
192.168.x.x）代替localhost；在容器内通过host.docker.internal（Docker Desktop / Docker for Mac/Win 默认支持，Linux 需手动加--add-host=host.docker.internal:host-gateway）
别试 172.17.0.1 —— 这是 bridge 网络的网关 IP，不一定能通宿主机上监听 127.0.0.1 的服务（因为很多服务默认不监听该地址）。
宿主机防火墙和监听地址双重拦截
即使代码绑定了 0.0.0.0、容器也用了正确 host，还可能连不上。原因有两个：
- 宿主机防火墙（如
ufw、firewalld、iptables）拦了入站连接：检查是否允许目标端口，例如sudo ufw allow 8888 - 宿主机上的 WebSocket 服务只监听
127.0.0.1：比如用npx wscat -l 8888启的服务，默认只响应本地回环，容器发来的包直接被丢弃
验证方法：在宿主机执行 curl -v http://192.168.x.x:8888（用局域网 IP），如果失败，说明服务没监听对外地址或被防火墙挡了。
docker-compose.yml 中容易漏掉的关键配置
用 docker-compose 启动时，光写 ports 不够，还得确认三件事：
-
environment里有没有覆盖掉监听地址（比如 Node.js 的HOST环境变量被设成localhost） - 若需容器访问宿主机服务，Linux 环境下必须显式加
extra_hosts：extra_hosts: ["host.docker.internal:host-gateway"] -
network_mode: "host"和ports互斥，写了前者，后者会被忽略——别同时配
复杂点在于：WebSocket 连接建立后还要维持长连接，NAT、代理、TCP keepalive 设置不当，会在空闲后被中间设备静默断开，这问题不会在本地直连时暴露，一进 Docker 就浮现。调试时建议先用 wscat 手动连，绕过业务逻辑，快速定位是网络层还是协议层问题。
