AWS ElasticBeanstalk搭配CodePipeline部署Laravel仅首页可访问404问题排查

• 这是Laravel项目部署到AWS EBS时最常见的报错场景，本质是Web服务器路由重写规则缺失，请求根本没有进入Laravel的应用路由解析层。
• 具体逻辑：Laravel所有非静态资源的请求，必须通过Web服务器配置统一转发到项目入口文件public/index.php，再由Laravel路由系统匹配对应路径的业务处理逻辑。当前EBS默认的Web服务器配置仅能识别根路径下的静态入口文件（对应首页可正常加载的表现），遇到带业务路径的请求（如/user/profile、/api/list）时，会直接在磁盘上寻找对应路径的实体文件，找不到就直接返回404，完全不会触发Laravel的路由匹配流程。
• 少数场景是EBS的Web根目录指向错误，没有定位到Laravel的public子目录，刚好根目录下的静态文件能匹配首页请求，其余路径因目录层级不对返回404。

所有配置直接放到代码仓库中，随CodePipeline流水线自动部署，不需要手动登录EBS控制台修改。按EBS实际运行的Web服务器类型选择对应配置：

场景1：EBS使用Amazon Linux 2平台，Web服务器为Nginx #

• 在代码仓库根目录新建.platform/nginx/conf.d/laravel-rewrite.conf文件，写入如下配置：

# 指向Laravel的public入口目录
root /var/www/html/public;
index index.php index.html index.htm;

# 核心路由重写规则
location / {
    try_files $uri $uri/ /index.php?$query_string;
}

• 不需要修改平台默认的PHP解析块配置，只需补充上述路由重写逻辑即可。EBS部署时会自动读取该路径下的Nginx配置并加载生效。

场景2：EBS使用Apache服务器（含旧版Amazon Linux 1平台、AL2 Apache运行环境） #

• 首先检查.gitignore配置，确认Laravel项目根目录下的.htaccess文件没有被Git忽略，确保该文件随代码部署到EBS实例。该文件自带Laravel要求的路由重写规则，作用和上述Nginx的try_files逻辑完全一致。
• 在代码仓库根目录新建.ebextensions/apache-rewrite.config文件，配置Apache开启权限读取.htaccess：

commands:
  # 修改Apache全局配置，允许目录下的.htaccess文件生效
  set_allow_override:
    command: "sudo sed -i 's/AllowOverride None/AllowOverride All/g' /etc/httpd/conf/httpd.conf"
  # 重启Apache服务使配置生效
  restart_httpd:
    command: "sudo systemctl restart httpd"

• 触发一次CodePipeline流水线完成部署，等待EBS应用状态更新为健康。
• 依次访问常见业务路径（如/login、/dashboard），确认不再返回404，请求能正常走到Laravel的路由逻辑。
• 顺带检查storage、bootstrap/cache目录的读写权限，避免后续出现因权限不足导致的500错误。

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