使用socket.io时Nginx代理WebSocket连接失败问题求助

核心问题定位 #

API代理正常但Socket.IO的polling请求超时，说明WebSocket升级或长轮询的代理配置、服务端/客户端参数存在问题，以下是针对性排查与修复步骤：

1. 完善Nginx的WebSocket代理超时配置 #

Nginx默认超时时间较短，不足以支撑Socket.IO的长轮询机制，需在location ~ ^/(api|socket\.io)/块中补充超时配置，同时优化Connection头的处理逻辑：

location ~ ^/(api|socket\.io)/ {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    # 避免硬编码Connection头，保留客户端原始值
    proxy_set_header Connection $http_upgrade;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    # 延长超时时间适配长轮询
    proxy_connect_timeout 7d;
    proxy_send_timeout 7d;
    proxy_read_timeout 7d;
    # 跳过自签名证书验证（Nginx到应用容器的HTTPS连接）
    proxy_ssl_verify off;
    proxy_pass https://172.17.0.1:8443;
}

2. 修正服务端Socket.IO的CORS配置 #

服务端CORS配置中存在格式错误的地址（https://x.x.x.x:x:443多了无效的:x），同时统一配置并明确传输方式：

const wss = new WebSocketServer(server, {
  cors: {
    origin: ['https://x.x.x.x'],
    credentials: true
  },
  // 明确支持的传输方式，避免自动选择异常
  transports: ['polling', 'websocket']
});

// Express CORS配置与Socket.IO保持一致即可
app.use(
  cors({
    credentials: true,
    origin: ['https://x.x.x.x'],
  })
);

3. 排查容器网络连通性 #

• 确认应用容器的8443端口已正确暴露并映射到宿主机，且服务确实在该端口监听
• 在Nginx容器内执行telnet 172.17.0.1 8443，验证网络是否可达
• 检查应用容器的防火墙/安全组，确保未阻止8443端口的入站请求

4. 客户端连接参数优化 #

明确指定传输方式，避免自动选择逻辑引发的异常：

const socket = connect('https://x.x.x.x', { 
  rejectUnauthorized: false,
  transports: ['polling', 'websocket']
});

验证步骤 #

修改配置后重启Nginx与应用容器，依次验证：

• 浏览器控制台中socket.io/?EIO=4&transport=polling请求返回200状态
• 网络请求中出现Upgrade: websocket的成功升级记录
• 应用端日志输出新的Socket连接记录

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