HTTPS 是 Basic 认证的前提，Nginx 仅在 TLS 解密后校验 Base64 解码的凭证并丢弃原始 Authorization 头，通过 X-Auth-User 等可信头向后端透传身份，后端须忽略原始头、校验来源 IP 并只信任 Nginx 注入头。
在 HTTPS 环境下使用 Nginx 的 HTTP Basic 认证，核心是确保凭证只在加密通道中传输，且不被 Nginx 或后端误用或泄露。Nginx 本身不加密密码，而是依赖 HTTPS 层保障 Authorization 头的安全性；它只负责接收、校验并透传可信身份信息给后端。
HTTPS 是 Basic 认证的前提
Basic 认证将用户名密码 Base64 编码后放在 Authorization: Basic xxx 请求头中——Base64 不是加密，仅是编码。若走 HTTP，该头可被任意中间人直接解码获取明文凭证。因此：
- 必须强制客户端通过 HTTPS（443 端口）访问受保护路径，例如用
return 301 https://$host$request_uri;重定向所有 HTTP 请求 - Nginx 配置中
auth_basic指令本身不处理加解密，它只在 TLS 解密后的请求上做 Base64 解码和密码比对 - 证书无需特殊配置，只要 HTTPS 已启用（
ssl_certificate和ssl_certificate_key正确），传输层就已加密整个 HTTP 报文，包括认证头
凭证校验由 Nginx 完成，不透传原始 Authorization 头
启用 Basic 认证后，Nginx 在收到请求时会：
- 解析
Authorization头，Base64 解码得到明文用户名/密码 - 查
auth_basic_user_file中的哈希值（如 bcrypt、apr1 MD5）进行比对 - 认证失败返回 401；成功则放行，并默认丢弃原始 Authorization 头，不转发给后端
这意味着后端收不到 Authorization 头——这是安全设计：避免后端错误地二次解析或日志泄露凭证。如需让后端知晓用户身份，应由 Nginx 主动注入可信头：
location /api/ {
auth_basic "Restricted API";
auth_basic_user_file /etc/nginx/.htpasswd;
<pre class='brush:php;toolbar:false;'># 将认证成功的用户名透传，后端只信任此头
proxy_set_header X-Auth-User $remote_user;
proxy_pass http://backend;}
后端必须忽略原始 Authorization，只信任 Nginx 注入头
即便 Nginx 默认不转发 Authorization，仍需防范攻击者伪造该头绕过网关：
- 后端服务应明确禁用对原始
Authorization头的任何鉴权逻辑 - 只读取 Nginx 显式设置的
X-Auth-User（或X-Auth-Email等）等自定义头 - 建议在后端增加校验：确认请求来源 IP 是 Nginx 内网地址（如
127.0.0.1或10.0.0.0/8），拒绝其他来源的X-Auth-*头 - 若后端也是 Nginx，启用
http_realip_module并配置set_real_ip_from，防止伪造X-Forwarded-For影响身份上下文
进阶：与 JWT 或 mTLS 共存时不冲突
Basic 认证可与其他认证方式共存于不同路径，但不可混用在同一 location：
-
/admin/用 Basic（简单管理后台） -
/api/v1/用 JWT（由上游网关签发，Nginx 透传Authorization: Bearer ...） -
/device/用 mTLS（双向 TLS，提取$ssl_client_s_dn）
关键原则不变：每个 location 只由一种机制完成终端认证，Nginx 负责提取结果、注入标准化头，后端只消费这些头，不回退到原始凭证字段。
