部署Laravel到Elastic Beanstalk时数据库连接被拒绝问题求助

根据你描述的情况——手动执行php artisan migrate --force完全正常，但部署流程里执行就报连接拒绝，核心原因大概率是部署阶段的执行上下文和你SSH登录后的运行环境不一致，以下是几个针对性的排查和解决方向：

1. 检查migrate命令的执行时机（最常见的坑） #

Elastic Beanstalk的commands和container_commands执行时机天差地别：

• commands是在应用代码解压前、环境变量注入前执行的，此时Laravel根本拿不到正确的数据库连接信息
• container_commands是在应用代码解压完成、EB已经把所有环境变量写入Laravel的.env文件后才执行的

如果你的.ebextensions配置里是用commands来跑migrate，赶紧改成container_commands，示例配置：

container_commands:
  01_run_migrations:
    command: "php artisan migrate --force"
    leader_only: true # 只让集群里的领头实例执行，避免多实例重复跑migrate

2. 验证部署时的环境变量是否正确加载 #

有时候EB的环境变量注入可能存在延迟，你可以在migrate前加一步打印环境变量的操作，确认DB连接信息是否正确：

container_commands:
  00_check_db_env:
    command: "echo DB_HOST: $DB_HOST | DB_NAME: $DB_DATABASE | DB_USER: $DB_USERNAME"
  01_run_migrations:
    command: "php artisan migrate --force"
    leader_only: true

部署完成后查看日志里的输出，对比你SSH登录后看到的环境变量，确认两者一致。

3. 检查新部署实例的安全组配置 #

如果EB用了滚动部署或蓝绿部署策略，新创建的EC2实例可能没被添加到RDS的安全组允许列表里：

• 登录AWS控制台，进入你的RDS实例详情页，查看关联的安全组
• 确认EB实例所在的安全组（或新实例的公网IP）在RDS的入站规则里，允许3306（MySQL）或5432（PostgreSQL）端口的访问

注意：老实例能正常连接不代表新实例也可以——新实例可能分配了全新的IP，或者EB自动扩展组的安全组规则被意外修改了。

4. 增加Laravel配置缓存清理步骤 #

有时候部署时Laravel的配置缓存会保留旧的连接信息，哪怕环境变量已经更新，你可以在migrate前先清理缓存：

container_commands:
  01_clear_config_cache:
    command: "php artisan config:clear"
  02_run_migrations:
    command: "php artisan migrate --force"
    leader_only: true

5. 检查RDS的连接日志 #

登录RDS控制台，查看数据库的错误日志，搜索Connection refused相关记录，确认拒绝连接的来源IP和时间点是否和部署时间匹配——这能帮你快速定位是实例IP未被允许，还是数据库层面的其他问题。

内容的提问来源于stack exchange，提问作者Chuck Le Butt