WebSocket服务连不上90%是因监听地址写死127.0.0.1，容器内该地址仅响应内部回环请求；必须改为0.0.0.0监听所有接口，并配合正确端口映射（如-p 8080:8080）和客户端使用宿主机IP访问。
WebSocket服务在Docker容器里连不上，90%的情况不是协议问题，而是服务监听地址写死了 127.0.0.1 或 localhost，导致容器网络隔离后外部请求根本进不来。
服务必须监听 0.0.0.0 而不是 127.0.0.1
本地开发时用 127.0.0.1 没问题，但放进容器后，这个地址只响应容器内部的 loopback 请求，宿主机或外部客户端发来的包会被直接丢弃。
- Node.js（
ws库）：启动时指定host: '0.0.0.0'，不能只靠port - Python（
websockets）：start_server(host='0.0.0.0', port=8080)，缺一不可 - .NET（
Microsoft.AspNetCore.WebSockets）：确保 Kestrel 的Urls配置包含http://0.0.0.0:8080 - 如果用
websocketd：命令行必须加--address=0.0.0.0:8080，默认只绑127.0.0.1
docker run 或 docker-compose 的 ports 映射必须显式声明
只写 -p 8080 是不够的，Docker 不会自动把容器内 8080 映射到宿主机 8080；必须写成 -p 8080:8080 这种完整格式，否则端口根本没暴露。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
docker run -p 8080:8080 my-ws-app—— 正确 -
docker run -p 8080 my-ws-app—— 宿主机端口由 Docker 随机分配，无法预测，连不上 - Docker Compose 中
ports字段必须是字符串数组，如- "8080:8080"，不能写成数字或对象 - 如果服务实际监听的是 UDP（比如某些 WebRTC 辅助场景），还得额外加
/udp后缀：- "8080:8080/udp"
客户端连接 URL 必须用宿主机 IP 或域名，不能用 localhost
你在浏览器或测试工具里访问 ws://localhost:8080，其实是在连你本机的 8080 端口，而不是 Docker 容器——除非容器是用 --network=host 启动的（不推荐）。
- 宿主机上测试：用
ws://127.0.0.1:8080或ws://localhost:8080可以（因为端口已映射到宿主机） - 其他机器访问：必须用宿主机真实 IP，如
ws://192.168.1.100:8080，不能用localhost - 如果你配了反向代理（Nginx / Ingress），客户端连的是代理地址，那就要确保代理正确转发
Upgrade和Connection头，否则握手阶段就失败
防火墙和云服务器安全组常被忽略
Docker 的 -p 只负责容器与宿主机之间的端口绑定，不触碰系统级网络策略。宿主机防火墙或云平台安全组若没放行对应端口，请求在到达 Docker 前就被拦了。
- Linux 上检查：
sudo ufw status或sudo iptables -L -n | grep 8080 - 阿里云/腾讯云等控制台中，确认安全组入方向规则放行了 TCP 8080（或你用的端口）
- Mac 使用 Docker Desktop 时，一般不用额外开防火墙；但 Windows WSL2 下，宿主机防火墙可能拦截，需手动允许
- 如果用
docker run --network=host，Docker 不再做 NAT，此时端口暴露完全依赖宿主机配置，风险更高，慎用
最容易卡住的地方，其实是代码里那个不起眼的 host 参数——它不像 HTTP 服务那样有默认行为，WebSocket 服务一旦监听错地址，日志里通常不会报错，只是静默拒绝连接。动手前先确认这一项，能省掉大半排查时间。
