关键在于选对框架、配好网络参数并适配长连接：Node.js用alpine镜像禁用watch命令，Go用多阶段构建生成静态二进制，Swoole需cli镜像并启用sockets，websocketd最轻量，uWebSockets需ubuntu基础镜像和CGO支持；Nginx代理必须透传Upgrade头、设proxy_read_timeout超长值；容器须加restart策略、资源限制、ping/pong保活及wss强制加密。
用Docker部署高性能WebSocket服务器，关键不在“装容器”，而在于选对底层服务框架、配好网络与连接参数，并让容器真正适配长连接场景。Node.js（ws库）、Go（gorilla/websocket）、Swoole、uWebSockets 或 websocketd 都是成熟选择，但它们的容器化方式和调优重点各不相同。
选型决定容器结构
不同技术栈对Docker镜像构建和运行模式有直接影响：
-
Node.js + ws：适合快速验证和中低并发，用
node:18-alpine基础镜像，CMD ["node", "server.js"]启动常驻进程，注意禁用npm start这类带watch的开发命令 -
Go原生实现：编译成静态二进制后体积极小，推荐多阶段构建——build阶段用
golang:1.22，runtime阶段用scratch或alpine:latest，无依赖、启动快、内存占用低 -
Swoole/Workerman（PHP）：必须用
php:8.2-cli-alpine而非fpm镜像，因FPM生命周期短，无法维持WebSocket连接；需显式安装swoole扩展并启用--enable-sockets -
websocketd：最轻量，适合已有bash/python脚本快速暴露为WebSocket服务；Dockerfile只需
apk add bash wget再下载二进制即可，无需语言运行时 -
uWebSockets：C++编写，性能极高，适合万级并发；需在Docker中启用
CGO_ENABLED=1并链接musl-dev等系统库，建议用ubuntu:22.04而非Alpine避免兼容问题
网络与连接必须显式配置
Docker默认网络模型不自动适配WebSocket长连接，几个关键点不能漏：
- 容器启动时加
--restart=unless-stopped，防止进程退出后连接中断无人接管 - Nginx反向代理WebSocket必须透传关键头：
Upgrade、Connection: upgrade，并在location块中设置proxy_read_timeout 86400（避免默认60秒断连） - 宿主机防火墙要放行WebSocket端口（如3000），且Docker映射使用
-p 3000:3000而非127.0.0.1:3000:3000，否则外部无法建连 - 若用
docker-compose，建议定义network_mode: host或自建bridge网络，避免NAT层引入延迟和连接复用问题
生产环境必做的三件事
容器跑起来只是第一步，稳定性和可观测性靠这几项落地：
-
连接保活：服务端主动发ping帧（如每30秒），客户端超时未回pong则关闭连接；Go用
conn.SetPingHandler，Node用ws.ping() -
资源限制：在
docker run中加--memory=512m --cpus=1.0，防止单实例吃光宿主机资源；Swoole可设worker_num=4匹配CPU核心数 -
日志与监控：标准输出日志不重定向，直接由Docker收集；用
docker logs -f查连接异常；高并发下建议集成Prometheus + Grafana，监控upgrader.HandshakeCount、Conn.CloseCount等指标
安全与证书不能跳过
所有对外服务的WebSocket必须走wss（WebSocket over TLS），否则现代浏览器会直接拒绝连接：
- 证书通过volume挂载进Nginx容器：
- ./certs/fullchain.pem:/etc/nginx/ssl/fullchain.pem:ro - Nginx配置中强制HTTP跳转HTTPS，并开启HSTS：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; - 服务端代码中严格校验Origin（尤其当多个前端域名共用同一后端时），禁止
return true式的宽松策略 - 若用Let’s Encrypt，推荐
nginx-proxy+acme-companion组合自动签发，无需手动续期
