Nginx命名location中try_files的上下文处理是否异于普通location？

这个行为是正常的，完全符合Nginx的内部执行逻辑，下面结合你的配置场景详细拆解：

场景一：未添加 =404 时的执行流程 #

你的初始配置中，当请求一个两个目录都不存在的文件时，执行路径如下：

1. 请求匹配location /，try_files $uri $uri/ @verify 检查目标文件和对应目录都不存在，触发跳转到命名location @verify
2. 在@verify上下文里，try_files $uri $uri/ /index.html 依次执行检查：
   • $uri 和 $uri/ 均不存在（两个目录都无对应资源）
   • 最后一个参数是路径/index.html，此时Nginx会发起内部重定向，将/index.html作为新的请求URI重新处理
   • 新的/index.html请求会匹配到location /，使用该上下文的root /mypath/p1/，返回已存在的/mypath/p1/index.html

场景二：添加 =404 后的执行流程 #

修改后的try_files $uri $uri/ /index.html =404，执行逻辑发生关键变化：

1. 前面的$uri、$uri/、/index.html均匹配不到资源时，最后一个参数是状态码=404
2. 此时Nginx会直接在当前@verify上下文返回404状态码，不会发起内部重定向，因此不会回到location /的上下文

对官方文档的补充理解 #

官方文档中“处理在当前上下文中执行”的描述，针对的是try_files参数中存在可匹配的本地文件的场景；当最后一个参数是URI路径时，Nginx会将其视为新请求触发内部重定向，此时会重新匹配所有location规则，不受当前命名location的限制；只有当最后一个参数是**明确的状态码（如=404）**时，才会在当前上下文直接返回结果，不会触发重定向。

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