AWS Beanstalk扩展Nginx配置后去除index.php的URL重写失效

现有Nginx配置的核心逻辑疏漏 #

• 错误嵌套完整server块：你编写的配置将整套server{}块直接写入了proxy.conf文件，既没有为该块声明listen 80/listen 443监听规则，也没有绑定对应域名，本质是在Nginx的http上下文下新增了一个悬空、无流量入口的空配置块，所有写在块内的重定向、try_files规则永远不会被真实请求触发。
• 规则重复且未绑定实际处理流程：你在server块内外重复写了多套index.php去除规则，但因为核心处理流量的是EBS默认生成的业务server块，你写的try_files $uri $uri/ /index.php?$query_string逻辑从未被加载到实际处理请求的块中，导致Nginx走默认的实体文件查找逻辑，最终出现日志中“/var/www/html/public/api不存在”的404错误。
• 规则位置错误：Nginx的配置上下文是严格分层的，location、try_files这类指令只能写在server块内部才能生效，你把独立server块放在conf.d下的写法，会导致所有核心规则和真实处理流量的server块完全隔离。

对AWS Elastic Beanstalk Nginx扩展机制的常见误解 #

• 很多开发者以为.platform/nginx/conf.d/下的配置可以随意写完整server块，实际该目录下的所有.conf文件，会被Nginx主配置通过include指令直接拉取到http全局上下文层级，不会自动嵌入到默认的业务server块内部。
• 你之前判断“配置已加载”的验证方式存在偏差：只要conf文件语法正确，哪怕是一个没有任何监听指令的空server块，Nginx加载时也不会报错；你能在服务器路径上找到该文件，不代表它的规则已经作用到真实流量上。通过nginx -T指令校验全量配置时，才能看到哪些规则已经被合并到实际处理80/443流量的server块内部。

调整后可直接落地的配置 #

按照EBS的Nginx加载规则，去掉冗余的自定义server块，只保留需要生效的规则，将文件内容调整为如下即可：

# 全局301重定向：匹配所有带index.php的请求，跳转到无index.php的同路径
if ($request_uri ~* "^(.*/)index\.php/*(.*)$") {
    return 301 $1$2;
}

# 合并到默认server块的Laravel路由规则，保证非实体文件请求转发到index.php处理
location / {
    root /var/www/html/public;
    try_files $uri $uri/ /index.php?$query_string;
}

# 原有辅助规则保留即可
if (!-d $request_filename) {
    rewrite ^/(.+)/$ /$1 permanent;
}

if ($request_uri ~* "\/\/") {
    rewrite ^/(.*) /$1 permanent;
}

效果验证方式 #

• 部署完成后登录EC2实例执行nginx -T，确认重定向规则、location块已经出现在实际监听80/443端口的server块配置段内，没有孤立在http全局层级。
• 访问https://example.com/index.php/任意端点路径，会收到301跳转响应，直接重定向为https://example.com/任意端点路径，路径段、查询字符串都会完整保留。
• 直接访问无index.php的URL时，Nginx会通过try_files逻辑将请求转发给Laravel的index.php处理，不会再出现查找实体文件的404错误。

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