Gatsby对接Drupal时Docker容器出现连接超时问题排查

这确实是个挺恼人的随机问题——主机上一切正常，Docker容器里却时不时触发连接超时，而且curl还能正常访问目标资源。结合你给出的配置和环境信息，咱们可以从Node进程在主机与Docker容器中的几个关键差异点来分析原因：

1. 网络栈隔离带来的请求行为差异 #

Docker容器的网络是独立命名空间，和主机的网络栈完全隔离。哪怕curl能成功请求，Node.js底层的HTTP请求库（gatsby-source-drupal依赖的node-fetch或类似工具）的连接池策略、超时设置和curl存在差异：

• Node的默认TCP连接超时可能更短，在容器网络转发有轻微延迟时，就容易触发ETIMEDOUT；
• 你设置了concurrentFileRequests: 120的高并发请求，容器的网络转发带宽/能力可能跟不上，导致部分连接无法及时建立；
• 容器网络的NAT转换可能会导致TCP连接的TIME_WAIT状态无法及时回收，积累到一定数量后，新的连接请求就会超时。

2. 容器的进程资源限制 #

虽然你提到主机和容器的Node内存使用相近，但Docker默认会给容器设置CPU、内存的软/硬限制：

• 如果容器的CPU配额不足，高并发请求时Node进程会被限流，导致请求处理延迟，进而触发连接超时；
• 容器的文件描述符限制（ulimit -n）通常比主机低，高并发下打开的套接字数量超过限制，就会出现无法建立新连接的情况，表现为随机的ETIMEDOUT。

3. DNS解析策略差异 #

主机和容器的DNS配置可能不同：

• 容器内的DNS解析服务（比如Docker内置的DNS）可能偶尔出现延迟，Node.js的DNS缓存策略和curl不同，可能不会自动重试，从而触发连接超时；
• 如果你用域名访问Drupal后端，容器内的DNS解析可能偶尔失败，而curl的重试机制更完善，所以没暴露问题。

4. Node.js运行环境的细微差异 #

即使Node版本都是v12，主机和容器的系统库、环境变量可能有差异：

• 容器内的Node可能依赖的系统SSL库和主机不同，导致TLS握手过程出现偶尔的延迟或失败；
• 容器的HOSTNAME等环境变量可能影响Node的网络请求行为，比如某些底层库会根据主机名调整连接策略。

排查建议 #

针对这些可能的差异，你可以尝试以下步骤定位问题：

• 降低并发请求量：把concurrentFileRequests从120降到60甚至30，测试是否还会出现随机超时。高并发很容易放大容器网络的瓶颈；
• 检查容器资源限制：用docker stats实时监控容器的CPU、内存占用，看是否有峰值超过容器的配额；用docker exec <your-container> ulimit -n对比主机的ulimit -n，如果容器的文件描述符太少，启动容器时添加--ulimit nofile=65535:65535参数调整；
• 开启Node网络调试：在容器中运行Gatsby时，设置环境变量NODE_DEBUG=http，这样能看到所有HTTP请求的细节，包括超时发生在哪个阶段（DNS解析、连接建立还是数据传输）；
• 添加请求重试/超时配置：虽然gatsby-source-drupal默认没暴露这些配置，但你可以通过自定义插件或者修改依赖的请求库，给HTTP请求添加更长的超时时间和自动重试机制，缓解网络波动带来的影响。

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