nginx master进程会因ssl_password_file指向含空白符的文件而静默挂起，无法派生worker；应移除该指令或确保密码文件首行真正为空（无任何字符），并严格控制权限与写入方式。
当 Nginx 的私钥文件实际不设密码（即为空密码），但配置中又启用了 ssl_password_file 指令指向一个非空文件，或该文件首行含空白字符（如空格、制表符、换行符），Nginx master 进程就会在启动时卡住——看似运行着，实则无法派生 worker，服务完全不可用。这不是报错退出，而是静默挂起，排查难度高。
为什么空密码会引发挂起？
Nginx 在读取 ssl_password_file 时，严格按“首行内容”作为解密口令。若该行仅含空白符（ \n、\t 等），OpenSSL 库底层会将其视作无效密码尝试，反复重试并阻塞在密钥加载阶段，导致 master 进程停滞在初始化 SSL 上下文环节，无法继续 fork worker 进程。
典型表现：
-
ps aux | grep nginx显示只有 master 进程，无 worker -
nginx -t能通过，但nginx或nginx -s start后无响应 -
strace -p $(cat /var/run/nginx.pid)可见进程卡在read()或SSL_CTX_use_PrivateKey_file()
如何确认是空密码文件惹的祸？
重点检查三处：
- 查看配置中
ssl_password_file指向的路径是否存在：ls -l /path/to/passfile - 检查该文件首行是否“看似为空”：
head -1 /path/to/passfile | cat -A（显示隐藏字符，如^I$表示制表符+换行） - 验证私钥本身是否真需要密码：
openssl rsa -in /path/to/your.key -check -noout；若提示unable to load Private Key且含bad decrypt，大概率是密码不匹配或为空密码误配
安全又可靠的修复方式
核心原则：**不硬编码、不删指令、不改私钥，只修正密码文件内容与使用逻辑**。
- 若私钥确实无密码，应移除
ssl_password_file指令，而非留空文件 - 若需保留该指令（如统一配置模板），则确保文件首行是真正空字符串（不含任何字符），可用：
printf "" > /etc/nginx/ssl_pass - 务必设置权限：
chmod 600 /etc/nginx/ssl_pass && chown root:root /etc/nginx/ssl_pass - 验证修复：
nginx -t && nginx -s reload；再用ps aux | grep 'nginx: worker'确认 worker 已启动
预防后续踩坑的关键点
运维中容易忽略但极关键的细节：
- 所有
ssl_password_file文件必须用printf或echo -n写入，禁用普通echo（它默认追加换行） - CI/CD 自动化部署脚本中，若生成密码文件，需明确判断私钥类型：
openssl rsa -in key.key -noout >/dev/null 2>&1成功则无密码，失败才需提供密码文件 - 日志中不会记录“空密码加载失败”，所以不能依赖 error.log 排查；必须结合进程状态与文件内容交叉验证
