Nginx 不支持 proxy_ssl_password_file 指令，该指令不存在；必须提前用 OpenSSL 解密客户端私钥为无密码格式，并严格限制文件权限（如 chmod 640、chown nginx），再通过 proxy_ssl_certificate_key 引用。
Nginx 的 proxy_ssl_password_file 指令本身并不存在，这是个常见误解。Nginx 官方不支持通过配置文件自动提供密码来解密受密码保护的客户端私钥（即用于 proxy_ssl_certificate_key 指定的 .key 文件）。如果你的上游服务（如后端 API）要求双向 TLS（mTLS），而你的 Nginx 作为反向代理需携带带密码的客户端证书私钥，那么必须手动处理密钥解密环节。
真正可行且生产环境推荐的方式是：提前移除私钥密码，或使用 OpenSSL 安全解密后保存为无密码版本，并严格控制文件权限。
✅ 正确做法：预解密私钥并安全存储
Nginx 启动时无法交互输入密码，也不读取 proxy_ssl_password_file（该指令在 Nginx 所有官方文档和源码中均未定义）。因此你需要：
- 使用 OpenSSL 将带密码的私钥转为无密码格式；
- 确保该无密码私钥仅对
nginx进程所属用户（通常是www-data或nginx）可读； - 在
nginx.conf中通过proxy_ssl_certificate_key直接引用该文件。
# 假设原始私钥为 client.key.enc，密码为 "mypass" openssl rsa -in client.key.enc -out client.key -passin pass:mypass # 设置严格权限（关键！） chown root:nginx client.key chmod 640 client.key # nginx worker 可读，其他用户不可读
然后在 Nginx 配置中：
location /api/ {
proxy_pass https://backend.example.com;
proxy_ssl_certificate /etc/nginx/ssl/client.crt;
proxy_ssl_certificate_key /etc/nginx/ssl/client.key; # ← 无密码私钥路径
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.crt;
}⚠️ 不推荐但技术上可行的方式：启动前用脚本解密（需谨慎）
若因合规要求禁止长期存储无密码私钥，可考虑在 Nginx 启动前由 systemd 或 init 脚本临时解密到内存文件系统（如 /run），并确保生命周期与 Nginx 进程一致：
# 示例：systemd ExecStartPre 脚本片段
mkdir -p /run/nginx-secrets
openssl rsa -in /etc/nginx/secrets/client.key.enc \
-out /run/nginx-secrets/client.key \
-passin env:CLIENT_KEY_PASS # 密码从环境变量注入
chown nginx:nginx /run/nginx-secrets/client.key
chmod 600 /run/nginx-secrets/client.key对应 Nginx 配置仍指向 /run/nginx-secrets/client.key。
⚠️ 注意：环境变量需通过 systemd 的 EnvironmentFile 或 Environment= 安全传递，切勿硬编码在脚本中。
❌ 常见误区澄清
-
proxy_ssl_password_file是虚构指令，Nginx 不识别，配置后会导致unknown directive错误； -
ssl_password_file是存在的，但它只作用于 Nginx 自身作为 HTTPS 服务器时的私钥解密（即ssl_certificate_key），不适用于反代场景中的proxy_ssl_certificate_key； -
proxy_ssl_certificate_key必须指向明文 PEM 格式私钥（无密码或已解密），否则 Nginx 启动失败或连接上游时报SSL_do_handshake() failed。
不复杂但容易忽略。核心就一条：Nginx 反代不支持运行时输密，所有密码必须提前处理。安全的关键不在“是否加密存储”，而在于“解密后权限是否最小化”。
