Nginx 默认对无斜杠目录请求（如 /app）自动返回 301 重定向至带斜杠版本（/app/），根源在于 try_files $uri $uri/ =404 中 $uri/ 触发目录存在性检查；关闭方式包括删除 $uri/、改用 alias 严格匹配、或启用 absolute_redirect off。
这是 Nginx 的默认行为，不是配置错误，而是它在处理目录路径时的内置逻辑：当请求一个以目录名结尾、但末尾不带斜杠（如 /app）的 URI，而该路径又对应一个真实存在的本地目录（比如用 root 或 alias 指向了文件系统中的目录），Nginx 就会自动返回 301，把用户重定向到带斜杠的版本（/app/）。
为什么会出现这个“隐式重定向”
根本原因是 Nginx 在匹配 location 后，发现请求路径可能指向一个目录，并且配置中启用了目录索引或使用了 try_files $uri $uri/ =404 这类语句。其中的 $uri/ 会让 Nginx 尝试将请求当作目录访问——如果该目录存在，就返回 301 强制补斜杠；如果不存在，则继续往后匹配或返回 404。
-
常见触发场景：配置了
index index.html;且root指向含子目录的静态文件路径 -
代理场景也受影响：即使用了
proxy_pass，只要 location 块里有try_files $uri $uri/ =404，且后端服务能响应目录结构，就可能触发 - 端口问题会放大影响：若 Nginx 前有负载均衡器（如 LB 监听 80，转发到 Nginx 的 8080），这个 301 重定向默认会带上 8080 端口，导致跳转失败
关闭隐式斜杠重定向的几种方式
核心思路是让 Nginx 不再尝试用 $uri/ 匹配目录，或者禁用它的自动补斜杠逻辑。
-
删掉 try_files 中的
$uri/：例如把try_files $uri $uri/ =404;改成try_files $uri =404;。这样就不会因目录存在而触发 301 -
用
alias替代root并严格匹配末尾斜杠：比如location /app/ { alias /var/www/app/; }，并确保只定义带斜杠的 location，避免/app这种无斜杠路径被单独匹配 -
禁用自动重定向功能：在 server 或 location 块中添加
port_in_redirect off;（适用于旧版 Nginx）或absolute_redirect off;（Nginx ≥ 1.11.8），可防止重定向 URL 暴露内部端口，但不阻止 301 本身
需要保留斜杠规范时的主动控制方案
如果你希望统一 URL 格式（比如所有目录必须以斜杠结尾），就不该依赖隐式行为，而是显式控制：
-
用 rewrite 显式补斜杠：例如
location ^~ /app($|\?) { return 301 $scheme://$host$request_uri/; }，精准捕获无斜杠情况 -
结合正则与条件判断：对非文件请求且无结尾斜杠的路径做 301，例如：
if ($request_uri !~ /$) { set $slash_redirect 1; } if (-d $document_root$request_uri) { set $slash_redirect "${slash_redirect}1"; } if ($slash_redirect = "11") { return 301 $request_uri/; } - 前端或应用层处理更稳妥：在反向代理场景下，让后端服务（如 Express、Django）自己处理路径规范，Nginx 只做透明转发，避免耦合
验证和调试建议
修改后务必验证是否真正生效，避免循环重定向或遗漏路径：
- 用
curl -I http://example.com/path查看响应头中的Location和状态码 - 检查 Nginx error 日志，确认没有
rewrite or internal redirection cycle类报错 - 对比带斜杠与不带斜杠请求的 access log，确认两者是否都返回 200 而非 301
- 若使用 HTTPS，注意
$scheme是否正确，避免混用 http/https 导致跳转异常
