API接口被try_files误触发的根本原因是location匹配顺序与路径设计不一致——Nginx将/api/users当作静态路径查找文件，因未找到而兜底至/index.html或404；正确做法是将location /api/ { proxy_pass http://backend/; }置于location /之前，确保API请求不落入try_files范围，并通过curl、日志及响应头验证是否生效。
API 接口被 try_files 误触发，本质是 location 匹配顺序和路径设计没对齐——Nginx 把 /api/users 当成静态路径去查文件，结果找不到，就按 try_files 规则兜底到 /index.html 或返回 404。这不是 try_files 的错，而是它被放到了不该管的范围里。
必须用独立 location 显式拦截 API 路径
所有 API 请求都要在通用 location / 之前，单独定义一个精确匹配的块：
- 写成
location /api/ { ... }（结尾带斜杠），不是/api或/api/.* -
proxy_pass地址末尾也加斜杠，比如proxy_pass http://backend/;，确保路径透传不丢前缀 - 这个
location块必须放在location /之前，Nginx 才会优先匹配最长前缀
避免兜底规则覆盖 API 路径
检查你当前的 try_files 是否出现在太宽泛的 location 中：
- 错误写法：
location / { try_files $uri $uri/ /index.html; }—— 它会无差别处理所有路径，包括/api/login - 正确写法：把 API 分离后，
location /只负责前端资源，try_files自然就只查$uri对应的 JS/CSS/图片或/index.html - 如果 API 路径不统一（比如有
/v1/、/admin-api/），每个都得单独配location，不能靠正则模糊匹配
验证 API 是否真正绕过了 try_files
改完配置后别只看页面，直接测接口本身：
- 用
curl -I http://your-domain.com/api/ping，响应状态码必须是 200，且Content-Type是application/json，不是text/html - 查看 Nginx access.log，确认该请求没进
location /日志行，而是进了location /api/对应的日志段 - 临时在
location /api/里加一行add_header X-Handled-By "API-Proxy";，再 curl 看响应头是否存在
额外加固：封掉 API 路径下的静态试探
即使配了 location /api/，有些客户端或爬虫仍可能发 /api/.env、/api/config.php 这类请求。Nginx 不该去磁盘找这些文件：
- 在 API location 内加拒绝规则：
location ~* \.(php|env|ini|log|yml)$ { return 404; } - 或者更彻底：在
location /api/里不写try_files，也不设root，只保留proxy_pass和必要头设置 - 这样所有以
/api/开头的请求，根本不会触发任何文件查找，直接转发
