前端无法绕过WSS证书校验，因浏览器在TLS握手阶段强制验证证书有效性，该过程早于JavaScript执行且无API干预；解决必须从服务端入手，如使用有效CA证书、反向代理TLS终结或开发环境临时配置。
WebSocket 连接因 SSL 证书校验失败而中断，本质是浏览器强制执行的安全策略，**无法在前端 HTML5 代码中绕过或禁用证书校验**。这是设计使然，不是 bug，也不是可通过 JavaScript 配置解决的问题。
为什么前端无法处理证书校验失败
当使用 wss:// 协议时，浏览器会在建立 TLS 握手阶段验证服务器证书的有效性（如是否过期、域名是否匹配、是否由受信 CA 签发）。一旦校验失败（例如自签名证书、域名不匹配、证书链不完整），浏览器会直接中止连接，甚至不触发 onerror 或 onclose 回调，WebSocket 对象可能停留在 CONNECTING 状态或立即变为 CLOSED（readyState = 0），且 event.code 通常为 1006（abnormal closure）。
关键点：
- 证书校验发生在网络栈底层（Blink/WebKit 网络层），早于 JavaScript 执行时机；
- HTML5 规范未提供任何 API 控制 TLS 行为（如忽略证书错误）；
- 所有现代浏览器（Chrome、Firefox、Safari、Edge）均严格遵循该策略，无例外配置项。
真正可行的解决路径
必须从服务端或部署环境入手，而非修改前端代码：
立即学习“前端免费学习笔记（深入）”；
- 使用合法有效的 TLS 证书：通过 Let's Encrypt 免费获取并正确部署，确保域名匹配、证书链完整、私钥权限正确；
-
开发环境临时方案：仅限本地调试，不要用于测试或生产：
– Chrome 启动时添加--unsafely-treat-insecure-origin-as-secure="wss://your-domain:port" --user-data-dir=/tmp/chrome-test（需配合--user-data-dir）；
– Firefox 地址栏访问about:config→ 搜索security.enterprise_roots.enabled并设为true（仅支持企业根证书）；
– 浏览器手动访问wss://your-domain:port页面 → 点击地址栏锁图标 → “证书” → “导出” → 将根证书导入系统/浏览器信任库（适用于自签名 CA）； -
反向代理统一出口：若后端 WebSocket 服务本身无 HTTPS，可在 Nginx / Caddy 前置一层带有效证书的反向代理，将
wss://请求代理到内网ws://localhost:port，由代理完成 TLS 终结；
前端可做的健壮性增强
虽不能修复证书问题，但可提升用户体验和排障效率：
-
明确区分连接失败类型：监听
onerror和onclose，检查readyState和event.code；1006 通常指向网络或证书问题，而非业务逻辑错误； - 添加连接重试与退避机制：避免频繁无效重连，例如指数退避 + 最大重试次数限制；
-
引导用户检查环境：在连接失败且
readyState === 0时，提示“请确认网站地址是否正确、是否使用了有效的 HTTPS 证书，或尝试刷新页面”； -
日志辅助定位：在
onerror中记录时间戳和 URL，结合浏览器开发者工具的 Security / Network 标签页查看具体证书错误详情（如 NET::ERR_CERT_INVALID）。
绝对要避免的做法
以下方式不仅无效，还存在严重风险或技术不可行：
- 试图用
XMLHttpRequest或fetch发起 wss 请求（协议不兼容）； - 在 WebSocket 构造函数中传入自定义证书参数（API 不支持）；
- 用 Node.js 的
rejectUnauthorized: false思路套用到浏览器（该选项仅存在于 Node.js 的https模块）； - 诱导用户永久点击“继续前往不安全网站”（现代浏览器已移除该选项，尤其对 wss）。
归根结底，SSL 证书问题必须在服务端解决。前端能做的只有清晰反馈、合理重试和友好提示。把证书配置好，WebSocket 连接自然就通了。
