Nginx try_files 配置错误易致301/302重定向死循环，主因是内部重定向后再次匹配同一try_files规则；需检查Location响应头、fallback URI触发路径、location匹配顺序，并启用error_log捕获“rewrite or internal redirection cycle”日志。
当 Nginx 的 try_files 指令配置错误时，极易引发 301/302 重定向死循环（比如浏览器报 “ERR_TOO_MANY_REDIRECTS”），本质是请求被反复 rewrite 或内部跳转，最终又回到同一 location，形成闭环。排查关键在于确认重定向路径、定位触发条件、检查 fallback 行为是否意外触发。
观察响应头与真实跳转链路
用 curl -I 或浏览器开发者工具的 Network 面板查看完整重定向链：
- 重点关注
Location响应头值是否在几个 URL 间反复出现（如/→/index.php→/） - 注意状态码是否连续出现 301/302，而非 200 或 404
- 添加
-v参数用 curl 跟踪全部跳转：curl -v http://example.com/
检查 try_files 后备项是否隐式触发 rewrite 或内部重定向
try_files 最后一个参数若为 URI（非文件路径），Nginx 会发起内部重定向（internal redirect）到该 URI —— 这常是死循环源头：
- 例如
try_files $uri $uri/ /index.php;：当请求/且/index.php存在时，Nginx 内部跳转到/index.php - 但如果
/index.php所在的 location 又匹配了同一条try_files规则（比如用了location ~ \.php$但未终止匹配），就可能再次执行try_files，又跳回/index.php - 典型错误写法：
location / { try_files $uri $uri/ /index.php; }+location ~ \.php$ { try_files $uri =404; fastcgi_pass ...; }—— 此时/index.php会先进入第一个 location 匹配，内部跳转后又进入第二个 location，而第二个 location 的try_files $uri =404若没命中真实文件，可能再次 fallback 到上级逻辑
验证 location 匹配顺序与内部跳转终止条件
Nginx 的内部重定向会重新进行 location 匹配，必须确保 fallback URI 进入的 location 不再触发同类 try_files：
- 将 PHP 处理块明确限定为
location = /index.php或使用^~前缀避免正则干扰 - 在处理脚本的 location 中，禁用
try_files，或仅用=404终止：location = /index.php { fastcgi_pass ...; } - 启用
error_log /path/to/error.log notice;，并复现请求，查看日志中是否有"rewrite or internal redirection cycle"报错（这是最直接证据）
简化并隔离测试配置
临时注释掉其他 location，只保留最小复现场景：
- 新建一个测试 server 块，仅含基础 root 和一条 try_files
- 用
echo模块（需编译支持）或返回固定内容快速验证行为：location = /test { return 200 "hit /test"; } - 逐步取消注释，观察从哪一步开始出现跳转异常
