Nginx 的 try_files 不能直接判断登录态，需结合 auth_request 模块（推荐）或 auth_basic + error_page 实现拦截重定向；前者通过子请求校验状态并自动跳转，后者利用 401 错误页模拟跳转。
在 Nginx 中，try_files 本身不处理认证逻辑，它只按顺序检查文件或路径是否存在，并做内部重定向；而用户登录状态判断（如是否已通过 Basic Auth 或 cookie 认证）需由其他模块配合实现。要实现“未登录用户访问静态资源时被拦截并重定向到登录页”，不能直接靠 try_files 判断登录态，但可以结合 auth_request 模块（推荐）或 auth_basic + 错误页跳转来间接达成目标。
用 auth_request 实现带登录态校验的 try_files 流程
这是最灵活、推荐的方式：将登录态验证抽象为一个独立的子请求（例如由后端 API 返回 200 表示已登录，401 表示未登录），Nginx 根据该子请求结果决定是否放行或重定向。
配置要点：
- 定义一个
location /auth，指向你的登录态校验接口（如http://backend/auth-check），该接口需根据 cookie/session/JWT 返回 200 或 401 - 主 location 使用
auth_request /auth，触发校验 - 配置
auth_request_redirect指向登录页（自动携带原始请求 URI 作为return_url参数） -
try_files放在认证通过后的处理流程中（例如校验通过后尝试找静态文件，找不到再交给后端）
示例配置：
location /auth {
internal;
proxy_pass http://backend/auth-check;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
<p>location / {
auth_request /auth;
auth_request_redirect <a href="https://www.php.cn/link/3dd640b2748772a55c764c54dc8d0a27">https://www.php.cn/link/3dd640b2748772a55c764c54dc8d0a27</a>;</p><pre class="brush:php;toolbar:false;"># 认证通过后才执行 try_files
try_files $uri $uri/ /index.html;
}
注意：$escaped_request_uri 需提前用 map 定义进行 URL 编码，否则重定向参数可能出错。
用 auth_basic + error_page 模拟“重定向”效果
如果仅用 Nginx 自带的 auth_basic（无后端参与），它只能弹出浏览器认证框，无法跳转到自定义登录页。但可通过 trick 方式“伪装”重定向：
- 启用
auth_basic，并设置auth_basic_user_file - 将 401 错误页设为一个 HTML 页面，其中包含 JS 跳转到登录页（如
window.location.href = '/login?from=' + encodeURIComponent(location.pathname)） -
try_files仍放在主 location 中，但它在 auth_basic 之后执行 —— 实际上，auth_basic 是前置校验，失败即返回 401，不会走到 try_files
这种方式不真正“拦截未登录请求后重定向”，而是让浏览器收到 401 后加载自定义错误页来跳转，体验接近，但非标准重定向（HTTP 状态码仍是 401）。
为什么不建议在 try_files 中直接判断登录态？
try_files 的每个选项只能是文件路径、命名 location 或 URI，它没有条件判断能力，也不能读取 cookie、header 或调用外部服务。你不能写类似 try_files @check_login $uri =404 并期望 @check_login 做登录检查——因为 @check_login 是命名 location，一旦命中就会进入该 block，而它本身无法“返回真假”供 try_files 决策。
换句话说：try_files 是“存在性检查”，不是“逻辑判断”。登录态是动态业务逻辑，必须交由 auth_request、rewrite + return、或者后端统一处理。
补充：简单场景下用 rewrite + cookie 判断（不依赖模块）
若只是检查某个 cookie 是否存在（如 session_id），可用 if + rewrite，但注意 if 在 location 中有局限且易出错：
- 不推荐在
if中使用try_files - 更稳妥的是：先用
if ($cookie_session_id = "") { rewrite ^(.*)$ /login?from=$uri redirect; } - 然后在 login location 或后续 location 中再用 try_files 处理页面逻辑
该方式适合轻量场景，但无法校验 session 有效性（只是检查 cookie 存在），安全性低于 auth_request。
