GitHub Actions中Docker-Compose运行Jest测试遇连接错误求助

我在Node.js API项目中使用Jest执行测试，GitHub部署时会通过Docker-Compose自动触发npm run test。

请求对象的创建代码如下：

baseURL: `http://${host}:3000`,
timeout: 10000,
headers: {
  'Access-Control-Allow-Origin': '*',
  'Content-Type': 'application/json',
  'X-API-KEY': '****',
},
})

用户请求统一放在单独文件中，比如注册请求：

const { request } = require('./requests')

async function signUp(data, config) {
  return await request.post('/users/sign-up', data, config)
}

Jest测试用例示例：

test('Should sign-up a new user', async () => {
  const data = {...}
  const config = { headers: {... } }
  const response = await signUp(data, config)
  expect(response.status).toEqual(200)
})

本地测试正常通过，之前GitHub Actions也能正常运行，但近一周突然失效，未修改任何测试相关代码。GitHub上测试返回socket hang up和connect ECONNREFUSED 172.18.0.7:3000错误。请问可能是什么原因导致的？

• API服务未就绪就启动测试：Docker-Compose启动服务时，若依赖的数据库等服务启动慢，或API自身初始化耗时变长，会导致测试开始时API还没完全启动。可以在测试脚本前加等待逻辑，比如用wait-for-it.sh脚本检测3000端口是否开放，再执行测试。
• 容器网络配置异常：GitHub Actions的Docker环境可能有更新，导致容器间网络通信出错。检查docker-compose.yml的网络配置，确认API容器的端口映射正确，测试代码中的host变量是否和容器名称/主机名匹配（Docker内部可直接用容器名访问服务）。
• 环境变量host配置错误：测试环境的host变量可能指向了错误的容器IP（172.18.0.7未必是当前API容器的IP）。测试前打印host的值，或者直接用容器名称替代IP作为请求地址。
• 资源限制导致服务崩溃：GitHub Actions虚拟机资源有限，若API启动时占用过多内存/CPU，可能被系统强制终止。查看API容器的日志，确认是否有OOM（内存不足）或崩溃报错。
• 依赖或镜像自动更新引发兼容问题：虽然测试代码没改，但项目依赖的npm包（如请求库、Jest）或Docker基础镜像可能自动更新了，导致兼容性问题。锁定依赖版本（用package-lock.json），并固定Docker镜像的具体标签（不要用latest）。
• 网络策略限制：GitHub Actions环境的网络策略可能有变更，阻止了测试容器访问API的3000端口。可在测试前添加容器间连通性测试，比如在测试容器内执行curl http://${host}:3000验证。

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