index指令仅对静态文件服务生效，不参与proxy_pass代理逻辑；配置proxy_pass后Nginx直接转发请求，不再查找index文件，所谓“失效”实为误用作用范围。
index 指令在 Nginx 中**只对静态文件服务生效，不参与代理请求的处理逻辑**——这是它“失效”的根本原因。当你用 proxy_pass 转发请求时，Nginx 不会查找或尝试匹配 index 文件，而是直接把请求原样转发给上游服务器。所谓“失效”，其实是误用了它的作用范围。
为什么 proxy_pass 下的 index 指令不起作用
index 指令的设计目标是辅助 Nginx 自动定位本地静态资源（如 / → index.html），它仅在以下场景触发：
- 请求路径指向一个目录（例如访问
https://example.com/） - Nginx 当前正在执行静态文件服务（即没走
proxy_pass） - 对应 location 块中显式配置了
index，且文件存在、可读
一旦配置了 proxy_pass，整个 location 就进入代理模式，Nginx 不再尝试拼接或查找任何本地 index 文件，也不会因缺少 index 而返回 403 —— 这个 403 如果出现，通常来自上游服务本身，而非 Nginx 的 index 逻辑。
常见混淆场景与真实归因
你以为是 index 失效，实际可能是这些情况：
-
前端 SPA 刷新 404：比如 Vue/React 应用访问
/user/profile刷新报 404，这不是 index 没起作用，而是 Nginx 没把该路径回退到index.html；需靠try_files $uri $uri/ /index.html;实现前端路由兜底 -
代理路径错配：例如
location /api/ { proxy_pass http://backend; }，若后端期望接收/api/users，但你写成proxy_pass http://backend/;（结尾带斜杠），会导致路径被截断，后端收不到完整路径，可能返回 404 或 403 - 上游返回 403：后端服务（如 Django、Spring Boot）自身做了权限校验或路径限制，Nginx 只是透传响应；此时查 upstream 日志比查 Nginx 的 index 配置更有效
正确做法：区分静态服务与代理服务
同一 server 块中，应明确划分职责：
- 静态资源走
root+try_files+index - API 或后端服务走
proxy_pass，且不依赖index
示例配置：
location / {
root /var/www/app;
try_files $uri $uri/ /index.html;
index index.html;
}
location /api/ {
proxy_pass http://127.0.0.1:8000/;
proxy_set_header Host $host;
}
注意：/api/ 块里写 index 是无效的，也不需要；而根 location 的 index 只服务于静态首页，与代理完全无关。
验证是否真和 index 有关
快速判断方法：
- curl -I http://localhost/ —— 看响应头
Content-Type是text/html还是application/json；前者走静态，后者走代理 - 检查 error.log 是否出现
directory index of ... is forbidden—— 出现说明进了静态路径但没 index，没出现就基本排除 index 问题 - 临时注释掉所有
proxy_pass，用return 200 "proxy disabled";替代，再测 / 路径 —— 若此时 403 消失，说明原问题确在代理链路，而非 index
