Electron应用内Socket.IO连接突然失效 独立Node脚本可正常连接

• 运行环境适配差异：socket.io-client会自动识别运行环境，纯Node环境调用Node原生tls/net模块实现连接，Electron环境默认调用Chromium内核的WebSocket API实现，两者的网络校验、传输逻辑存在差异
• SSL证书校验规则差异：Chromium的根证书信任链、SSL校验规则比Node严格，若10月1日前后你的服务端SSL证书刚好出现根证书过期、证书链不完整、证书域名不匹配等问题，Chromium会直接拦截连接，Node环境可能因本地缓存的根证书、宽松校验规则正常连通
• Electron网络策略限制：若你最近更新过Electron应用的CSP（内容安全策略）、webPreferences配置、跨域规则，可能会拦截wss协议的对外连接
• 进程级网络拦截：10月1日前后系统防火墙、安全软件更新了规则，对Electron进程的出站连接做了限制，对Node进程则正常放行
• Socket.IO传输层适配问题：socket.io默认先发起polling请求做握手，再升级为websocket，若Electron环境下polling请求被CORS、跨域规则拦截，会导致整个连接流程中断
• 依赖隐式升级：虽然你调用的是同一个socket.io-client依赖，若最近安装的Electron版本自动携带了不同版本的ws、engine.io-client等子依赖，也可能出现兼容问题

• 首先添加完整的事件监听，捕获具体错误信息，在现有代码中新增如下监听逻辑：

client.on('connect_error', (err) => {
  console.log('连接错误', err)
})
client.on('error', (err) => {
  console.log('通用错误', err)
})
client.on('disconnect', (reason) => {
  console.log('断开连接', reason)
})

• 临时关闭SSL校验、强制指定传输层测试，初始化时传入配置：

const client = io("wss://myserver.com", {
  transports: ['websocket'],
  rejectUnauthorized: false, // 仅测试用，生产环境不要开启
  // 若在Electron主进程运行，可额外添加如下配置强制使用Node端实现
  agent: new (require('https').Agent)({ rejectUnauthorized: false })
});

如果修改后能正常连接，说明是SSL证书或者传输层适配问题，接下来排查服务端证书链完整性即可。

• 抓包排查网络请求：用Wireshark、Fiddler等工具抓Electron进程的网络包，查看连接请求是否成功发出，服务端返回的状态码、响应内容是什么
• 验证进程级拦截规则：临时关闭系统防火墙、安全软件后重试，或手动在防火墙规则中添加Electron进程的出站放行规则
• 检查Electron网络配置：查看应用的CSP配置是否允许wss协议连接你的目标域名，webPreferences中的webSecurity、allowRunningInsecureContent等配置是否有变动
• 对比版本差异：回滚到9月30日之前可用的Electron版本、socket.io-client版本测试，确认是否是依赖版本变更导致的问题

内容的提问来源于stack exchange，提问作者Daniel van Eeden