WebSocket连接失败求助：Netlify与AWS Elastic Beanstalk部署后无法通信

核心问题分析 #

本地环境正常但HTTPS线上环境WebSocket连接失败，大概率是跨域配置错误、AWS Elastic Beanstalk负载均衡未适配WebSocket或传输策略兼容性问题导致。

1. 修正客户端CORS配置错误 #

你当前客户端代码里的cors.origin配置完全错误：

// 错误配置：将服务端URL设为允许的请求源
cors: {
  origin: `${process.env.REACT_APP_SERVER_URL}`,
}

CORS的origin应设置为客户端的域名（即Netlify部署后的站点地址），目的是允许客户端向服务端发起跨域请求。修正后的代码：

export const socket = io.connect(`${process.env.REACT_APP_SERVER_URL}`, {
  path: "/socket.io",
  transports: ["websocket", "polling"], // 增加降级策略，提升兼容性
  withCredentials: true,
  cors: {
    origin: `${process.env.REACT_APP_CLIENT_URL}`, // 替换为Netlify站点域名
    credentials: true // 配合withCredentials启用凭证传递
  },
});

2. 配置AWS Elastic Beanstalk负载均衡支持WebSocket #

AWS ALB（应用负载均衡）默认需要手动配置才能适配WebSocket长连接：

• 登录AWS控制台，进入目标Elastic Beanstalk环境，找到关联的ALB目标组
• 修改目标组的健康检查路径为/socket.io/?EIO=4&transport=polling（适配Socket.IO的健康检查规则）
• 调整目标组的连接超时时间至60秒以上（WebSocket是长连接，默认超时会导致连接被强制中断）
• 确保ALB的HTTPS监听器已正确转发到服务端的HTTP端口（Elastic Beanstalk应用通常监听80端口，ALB负责SSL终止）

3. 验证SSL证书与域名映射 #

• 直接访问https://api.dino-run.site/socket.io/，通过浏览器证书信息确认服务端SSL证书有效、域名匹配
• 检查域名解析记录，确认api.dino-run.site已正确指向ALB的端点，无跳转或解析错误

4. 调整Socket.IO传输策略 #

强制仅使用websocket传输在部分CDN或负载均衡环境下可能被拦截，建议添加降级策略：

transports: ["websocket", "polling"], // 优先尝试WebSocket，失败后自动切换轮询

服务端默认已支持两种传输方式，无需额外配置。

5. 检查服务端CORS与环境变量 #

• 确认服务端process.env.CLIENT_URL环境变量是正确的Netlify站点域名（需带https://前缀）
• 服务端Socket.IO配置补充credentials: true，配合客户端的withCredentials：

const io = socketIO(server, {
  path: "/socket.io",
  cors: {
    origin: `${process.env.CLIENT_URL}`,
    credentials: true // 启用跨域凭证支持
  },
});

6. 查看日志定位问题 #

• 在Elastic Beanstalk控制台下载应用日志，检查是否有CORS请求被拒绝、Socket.IO初始化失败的错误信息
• 客户端浏览器控制台打开Network标签，查看WebSocket连接的请求头（确认Origin是否正确）、服务端响应码（如403、502等）

内容的提问来源于stack exchange，提问作者henry.ki