Nginx账户认证无限弹窗主因是密码文件格式不兼容、Nginx无权限读取文件或location配置被覆盖；需用htpasswd -mb生成apr1格式密码，设640权限并属组www-data/nginx，用^~精确匹配路径，且必须启用HTTPS。
输入密码后无限弹窗，不是密码输错，而是认证流程卡在中间环节没走完——Nginx 没法完成校验、没返回成功也没返回失败，客户端只能反复重试。核心问题通常出在三处：密码文件格式不兼容、Nginx 读不到文件、或 location 匹配被覆盖。
检查密码文件是否真正可用
Basic Auth 要求密码必须是 Apache 兼容的哈希格式（如 MD5（-m）或 apr1），不能用普通文本、SHA 或系统 crypt。常见错误是直接写明文密码，或用了不被 Nginx 支持的加密方式。
- 用 htpasswd -mb /etc/nginx/.htpasswd user pass 生成（-m 强制 MD5，-b 支持命令行传参）
- 避免用 -s（SHA），它无 salt，Nginx 可能拒绝解析
- 检查文件内容是否为 user:$apr1$xxx$yyy 或 user:$1$xxx$yyy 格式，不是 user:password
- 确认文件路径在配置中是绝对路径，比如 /etc/nginx/.htpasswd，而非相对路径
确认 Nginx 进程有权限读取密码文件
即使文件存在且格式正确，如果 worker 进程打不开它，认证就无法进行，常表现为 403 或静默失败继而触发重试循环。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 执行 ls -l /etc/nginx/.htpasswd，确保权限是 640（属主可读写，属组可读）
- 属主建议设为 root，属组设为 Nginx 工作进程所属组（通常是 www-data 或 nginx）
- 运行 sudo -u www-data cat /etc/nginx/.htpasswd 测试能否读取；若报 Permission denied，说明权限或组设置不对
验证 location 配置是否被意外覆盖
如果受保护路径（如 /admin/）的 location 块被更精确或更高优先级的规则“劫持”，auth_basic 就不会生效，浏览器收不到 401 响应头，也就不会弹窗——但某些客户端（如 FinalShell 或部分浏览器缓存行为）可能表现异常，误判为“弹窗失败→重连→再弹窗”循环。
- 检查是否有其他 location ^~ /admin/static/、location ~ \.js$ 等规则写在受保护块之前，且匹配了请求路径
- 对固定路径保护，务必使用 ^~ 前缀（如 location ^~ /admin/），避免被正则 location 降级覆盖
- 临时注释掉所有其他 location，只留 auth_basic 块，测试是否恢复正常弹窗，可快速定位冲突
务必启用 HTTPS
HTTP Basic Auth 明文传输 Base64 编码的凭证，现代浏览器对纯 HTTP 下的 auth_basic 会主动限制或降级行为，部分版本甚至屏蔽弹窗或反复刷新认证状态，造成“无限弹”的假象。
- 确认该 server 块监听的是 443 ssl，且已配置有效证书
- 访问地址必须是 https:// 开头；若用 http 访问，即使配置正确，也可能被浏览器拦截或忽略认证头
- 不要在未配 HTTPS 的站点上启用 auth_basic —— 它不仅不安全，还容易引发兼容性问题
