根本原因是浏览器base64凭据未被正确校验或响应头被干扰，导致nginx不返回200而持续返回401；需检查密码文件格式与权限、auth_basic配置作用域一致性、前置代理是否剥离authorization头，并用curl验证凭据传递是否正常。
输入账号密码后反复弹出认证框，不是密码错了，而是认证流程没走完——Nginx 没有真正“认可”这次登录。根本原因在于浏览器发送的 Base64 凭据未被正确校验或响应头被干扰，导致客户端始终收不到 200 响应，只能不断重试 401。
检查密码文件格式与权限是否合规
这是最常被忽略的第一环。Nginx 只认特定格式的密码行和可读权限：
- 每行必须严格为 username:hash 格式，不能有多余空格、注释或空行
- hash 必须是 Nginx 支持的格式（bcrypt 推荐，apr1/MD5 兼容，crypt 不安全不建议）
- 执行 htpasswd -B -c /etc/nginx/.htpasswd user 生成（-B 启用 bcrypt）
- 确认文件归属：运行 chown www-data:www-data /etc/nginx/.htpasswd（Ubuntu/Debian）或 chown nginx:nginx /etc/nginx/.htpasswd（CentOS/RHEL）
- 禁止 web 可访问：确保该文件路径不在 root 或 alias 指向的公开目录下，否则可能被直接下载
验证 auth_basic 配置是否生效且无冲突
多个 location 或 server 块中重复/错位配置会覆盖或失效：
- 确认 auth_basic 和 auth_basic_user_file 在同一作用域（同个 location 或 server 块内），不能一个在 server、一个在 location 里
- 避免嵌套 location 冲突：例如 location /admin { ... } 和 location /admin/api { ... } 中都写了 auth_basic，后者会继承前者，但若后者又删了 auth_basic_user_file 就会出问题
- 检查是否有 satisfy any; 或 allow/deny 规则混用，它们与 auth_basic 是不同认证体系，混用会导致逻辑混乱
- 临时注释掉其他模块（如 auth_request、第三方鉴权模块），排除干扰
抓包确认浏览器是否真发了凭据
用 curl 直接模拟，绕过浏览器缓存和 UI 干扰：
- 执行：curl -v -u user:password http://yourdomain.com/protected/
- 观察响应头：成功应返回 HTTP/1.1 200 OK；若仍返回 401 Unauthorized 且含 WWW-Authenticate: Basic realm="..."，说明校验失败
- 若 curl 成功但浏览器失败，大概率是浏览器缓存了错误凭据：在地址栏输入 about:logins（Firefox）或清除“Basic Auth”相关登录数据（Chrome 需清“密码”和“自动填充”）
- 注意：浏览器对同一 realm 下的凭据会复用，换用户需强制刷新或改 realm 名（如把 "Restricted Area" 改成 "Restricted Area v2"）
排查 HTTPS 与代理环境下的头信息干扰
当 Nginx 前有 CDN、WAF 或反向代理时，原始认证头可能被剥离或污染：
- 确认请求中是否携带 Authorization: Basic xxx 头：用 curl -v 或浏览器开发者工具 Network → Headers 查看 Request Headers
- 若缺失，说明前置设备过滤了 Authorization 头（常见于某些云 WAF 默认策略），需在 WAF 控制台放行该 Header
- 若使用 HTTPS 终止在 Nginx，确保没有配置 underscores_in_headers on; 导致解析异常（虽不直接相关，但属常见配置陷阱）
- 在 location 块中临时加一句：add_header X-Auth-Debug "$remote_user $sent_http_www_authenticate" always;，可直观看到 Nginx 是否识别到用户及返回了什么认证头
