WSS 配置需TLS层完整支撑：直连模式用https.createServer加载fullchain.pem和privkey.pem监听443；反代模式由Nginx终止SSL并透传Upgrade头；Python需ssl.SSLContext.load_cert_chain加载证书链。
WSS 不是单独“配个 ssl_certificate 就能用”，它依赖完整的 TLS 传输层支撑——要么服务端自己加载证书私钥直连监听 443，要么靠 Nginx/Apache 终止 SSL 后透传 Upgrade 连接。选错路径，wss:// 会直接报 ERR_SSL_PROTOCOL_ERROR 或连接被重置。
Node.js + ws 库：用 https.createServer 加载证书启动 WSS
这是最直白的直连模式，适合小规模部署或调试。关键不是调 WebSocketServer 的某个参数，而是把 WebSocket 挂在 HTTPS 服务器实例上。
-
cert和key必须是 PEM 格式；若用 Let's Encrypt，路径通常是/etc/letsencrypt/live/yourdomain.com/fullchain.pem和/etc/letsencrypt/live/yourdomain.com/privkey.pem - 不能只传
key.pem—— 缺少中间证书会导致部分客户端（如 iOS Safari）握手失败；fullchain.pem已含证书+中间链，必须用它 - 监听端口必须是 443（或用户明确配置的 HTTPS 端口），否则浏览器会拒绝
wss://连接（除非加端口号，但不推荐） - 示例代码里别漏掉
https.createServer(...)，直接传{ port: 443, cert, key }给WebSocketServer是无效的（ws库 v8+ 已移除该写法）
Nginx 反向代理：ssl_certificate 配在这里，不是后端代码里
生产环境首选。Nginx 负责 TLS 握手和加密解密，后端 WebSocket 服务仍跑在 HTTP（如 localhost:3000），完全不用碰证书文件。
-
ssl_certificate和ssl_certificate_key必须写在server { listen 443 ssl; ... }块内，不能放在location里 - WebSocket 透传三要素缺一不可：
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"；漏掉任一，连接会在 101 Switching Protocols 阶段卡住或降级为 HTTP - 如果后端服务监听的是 Unix socket（如
unix:/var/run/ws.sock），proxy_pass要写成http://unix:/var/run/ws.sock;，且确保 Nginx 用户有读权限 - 不要在 Nginx 里配
ssl_protocols TLSv1.2 TLSv1.3以外的协议——TLSv1.0和TLSv1.1已被主流浏览器弃用，强行开启反而导致握手失败
Python websockets 库：ssl_context.load_cert_chain 是唯一入口
Python 的 websockets 库不接受 PEM 字符串或路径字符串，必须显式构造 ssl.SSLContext 并加载证书链。
- 别用
ssl.create_default_context()直接传参——它没有load_cert_chain方法；必须用ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)或ssl.create_default_context(ssl.Purpose.CLIENT_AUTH) -
certfile参数要填完整证书链（即fullchain.pem），不是单个域名证书；keyfile是私钥，两者路径必须可被 Python 进程读取（注意 systemd 服务的WorkingDirectory和文件权限） - 若用自签名证书测试，客户端（如浏览器）会提示不安全；此时需手动访问
https://yourdomain.com并信任该证书，否则wss://连接会被静默拒绝 - 启动命令里不能加
--ssl或类似开关——websockets.serve()的ssl参数只接收已配置好的ssl_context对象
常见失败现象与定位线索
WSS 配置失败往往不是“连不上”，而是卡在某个协议层，得看具体错误才好下手。
- 浏览器控制台报
net::ERR_CONNECTION_CLOSED或net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH→ 大概率是 Nginx 或服务端 TLS 版本/密码套件不兼容，检查ssl_protocols和ssl_ciphers配置 - 抓包看到 TCP 握手成功但没 TLS Client Hello → 服务端没监听 443，或防火墙/安全组拦截了 443 端口
- Nginx error log 出现
upstream sent no valid HTTP/1.0 header→ 后端服务返回的不是合法 HTTP 响应（比如直接吐了 WebSocket 帧），说明代理路径或后端逻辑有误 - 用
curl -I -k https://yourdomain.com能拿到 200，但wss://连接立刻关闭 → 很可能Upgrade头没透传，检查 Nginx 的proxy_set_header是否拼写错误（如写成Upgrde）
证书路径写错、Upgrade 头漏传、fullchain.pem 和 privkey.pem 权限不对——这三个点加起来覆盖了 80% 的 WSS 配置失败场景。别急着查文档，先盯住 Nginx error log 或服务端启动日志里的第一行报错。
