Wss是基于TLS/SSL加密的WebSocket协议，Ws是明文传输；二者端口默认为443和80，浏览器禁止HTTPS页面使用Ws，Wss需正确配置证书链与域名匹配。
Ws 是不加密的 WebSocket 协议，Wss 是基于 TLS/SSL 加密的 WebSocket 协议，本质区别在于传输层是否启用安全通道。Wss 类似于 HTTPS 之于 HTTP，必须通过有效证书建立加密连接，否则浏览器会拒绝连接。
Ws 与 Wss 的核心差异
协议层面：ws:// 使用明文 TCP 连接，数据在传输中可被中间节点截获或篡改；wss:// 强制使用 TLS 握手（通常为 TLS 1.2 或更高），所有帧数据均加密传输。
端口默认值：ws 默认走 80 端口，wss 默认走 443 端口（但实际取决于服务器配置）；
浏览器限制：现代浏览器禁止在 HTTPS 页面中建立 ws 连接（混合内容策略），必须用 wss 才能与安全上下文兼容；
代理与防火墙：wss 流量常被识别为标准 HTTPS 流量，更容易穿透企业级代理和防火墙；ws 则可能被拦截或重置。
服务端启用 Wss 的常见配置方式
以主流服务器为例，关键在于将 WebSocket 升级请求交由 HTTPS 服务处理，并确保 TLS 终止在反向代理或应用层：
- Node.js + ws 库：需传入 https.Server 实例（而非 http.Server），并提供 key/cert 选项；证书可为自签名（开发用）或 Let's Encrypt 正式证书（生产用）
- Nginx 反向代理：监听 443 端口并配置 SSL，将 /ws 路径 proxy_pass 到后端 ws 服务，同时设置 proxy_http_version 1.1、upgrade 和 connection 头以支持 WebSocket 升级
- Apache：启用 mod_ssl 和 mod_proxy_wstunnel，用 ProxyPassMatch 匹配 wss 路径，确保 SSLProxyEngine on 并验证后端证书（如需）
前端连接时的注意事项
客户端代码看似一致，但协议前缀决定底层行为：
- 页面若通过 https:// 加载，则 new WebSocket("ws://...") 会被浏览器直接阻止，控制台报错 "Mixed Content"
- 应统一使用环境变量或运行时判断：开发环境可用 ws://localhost:3000，生产环境强制 wss://api.example.com
- 连接失败时优先检查：浏览器地址栏是否显示锁形图标、控制台是否提示证书错误（如 NET::ERR_CERT_INVALID）、服务端 TLS 是否启用且证书未过期
证书配置要点（避免常见陷阱）
Wss 不是简单加个 https 就行，证书链和域名匹配直接影响连接成败：
立即学习“前端免费学习笔记（深入）”；
- 证书域名必须覆盖 WebSocket 所用的主机名（如 wss://chat.example.com，则证书需包含 chat.example.com 或泛域名 *.example.com）
- 自签名证书不能用于生产，浏览器会拒绝；开发测试时可在 Chrome 启动参数加 --unsafely-treat-insecure-origin-as-secure="ws://..."（仅限本地调试）
- 使用 Let's Encrypt 时，certbot 生成的 fullchain.pem 是证书+中间 CA 链，务必用它而非 cert.pem 单独文件，否则部分客户端握手失败
- Node.js 中若用 fs.readFileSync 读取证书，路径错误或权限不足会导致服务启动无报错但 wss 连接立即关闭
