同一URL可能涉及精确、前缀、正则location以及内部跳转，规则写在看似正确位置不代表请求最终由它处理。应根据完整配置与实际URI追踪匹配，而不是凭配置块排列位置猜测。
固定一个请求样本
记录原始URL、规范化后的路径、参数与方法，区分浏览器重定向和服务器内部重写。缓存、CDN或静态响应可能使请求根本没进入预期源站。先确认样本可重复，再讨论哪一条location负责处理，避免同时拿多个相似地址比较。
按当前配置理解匹配类别
精确匹配、普通前缀、带修饰的前缀和正则有不同选择规则，嵌套与内部跳转还会使判断复杂。查当前Nginx文档并读取完整include，不把“放在最前面”当成万能优先级办法。命中前缀也不总意味着后续不再检查其他规则。
用受控诊断证明最终路径
在测试环境可通过合适日志或临时无敏感标记确认处理位置，注意清理诊断输出。观察实际文件、上游与响应状态，不仅看某个自定义头是否存在。若发生内部重写，原先命中位置可能并非最终生成内容的位置，应把过程一起记录。
修正后验证相邻路径
对目标、相似目录、静态文件和不存在路径分别回测，确认安全规则和PHP处理没有被新优先级绕开。保存配置检查及回退文件，再按流程重载。不要为某个资源成功而把更大范围请求全部送进PHP或全部放行。
关键区别
精确与前缀：不同匹配方式；不能只按文件排列猜。
正则规则：可能参与最终选择；顺序与上下文需核对。
内部跳转：可能再次选择处理；要看最终响应来源。
怎样确认处理到位
目标请求的处理位置有证据，相邻路径行为正确，静态与PHP边界未被破坏，配置通过检查且可恢复。
容易误判的边界
本篇不是一段可覆盖所有嵌套规则的速查口诀；复杂配置必须结合完整上下文和实际请求验证。
