AWS ALB多实例部署时Socket.IO轮询传输报400错误排查求助

这个400 TransportError的核心触发逻辑是：Socket.IO默认优先使用polling（长轮询）模式完成握手，第一次GET请求打到后端实例后，实例会生成唯一的sid会话标识返回给客户端，后续所有polling阶段的请求（POST上行、GET下行）都必须携带这个sid路由到生成该sid的同一台后端实例；如果请求被转发到其他实例，该实例本地没有对应sid的会话上下文，就会直接返回400错误。
你之前开启粘性会话后问题未解决，本质是粘性策略没有在Socket.IO polling握手的全链路生效，不是粘性会话方案本身无效。直连单实例、纯WebSocket模式下连接正常，已经可以排除Redis适配器故障、服务端基础功能故障，问题完全出在ALB转发逻辑和链路配置上。

• 第一步：验证粘性会话是否真实生效。打开浏览器开发者工具的网络面板，过滤socket.io路径的请求，依次查看前3次polling交互：第一次GET握手请求的响应头是否返回了粘性Cookie，后续POST、GET请求的请求头是否携带了该Cookie。如果后续请求未携带Cookie，说明Cookie的域、路径、SameSite、Secure属性配置不符合浏览器安全策略被拦截；如果请求携带了Cookie但依然被转发到不同后端，说明ALB目标组的粘性规则配置错误。
• 第二步：验证单实例polling可用性。通过Host绑定将访问域名指向单台后端实例IP，客户端配置transports: ['polling']发起连接，确认单实例下polling模式可以正常连通，排除单实例本身的polling配置故障。
• 第三步：检查ALB转发规则完整性。确认/socket.io/路径下的GET、POST、OPTIONS三类请求全部被转发到同一个后端目标组，没有被其他路径规则分流；临时关闭该路径下的WAF拦截规则、请求/响应头自动改写规则，避免sid参数、Cookie被篡改或丢弃。
• 第四步：检查跨域配置。如果客户端和服务端不同源，确认服务端CORS配置开启了凭证允许，客户端请求开启了携带凭证配置，否则浏览器会拦截粘性Cookie的写入和发送。

根据你的业务场景二选一即可：

• 方案一（推荐，零额外配置成本）：客户端直接指定仅使用WebSocket传输，配置项为transports: ['websocket']。WebSocket协议在第一次HTTP升级握手完成后，会和后端建立固定的长TCP连接，后续所有通信都复用该连接，完全不依赖多请求轮询，也不需要粘性会话支持，性能比polling模式高30%以上。只要ALB默认开启WebSocket支持（ALB默认开启，仅需将空闲超时调整为60s以上即可），就能稳定运行，你当前测试该模式正常，生产环境可直接使用。

说明：仅当你需要兼容IE9及以下不支持WebSocket的极老旧终端时，才需要保留polling模式，当前99%以上的用户终端都原生支持WebSocket，无需额外做polling兼容。

• 方案二（需保留polling兼容的场景）：按以下顺序修正配置
  1. ALB目标组配置：重新开启粘性会话，选择自定义Cookie模式，Cookie名设置为socket.io，Cookie路径设置为/，同站部署场景下SameSite属性设为Lax，跨域部署场景下SameSite设为None同时开启Secure属性，Cookie有效期设置为86400秒（1天）。
  2. ALB监听器配置：为/socket.io/路径单独配置转发规则，覆盖GET、POST、OPTIONS三类请求方法，将ALB空闲超时调整为120秒，避免长轮询连接被提前掐断。
  3. Socket.IO服务端配置：CORS配置添加credentials: true参数，将pingTimeout设为60000、pingInterval设为25000，和ALB超时时间对齐；确认多线程架构下，单实例内的线程间会话也通过Redis适配器同步，不要将会话存在线程本地内存中。
  4. Socket.IO客户端配置：添加withCredentials: true参数，保持默认路径/socket.io/和服务端一致，不要自定义修改路径参数。

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