HTTP基本认证401错误不一定是凭据错误，更可能是Nginx auth_basic配置失效、Authorization请求头被代理丢弃、密码文件路径/权限异常或浏览器缓存旧凭证所致，需从客户端请求头、Nginx配置作用域、代理透传设置及调试日志逐层排查。
HTTP 基本认证返回 401，不一定是用户名密码错了，更可能是 Nginx 配置、请求头、后端透传或认证逻辑本身出了问题。排查要从客户端请求出发，逐层验证服务端处理链路。
确认认证凭据是否被正确发送
浏览器或 curl 发起请求时，必须携带合法的 Authorization: Basic base64(username:password) 请求头。常见疏漏包括：
- 使用 curl 时忘记加
-u user:pass或手动构造 header 时 base64 编码错误（如含空格、换行、中文） - 浏览器缓存了旧的错误凭据，导致反复发送无效 token；可尝试无痕窗口或清除认证缓存
- 前端 JS 发起 fetch/AJAX 时未设置
credentials: 'include'，且未手动拼 Authorization 头
检查 Nginx 的 auth_basic 配置是否生效
Nginx 必须在对应 location 或 server 块中启用并指向有效密码文件：
- 确认启用了
auth_basic "Restricted";，且未被auth_basic off;覆盖（注意继承与作用域） - 密码文件路径正确、Nginx 进程有读取权限（
ls -l /path/to/.htpasswd），格式符合 Apache htpasswd 标准（每行user:$apr1$...） - 若用
auth_basic_user_file指向变量（如$realpath/.htpasswd），确保变量已定义且值合法
留意代理场景下 Authorization 头是否被丢弃
当 Nginx 作为反向代理时，默认会过滤掉部分敏感请求头，Authorization 正在其列：
- 必须显式透传：在 proxy_pass 所在 location 中添加
proxy_pass_request_headers on;（默认已是 on，但某些精简镜像可能关闭） - 更关键的是补上头：加入
proxy_set_header Authorization $http_authorization;，否则后端收不到原始认证信息 - 若后端自己做鉴权（如 Django/Flask），而 Nginx 只是透传，那 Nginx 本身不应配
auth_basic，否则会提前拦截并返回 401
开启调试日志快速定位拦截点
临时启用 Nginx error log 的 debug 级别，能清晰看到认证决策过程：
- 在 nginx.conf 的 main 或 http 块中添加：
error_log /var/log/nginx/error.log debug; - 重启后触发一次失败请求，搜索日志中的
http auth、no user、user not found、invalid credentials等关键词 - 典型线索示例：
http auth: user "alice", pass "xxx" → not found in "/etc/nginx/.htpasswd"，说明用户不存在或文件路径错
不复杂但容易忽略。先抓包看请求头有没有、再查 Nginx 配置是否命中、最后盯住日志里的那句判断依据。
