401 Unauthorized 表示请求未提供有效身份凭证或凭证被拒绝，核心是认证失败而非权限不足；需排查 auth_basic 配置是否生效、.htpasswd 文件路径与格式是否正确、Authorization 请求头是否被代理链剥离。
401 Unauthorized 表示 Nginx 要求认证，但客户端未提供有效凭证，或提供的凭证被拒绝。这不是权限不足（403），而是“你还没报上名”或“名字报错了”。排查重点不在文件属主、SELinux，而在于认证配置是否生效、凭证是否匹配、请求头是否被拦截。
确认 auth_basic 配置已启用且作用域正确
Basic 认证必须显式开启，且只对目标 location 生效：
- 检查配置中是否有 auth_basic "提示文字"; 和 auth_basic_user_file /path/to/.htpasswd;
- 确保这两行位于你要保护的
location或server块内，而不是被注释或写在错误位置（比如写在upstream里） - 若用正则匹配 location（如
location ~ ^/admin/），注意其优先级高于普通前缀匹配，可能意外覆盖认证配置
验证 .htpasswd 文件路径与内容有效性
Nginx 不解析密码明文，但会严格校验文件可读性与格式：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 运行 sudo -u nginx cat /etc/nginx/.htpasswd（将
nginx替换为你的 worker 用户，如www-data），确认 Nginx 进程能读取该文件；若报 Permission denied，说明文件权限不对（建议chmod 644，属主为 worker 用户） - 检查文件每行是否为
用户名:加密后的密码格式，密码须用htpasswd -B生成（bcrypt 推荐），避免用明文或过时的 crypt - 可用 htpasswd -v /etc/nginx/.htpasswd username 测试某用户密码是否能通过校验
检查请求头是否被中间设备剥离
Authorization 请求头极易在代理链中丢失，尤其经负载均衡、CDN 或反向代理后：
- 直接用 curl 测试：curl -u user:pass https://yoursite.com/protected/，观察是否返回 200；若成功，说明浏览器环境或前端代码有问题
- 若部署在阿里云 SLB、腾讯云 CLB 等七层负载后，需确认其是否透传
Authorization头——部分默认不透传，需在控制台开启“透传自定义 Header”或配置转发规则 - 在 Nginx 配置中加一行 log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_authorization"';，配合
access_log查看日志中$http_authorization是否为空
区分 auth_request 与 auth_basic 触发的 401
两类 401 来源不同，排查方式也不同：
-
auth_basic 触发的 401：由 Nginx 自身处理，响应头必含
WWW-Authenticate: Basic realm="..."；若无此头，说明 auth_basic 未生效或被覆盖 -
auth_request 触发的 401：是 Nginx 将请求代理到认证服务（如 OAuth 网关）后，由该服务返回的；此时需检查
auth_request指向的地址是否可达、超时设置是否合理、返回状态码是否确为 401 - 二者共存时，
error_page 401 = @login可能同时捕获两者，需结合日志中的$upstream_status或$sent_http_www_authenticate判断源头
