Node前后端分Docker容器部署时Socket.io连接方案咨询

取消前端代理、后端配置CORS允许客户端直连Socket不是最优方案，更推荐保留现有前端代理架构，通过代理规则适配Socket.io的握手和传输要求，两种方案的优缺点和落地建议如下：

方案1：取消前端代理，后端配置CORS允许客户端直连Socket #

优点 #

• 实现逻辑简单，前端Socket实例直接指向后端对外暴露的服务地址即可，后端仅需配置socket.io的CORS规则放行前端域名，参考配置：

// 后端socket.io CORS配置
const { Server } = require("socket.io");
const io = new Server(httpServer, {
  cors: {
    origin: "你的前端实际域名",
    methods: ["GET", "POST"],
    credentials: true
  }
});

• 不会占用前端代理服务的WebSocket连接资源，高并发场景下代理层不会成为Socket连接的瓶颈

缺点 #

• 后端服务需要直接对公网暴露端口，增加攻击面，违背了原架构中后端隐藏、仅前端可访问的安全设计
• 后续如果调整后端服务地址、做多后端负载均衡，所有前端代码里的Socket连接地址都要同步修改，维护成本高
• 跨域场景下需要额外处理Cookie、身份凭证的传递逻辑，容易出现鉴权失败的问题

方案2：保留现有前端代理架构，新增Socket.io代理规则（推荐） #

不需要调整原有安全架构，仅修改前端代理的配置即可，适配Socket.io的握手和长连接传输要求即可正常建立通信。

优点 #

• 后端全程不需要对公网暴露，保持原有安全架构，所有流量入口统一走前端服务，方便后续做流量管控、限流、日志审计
• 前端代码不需要修改任何Socket连接地址，和本地开发、原同设备部署时代码完全一致，迁移成本极低
• 不需要处理跨域相关的适配问题，原有鉴权逻辑不需要调整

缺点 #

• 代理层需要承载所有Socket连接，高并发场景下需要对代理服务做扩容，避免连接数打满
• 代理配置需要额外适配Socket.io的传输特性，比如要开启WebSocket支持、设置较长的连接超时时间，避免主动断连

• 并发量在1万以下的场景，优先选方案2，仅调整代理配置即可，Express前端服务的代理参考配置（使用http-proxy-middleware）：

const { createProxyMiddleware } = require('http-proxy-middleware');

app.use('/socket.io', createProxyMiddleware({
  target: 'http://后端Docker容器的服务地址:端口',
  changeOrigin: true,
  ws: true, // 开启WebSocket代理支持
  timeout: 180000, // 设置3分钟超时，避免长连接被主动断开
}));

• 如果是十万级以上Socket连接的超大规模场景，再考虑方案1，同时要给后端Socket服务单独做WAF防护、增加严格的身份鉴权校验，避免非法连接。

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