更换域名后Socket.io抛出connect_error server error的问题排查

• 检查反向代理/CDN的WebSocket支持配置
  两个域名部署环境的差异大概率出现在中间代理层：
  • 确认Nginx、Apache等反向代理是否配置了WebSocket必要的请求头转发：Upgrade、Connection，同时调整代理超时时间避免长连接被提前断开
  • 若新域名接入了CDN，确认CDN控制台已开启WebSocket支持，大部分CDN服务默认会禁用WebSocket流量
• 测试传输协议适配情况
  可在客户端初始化时强制指定传输协议跳过polling预校验阶段，测试是否是长连接升级流程被拦截：

  const socket = io('你的新域名', { transports: ['websocket'] })
  

  如果强制用WebSocket可正常连接，说明中间代理层对HTTP长轮询(polling)的请求做了缓冲或拦截。
• 校验两端依赖版本一致性
  同分支代码部署时若未同步锁文件（package-lock.json/yarn.lock），可能出现Socket.IO依赖版本不一致的问题：
  • 服务端执行npm list socket.io查看版本
  • 客户端执行npm list socket.io-client查看版本
    Socket.IO要求服务端与客户端的大版本必须完全匹配，例如v4版本服务端无法兼容v2版本客户端。
• 开启全量debug日志
  启动服务端时添加DEBUG环境变量开启Socket.IO全链路日志，可打印握手、协议升级、心跳全流程的详细错误：

  DEBUG=socket.io* node 你的服务启动文件.js
  

• 检查网络安全策略限制
  确认新域名对应的服务器安全组、WAF、防火墙规则是否拦截了WebSocket流量，是否限制了长连接的最大保持时长。可调整Socket.IO心跳配置降低被中间网络切断的概率：

  const io = new Server(httpServer, {
    pingInterval: 10000, // 每10秒发一次心跳
    pingTimeout: 20000 // 20秒没收到心跳就断开
  })
  

• 校验路径转发配置
  确认反向代理是否将Socket.IO默认的/socket.io路径完整转发到目标服务，没有被重写规则修改路径导致服务端无法收到握手请求。

内容的提问来源于stack exchange，提问作者Terry Windwalker