CentOS7 LiteSpeed环境下Socket.IO服务已监听但客户端无法连接的问题求助

修正代码层显性错误 #

• 你贴出的示例app.js存在变量引用错误：前面初始化的HTTP服务实例命名为http，但启动服务时写了未定义的server.listen()，会导致服务无法正常绑定端口。正确写法是将启动行调整为http.listen(port, () => console.log(Listening on port ${port}))，移除不存在的server变量引用。
• 客户端初始化Socket.IO时禁止使用空参数io()：空参数在生产环境会默认指向当前页面的同源地址，在LiteSpeed反代场景下无法路由到本地Node服务。需先显式指定地址、暂时关闭WebSocket升级选项排除干扰，优先测通最基础的轮询连通性：

  const socket = io('http://你的站点域名', {
    transports: ['polling']
  })
  

• 不需要在后端Node进程里替换成HTTPS模块，HTTPS的证书托管、流量解密全部由LiteSpeed在前置层完成即可，后端和LiteSpeed之间走本地明文HTTP通信，不会存在安全问题。

定位核心环境根因 #

你遇到的是Cyberpanel/LiteSpeed场景下的共性配置坑：LiteSpeed默认的反向代理规则会拦截Socket.IO的专属请求，哪怕防火墙放行了5000端口，请求也会被LiteSpeed的WAF、默认站点规则挡在外面，对应表现完全和你的情况匹配：

• 你观察到的Socket.IO GET请求返回200，实际是LiteSpeed自己返回的默认空响应，根本没有转发到后端Node进程
• Node服务虽然能正常打印启动日志，但从来没有收到过外部发来的Socket.IO请求，自然不会触发connection事件回调
• 你之前替换HTTP/HTTPS模块、调整服务启动方式、尝试各类端点配置的操作全部无效，就是因为请求根本没到达代码运行层

完成LiteSpeed层的透传配置 #

• 先在服务器本地验证Node服务本身是否正常：SSH登录VPS后执行本地curl测试，确认Node进程的响应符合预期：

  curl "http://127.0.0.1:5000/socket.io/?EIO=4&transport=polling"
  

  如果返回包含sid字段的Socket.IO标准握手响应，说明Node服务本身无故障，问题100%出在LiteSpeed代理层。
• 配置站点根目录下的.htaccess文件，新增Socket.IO专属的代理透传规则，让LiteSpeed把所有Socket.IO路径的请求正确转发到本地Node端口：

  RewriteEngine On
  # 处理WebSocket升级请求
  RewriteCond %{REQUEST_URI} ^/socket.io
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule ^(.*)$ ws://127.0.0.1:5000/$1 [P,L]
  # 处理普通轮询请求
  RewriteCond %{REQUEST_URI} ^/socket.io
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule ^(.*)$ http://127.0.0.1:5000/$1 [P,L]
  

• 进入Cyberpanel对应站点的LiteSpeed配置页，开启「Websockets」总开关，确保LiteSpeed不会自动剥离请求头里的Upgrade、Connection字段。
• 配置完成后，客户端不需要直连5000端口，直接请求当前站点的同源地址即可，既可以避免公网端口暴露的安全风险，也能走通完整的Socket.IO请求链路。

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