Nginx try_files 循环实为内部重定向后 location 重新匹配所致，主因是 root 路径错误导致 /index.html 无法命中物理文件而反复 fallback；应检查 root 配置、添加 location = /index.html 精确匹配，排除 rewrite/error_page 干扰，并用 nginx -t 校验。
核心问题在于 try_files 的 fallback 路径（如 /index.html）被当前 location / 块再次匹配，触发新一轮检查，形成闭环。这不是 try_files 本身“反复尝试”，而是 Nginx 内部重定向后重新进入 location 匹配流程导致的。
确认是否真为 try_files 循环
先看错误日志关键特征：
- 日志中明确出现 rewrite or internal redirection cycle
- 末尾总指向同一个路径，例如 internally redirecting to "/index.html"
- 根路径
GET /和GET /favicon.ico都报错，说明是通用匹配逻辑问题
最常见原因：root 路径不匹配或缺失
try_files 检查文件时依赖 root（或 alias）拼出真实磁盘路径。如果 root 指向错误目录，$uri 和 $uri/ 全部失败，最终 fallback 到 /index.html；而该路径又因 root 错误，仍无法命中物理文件，于是再次 fallback —— 循环就此开始。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 检查
location /块内是否已正确定义root，且路径是前端构建产物（如 dist 或 build 目录）的绝对路径 - 避免使用相对路径如
html，应写成/usr/share/nginx/html或/var/www/myapp - 用
ls -l /your/root/path/index.html确认文件真实存在且权限可读
精准拦截 /index.html 请求（推荐方案）
给 /index.html 单独设一个精确匹配 location，让它跳过 try_files 流程，直接返回静态文件：
- 添加配置：
location = /index.html { root /path/to/your/dist; } - 这个
=表示严格等值匹配，只生效于字面量/index.html，不影响其他路由 - 它会短路整个处理链，不再触发内部重定向，彻底切断循环源头
检查是否有干扰性配置
以下配置容易与 try_files 叠加引发二次捕获：
-
location ~ \.html$ { ... try_files ... }：可能让/index.html被再次匹配并重试 -
error_page 404 /：所有 404 都跳回根路径，和 try_files fallback 形成双保险式死循环 -
rewrite ^/(.*)$ /index.html last;：显式 rewrite + last，和 try_files 逻辑重复，极易叠加 - 多个嵌套或重叠的
location /块：尤其在 include 文件中容易遗漏
修复后务必执行 nginx -t 校验语法，再 nginx -s reload 生效。重点验证 GET /、GET /about、GET /favicon.ico 三类请求是否均能正常返回且无 500 错误。
