核心是确保Nginx worker进程能安全读取.htpasswd文件：文件须置于非Web可访问路径（如/etc/nginx/），设权限640，属主root、属组与worker用户一致（www-data或nginx），并验证SELinux/AppArmor未拦截，且配置中auth_basic_user_file必须为绝对路径。
排查 htpasswd 密码文件导致的权限拒绝问题，核心是确保 Nginx worker 进程能安全、合法地读取该文件——它既不能被 Web 直接访问，又必须对 Nginx 用户可读。常见报错如 open() "/etc/nginx/.htpasswd" failed (13: Permission denied)，说明权限链在某处断了。
确认 .htpasswd 文件路径与权限设置
密码文件必须放在非 Web 可访问路径（如 /etc/nginx/ 或 /usr/local/nginx/conf/），绝不能放在 /var/www/html 等网站根目录下。创建后立即设好权限：
- 运行
sudo chmod 640 /etc/nginx/.htpasswd：仅属主可读写，属组可读，其他用户无权访问 - 运行
sudo chown root:www-data /etc/nginx/.htpasswd（Debian/Ubuntu）或sudo chown root:nginx /etc/nginx/.htpasswd（RHEL/CentOS）：确保属组与 Nginx 运行组一致 - 用
ls -l /etc/nginx/.htpasswd验证输出类似-rw-r----- 1 root www-data
验证 Nginx 进程用户能否实际读取文件
别只看配置里的 user 指令，要实测 worker 进程视角：
- 查真实运行用户：
ps aux | grep "nginx: worker"，看 USER 列（通常是www-data或nginx） - 模拟访问：
sudo -u www-data cat /etc/nginx/.htpasswd（替换为你的实际用户）。若报Permission denied，说明权限或属组仍不匹配 - 注意：如果用
root启动 Nginx（不推荐），worker 仍会降权，所以仍需按降权后的用户检查
检查 SELinux 或 AppArmor 干预（尤其 RHEL/CentOS 或 Ubuntu）
即使传统权限全对，安全模块也可能拦截对 .htpasswd 的读取：
- RHEL/CentOS：运行
sestatus，若为enforcing，再执行ausearch -m avc -ts recent | grep nginx查是否拦截 - 临时测试：
sudo setenforce 0，刷新页面看认证是否恢复；若恢复，需修复上下文，例如：sudo chcon -t httpd_config_t /etc/nginx/.htpasswd - Ubuntu：运行
aa-status | grep nginx，查看 AppArmor 是否加载对应 profile，日志通常在/var/log/syslog中搜索avc
核对 Nginx 配置中 auth_basic_user_file 路径
配置项必须是绝对路径，且拼写完全准确：
- 检查
auth_basic_user_file值是否带多余空格或换行，例如：auth_basic_user_file /etc/nginx/.htpasswd;（结尾分号不可少） - 避免使用相对路径或变量，Nginx 不解析
$document_root等用于该指令 - 用
sudo nginx -t测试配置语法，但它不会校验文件是否存在或可读，需手动验证
