登录页面能正常打开，访问受保护接口却报500，错误日志还出现auth request unexpected status。此时应先看鉴权子请求返回了什么，而不是先延长业务接口超时。
先按状态码区分认证失败与接口故障
auth_request把子请求的2xx视为允许访问，把401或403视为拒绝，其余状态码视为错误。认证服务返回302登录跳转，并不符合这个接口约定。浏览器能跟随跳转打开登录页，不能证明鉴权子请求可用。
核对模块与生效配置
执行nginx -V 2>&1检查构建参数，再用sudo nginx -T查看受保护位置的auth_request及其目标。该模块并非默认编译，静态构建可见--with-http_auth_request_module；发行版动态模块还需核对加载配置。输出可能含敏感配置，不要整份公开。
按一次失败请求的时间关联网关错误日志与认证服务日志。检查内部认证请求的返回值，不要只看主请求最终的500。记录时避免保存Cookie和令牌。
让认证接口返回机器可读的结果
为子请求准备独立认证端点：已认证返回2xx，未认证返回401，无权访问返回403。业务登录页面可以继续使用跳转，但别让子请求端点直接复用浏览器跳转行为。401时Nginx还会把子请求的WWW-Authenticate响应头传给客户端。
可将认证位置设为location = /auth_check { internal; proxy_pass http://127.0.0.1:9000/verify; proxy_pass_request_body off; proxy_set_header Content-Length ""; proxy_set_header X-Original-URI $request_uri; }。地址和端点须替换，并在业务位置配置auth_request /auth_check;。
别忽略凭据转发和递归调用
认证后端若缺少它需要的Cookie或Authorization头，应按接口约定核对转发链路；不要把令牌写进URL或日志。检查认证位置是否再次命中同一鉴权规则，避免递归。不要用auth_request off让全部请求放行来掩盖故障。
用三种身份验证修复结果
先运行sudo nginx -t，通过后平滑重载。在萤光云或LightNode的隔离实例，分别用有效凭据、缺失凭据和无权限账号请求同一资源。验收要同时覆盖允许、401、403三条路径，且错误日志不再出现异常子请求状态。
FAQ
认证端点返回204可以吗？ 可以，属于2xx。
302为什么不能直接表示未登录？ 该模块把401和403作为拒绝，其余非2xx状态是错误。
需要把上传文件再发给认证服务吗？ 按官方示例可关闭子请求请求体，并清空Content-Length。
internal会阻止内部子请求吗？ 不会，它限制客户端直接访问该位置。
改了配置仍500怎么办？ 继续关联认证端点日志，核对实际命中位置和状态码。
温馨提示
保留鉴权规则原配置和回退版本。验证期间用专用测试账号，避免把生产凭据复制到命令历史或调试截图。
