为何连接AWS ALB时出现connect ETIMEDOUT错误？

问题场景 #

我们有一个React+Gatsby的静态站点，构建时会并行发起约200个请求到AWS ALB代理的ECS Fargate API，用响应填充GraphQL数据层。大多数时候构建正常，但偶尔会触发以下超时错误：

connect ETIMEDOUT <IP>:443

  Error:connect ETIMEDOUT <IP>:443
  
  - node:net:1278 TCPConnectWrap.afterConnect [as oncomplete]
    node:net:1278:16
  

not finished source and transform nodes - 529.009s

此时AWS ALB的访问日志中没有对应请求记录（符合TCP连接未建立的预期），且ALB已开启自动扩缩容，仍偶发该问题。

排查与解决思路 #

1. 降低Gatsby的并发请求数 #

短时间200个并发请求可能瞬间打满ALB的TCP连接队列，哪怕ALB支持扩缩容，突发流量也可能直接被丢弃。

• 在自定义数据源插件（比如gatsby-source-custom-api）中设置并发上限，建议先调到75-100（根据测试调整）：

  module.exports = {
    plugins: [
      {
        resolve: 'gatsby-source-custom-api',
        options: {
          url: '你的API地址',
          concurrency: 75, // 控制并发请求数量
        },
      },
    ],
  };
  

• 或通过环境变量限制Node.js的HTTP并发数：

  export NODE_MAX_HTTP_CONCURRENCY=75 && gatsby build
  

2. 检查ALB的连接配置 #

ALB本身有TCP连接队列和超时限制，这些参数可能成为瓶颈：

• 查看CloudWatch中ALB的ConnectionErrorCount、RequestCount指标，确认是否存在连接队列溢出的情况。
• 在AWS控制台将ALB的空闲连接超时从默认60秒调整到120秒，避免构建请求未完成就被断开。
• 检查ALB的安全组和网络ACL（NACL）规则，确认没有临时的流量拦截（比如AWS基础防护误判突发流量为异常）。

3. 排查后端Fargate的资源瓶颈 #

ALB能扩容，但后端ECS Fargate容器资源不足也会导致无法及时响应连接请求：

• 查看Fargate任务的CPU、内存使用率指标，若经常跑满，直接提升任务的CPU/内存配置。
• 检查后端API的连接池配置（比如数据库连接数、HTTP服务最大连接数），确保能承接并发请求。
• 给Fargate配置基于请求数的自动扩缩容策略，比单纯依赖CPU/内存更能快速响应突发流量。

4. 优化Node.js的TCP连接参数 #

Node.js默认的TCP参数可能不适应高并发场景：

• 构建时添加Node.js参数调整最大socket数：

  node --max-sockets=100 ./node_modules/gatsby/bin/gatsby.js build
  

• 在API请求逻辑中使用Agent复用TCP连接，减少握手开销：

  const https = require('https');
  const keepAliveAgent = new https.Agent({ keepAlive: true, maxSockets: 75 });
  // 用fetch请求时带上该agent
  fetch('你的API地址', { agent: keepAliveAgent });
  

5. 检查构建环境的网络限制 #

如果使用CI/CD服务（如GitHub Actions、GitLab CI）构建，运行环境的出口带宽或连接数限制也可能导致超时：

• 查看构建机器的网络监控，确认是否存在出口带宽饱和的情况。
• 切换到更高配置的CI运行环境，或把请求拆分成多个批次，避免一次性发起200个请求。

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