通过GitLabCI部署Strapi至AWS Fargate无法连接Aurora MySQL的求助

getaddrinfo ENOTFOUND 属于 DNS域名解析层故障，和Aurora数据库本身的运行状态、安全组端口放行规则无直接关联——本质是Fargate上运行的Strapi容器，无法获取配置的数据库主机域名对应的IP地址，流程在DNS解析环节就已中断，根本进入不了网络连通性校验阶段。

分配置模块排查指引 #

1. 优先校验数据库主机地址的全链路注入逻辑 #

• 排查Secret Manager存储的Aurora端点值：检查复制录入的集群主机地址是否附带了多余的空格、换行符或隐藏字符。这类脏值会被直接同步注入Fargate任务，容器携带无效字符去做DNS解析时，必然触发ENOTFOUND报错。
• 核对Fargate任务定义的Secret映射规则：确认任务定义中引用的Secret键值路径没有错配——比如原本要获取DB_HOST的值，错误引用了存储S3桶名、其他环境数据库地址的Secret键，容器会拿到完全不相关的域名作为数据库连接目标，自然无法解析成功。
• 排查GitLabCI部署流程的值覆盖问题：避免在部署阶段通过命令行参数硬编码覆盖Secret注入的环境变量，否则Strapi实际运行时拿到的数据库地址，会被替换成CICD流程里残留的旧测试环境域名，完全和你当前配置的Aurora地址无关。

2. Strapi核心配置文件校验 #

• 检查database.js的生产环境配置：确认数据库host字段直接读取运行时环境变量，没有在代码里硬编码本地、旧测试环境的数据库地址。正确的生产环境配置片段参考：

module.exports = ({ env }) => ({
  connection: {
    client: 'mysql2',
    connection: {
      host: env('DATABASE_HOST'),
      port: env.int('DATABASE_PORT', 3306),
      database: env('DATABASE_NAME'),
      user: env('DATABASE_USERNAME'),
      password: env('DATABASE_PASSWORD'),
    },
  },
});

• server.js配置仅需确认Strapi监听地址绑定为0.0.0.0即可，这部分不会影响数据库DNS解析逻辑，仅和任务健康检查的通过性相关。

3. Dockerfile层面的常见坑 #

• 不要在Dockerfile中通过ENV指令硬编码旧的数据库主机地址。这类构建时写入的默认值，只有当Fargate运行时没有注入对应环境变量时才会被使用，如果你的任务定义没有正确配置Secret注入逻辑，容器就会直接调用这个硬编码的旧地址触发解析失败。
• 不要在容器启动的entrypoint脚本中重复导出数据库相关环境变量，这类脚本写入的导出值会覆盖Fargate运行时注入的正确配置，导致连接地址错位。

4. Fargate网络层配置校验 #

• 确认Fargate任务关联的VPC，已开启DNS解析、DNS主机名两个核心属性。如果VPC未开启DNS解析，容器完全无法将AWS内网的Aurora端点解析为IP地址，无论域名配置是否正确，都会触发ENOTFOUND报错。
• 校验Fargate所在子网的DNS路由配置：如果任务部署在私有子网，需确保子网路由能正常转发DNS请求到VPC对应的AWS内网DNS服务；如果自定义了无效的外部DNS服务器，内网的Aurora域名会因为无法被外部DNS识别，直接解析失败。
• 不要在生产配置中混用Aurora公网端点做连接目标：如果Fargate任务部署在无公网出口的私有子网，即使DNS解析公网端点成功，也会因为网络路径不通连接失败，而如果DNS请求本身无法出网，就会直接触发ENOTFOUND报错。

5. GitLabCI部署流程排查 #

• 确认CICD流程实际部署的Fargate任务定义版本，是包含最新Secret映射配置的版本。很多场景下修改了任务定义的Secret引用规则后，CICD流程仍在引用旧版本的任务定义ARN，导致新配置完全不生效，容器仍在运行没有正确DB_HOST注入的旧版本任务。
• 校验GitLabCI使用的IAM角色权限：确保角色具备从Secret Manager读取数据库连接参数的权限。如果权限不足，Fargate拉取Secret失败时不会直接抛出权限错误，反而会将空值、占位符作为环境变量注入容器，Strapi拿无效值做域名解析时就会触发ENOTFOUND。

快速调试技巧：可以临时在Fargate任务定义中添加调试启动命令，容器启动后先执行nslookup $DATABASE_HOST将解析结果打印到CloudWatch日志，就能直接看到容器实际获取到的数据库主机值、对应的解析结果，避免反复调整配置迭代排查。

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