如何让两个WebSocket客户端连接AWS ECS Fargate集群同一容器实例

先直接回答你提到的两个核心疑问：

• 仅靠自定义Host请求头无法实现定向路由到指定Fargate容器的需求，ALB默认不支持仅凭Host头将请求打给特定后端任务，且为每个任务维护独立域名的成本极高，完全不推荐
• 正确配置ALB规则后，不会产生额外的跨实例转发开销，ALB与Fargate任务之间走AWS内网直连，WebSocket长连接可稳定支持数小时会话。

适配你场景的最优落地方案（零额外转发开销） #

你已经可以提前给两个客户端同步目标实例信息，不需要引入额外的服务网格、代理组件，按以下步骤配置即可：

• ALB基础长连接配置
  首先开启ALB对WebSocket的原生支持，将对应监听器的空闲超时调整到支持的最大值（当前最高为4000秒）；同时在WebSocket服务端、客户端两侧配置间隔小于空闲超时的心跳机制（比如每5分钟互发ping/pong帧），避免空闲连接被ALB强制断开。
• 实例唯一路由标识配置
  每个Fargate任务启动时，通过ECS元数据接口获取自身唯一任务ID，生成专属的WebSocket连接路径，格式类似/ws/conn/{task-id}，或携带专属查询参数?target={task-id}。任务启动完成向ALB目标组注册自身ENI地址时，同步将这个路由标识上报给你的业务调度服务。
• ALB细粒度转发规则配置
  在ALB对应监听器上配置路径/查询参数匹配规则，将携带特定任务标识的WebSocket握手请求，直接转发到对应ID的Fargate任务。当需要让用户A、用户B配对时，调度服务直接给两个客户端下发同一个任务标识对应的连接地址即可。
  这个方案下ALB完成握手后会直接和目标容器建立长连接，没有中间跳转，转发延迟在毫秒级，数据帧转发开销几乎可以忽略，完全满足高频率、大流量的一对一数据交换需求。

备选方案（低配置成本，存在一定局限性） #

如果你不想配置细粒度的ALB转发规则，可以开启ALB目标组的粘性会话（Sticky Session）功能：

• 用户A首次连接时，ALB会生成专属的粘性cookie，将请求路由到某个后端实例
• 业务服务拿到这个cookie后同步给用户B，用户B发起WebSocket握手时携带该cookie，ALB就会将请求路由到和用户A相同的实例
• 这个方案的缺点是粘性cookie存在固定过期时间，长连接场景下如果发生重连可能被调度到其他实例，且无法主动指定目标实例，配对延迟更高，仅适合快速验证场景使用。

注意避坑 #

• 不要尝试绕过ALB直连Fargate任务：Fargate任务的ENI IP默认动态变化，直连需要你自己维护IP映射、公网暴露、安全组规则，运维成本远高于ALB方案，且实际性能提升极小
• 给WebSocket服务配置独立的ALB健康检查规则，适当调大健康检查间隔、失败阈值，避免偶发的健康检查失败导致任务被ALB强制注销，断开正在运行的长连接
• 不要在ALB和Fargate任务之间再加其他反向代理层，避免引入额外的转发开销和连接稳定性问题

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