Nginx因Basic Auth密码文件权限不足（如13: Permission denied）可触发500错误；需检查error.log确认，再通过chown/chmod调整属组与权限（如root:www-data + 640），并排除SELinux/AppArmor干扰。
HTTP基本认证（Basic Auth）本身不会直接导致 500 错误——它通常返回 401（未授权）或 403（禁止访问）。但若 Nginx 在读取密码文件（如 htpasswd 文件）时因权限问题失败，且该操作发生在 auth_basic_user_file 指令执行阶段，Nginx 可能无法完成请求处理流程，进而触发内部错误，最终返回 500。
确认是否为密码文件权限引发的 500
关键看错误日志中是否有明确指向密码文件的系统级拒绝信息：
- 运行
sudo tail -n 30 /var/log/nginx/error.log - 查找含
open() "/path/to/.htpasswd" failed (13: Permission denied)的行 - 若存在，说明 Nginx 工作进程（非 root）无权读取该文件，这是典型诱因
检查 Nginx 工作用户与密码文件属主是否匹配
Nginx 默认以非特权用户（如 nginx 或 www-data）运行 worker 进程，它只能读取被授权的文件：
- 查当前工作用户：
ps aux | grep "nginx: worker process"（看 USER 列） - 查密码文件权限：
ls -l /etc/nginx/.htpasswd（路径以你配置中auth_basic_user_file的值为准） - 常见问题：文件属主是
root，权限为600，而 Nginx 用户无读取权
修复密码文件权限与归属
不推荐直接改成 644（尤其在共享主机环境），应最小化授权：
- 方案一（推荐）：把文件属组设为 Nginx 用户所在组，并开放组读权限
例如 Nginx 用户是www-data：sudo chown root:www-data /etc/nginx/.htpasswd && sudo chmod 640 /etc/nginx/.htpasswd - 方案二：直接属主改为 Nginx 用户（适合独立部署）：
sudo chown www-data:www-data /etc/nginx/.htpasswd && sudo chmod 600 /etc/nginx/.htpasswd - 切勿使用
chmod 777或让 root 用户直接运行 worker 进程
排除 SELinux 或 AppArmor 干扰
在 CentOS/RHEL 或 Ubuntu 启用强制访问控制的系统上，即使文件权限正确，策略也可能拦截读取：
- 临时验证：
sudo setenforce 0（SELinux）或sudo aa-disable /usr/sbin/nginx（AppArmor），再测试是否恢复 - 若恢复，需打对应标签：
SELinux 下：sudo chcon -t httpd_sys_content_t /etc/nginx/.htpasswd
AppArmor 下：编辑 profile，添加/etc/nginx/.htpasswd r,
