Nginx Location与try_files行为不符文档的技术疑问

首先纠正你的核心认知误区：try_files的最后一个参数是否触发内部重定向，取决于它是「文件路径」还是「URI」；而在使用alias的location中，Nginx会对绝对URI参数做特殊处理，结合当前location前缀生成新的请求路径，而非直接触发全局重定向。

你的配置实际运行逻辑解析 #

当请求http://test.com/pma/时，真实处理流程如下：

1. 请求匹配location /pma（前缀匹配优先级高于全局/规则）
2. try_files $uri检查/var/www/html/（由alias映射/pma/得到），若该目录不存在或无访问权限，匹配失败
3. try_files $uri/同理，匹配失败
4. 回退到最后一个参数/index.php——这里的关键是：在alias配置的location中，Nginx不会将/index.php视为全局URI，而是自动结合当前location前缀，生成/pma/index.php的请求路径，对应文件路径为/var/www/html/index.php
5. 此时请求处于location /pma的上下文内，嵌套的location ~ \.php$优先级高于全局同规则location，因此直接匹配该嵌套规则
6. 最终通过fastcgi_pass phpmyadmin:9000转发到phpMyAdmin容器，完成正常请求处理

为什么你的预期流程错误？ #

你误以为/index.php会触发全局内部重定向，但实际不符合Nginx的规则：

• 只有在root配置的普通location中，try_files的绝对URI参数才会触发全局重定向；在alias location中，Nginx会自动将绝对URI与当前location前缀拼接，生成属于当前上下文的新请求路径
• Nginx处理请求时，会优先匹配当前location上下文内的嵌套规则，而非直接重新走全局location匹配流程

验证与补充说明 #

如果想强制触发全局重定向，可修改location /pma的try_files为：

try_files $uri $uri/ @global_fallback;

并添加全局命名location：

location @global_fallback {
    rewrite ^ /index.php last;
}

此时请求会跳转到全局的/index.php，匹配底部的PHP规则转发到WordPress容器，导致phpMyAdmin无法访问——这才是你最初预期的「失效」情况，但你的原配置因alias的特殊处理，并未走到这一步。

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