NestJS Socket.IO适配器：allowFunction传false时握手响应缺失CORS头是bug还是配置问题

该问题属于配置与实现逻辑错位问题，并非NestJS或Socket.IO的框架Bug。

逻辑根因 #

• 你在main.ts中通过app.enableCors配置的CORS规则、以及cookieParser、csurf等中间件能力，全部绑定在NestJS底层HTTP服务的常规HTTP请求处理链路上。这套链路只会对匹配到HTTP路由的请求做统一的响应头注入、流程处理。
• Socket.IO的握手请求拥有独立处理链路，与上述全局HTTP中间件链路存在分层差异：
  • 鉴权通过时，握手请求会走完完整处理流程，触达全局HTTP中间件的CORS注入逻辑，因此响应正常携带CORS头；
  • 鉴权失败时，allowRequest钩子会直接在Socket.IO的请求拦截层生成错误响应并返回。这个环节的响应生成完全没有经过全局HTTP中间件的处理流程，因此不会触发CORS头注入逻辑，最终出现响应缺失CORS头的现象。

修复方案 #

不要依赖全局HTTP中间件为Socket.IO的所有握手响应补全CORS头，需要将CORS规则直接透传给Socket.IO服务实例，保证所有握手响应（包括鉴权失败的错误响应）都能由Socket.IO自身的处理逻辑统一注入CORS头：

1. 在自定义适配器的createIOServer方法中，给传入的Socket.IO配置项补充和全局HTTP层完全一致的CORS规则，示例代码如下：

   createIOServer(port: number, options?: SocketIO.ServerOptions): any {
     // 为Socket.IO实例单独配置统一CORS规则，覆盖全场景响应
     options = {
       ...options,
       cors: {
         origin: ['http://localhost:4200'],
         credentials: true
       }
     }
     options.allowRequest = async (request, allowFunction) => {
       // 原有鉴权逻辑保持不变
       const { authorized, errorMessage } = await this.check(parse(request?.headers?.cookie || '').jwt, [UserRole.ADMIN]);
       if (!authorized) {
         return allowFunction(errorMessage, false);
       }
       return allowFunction(null, true);
     };
     return super.createIOServer(port, options);
   }
   

2. 配置完成后，无论握手请求最终返回成功响应还是鉴权失败的错误响应，CORS头的注入逻辑都会在Socket.IO实例的统一处理层完成，不会再出现不同响应场景下CORS头缺失的不对称问题。

内容的提问来源于stack exchange，提问作者M. C. Cristian