直接原因是nginx在linux下无法解析带utf-8 bom的证书或私钥文件，误判为非法pem格式而报错；需用file或hexdump确认bom，用dos2unix或sed清除，并验证开头结尾标记及模数一致性。
直接原因是 Nginx 在 Linux 环境下无法正确解析带 UTF-8 BOM（EF BB BF）的证书或私钥文件，会将其误判为非法 PEM 格式，进而触发“key values mismatch”“SSL_CTX_use_PrivateKey_file failed”等报错——哪怕密钥对本身完全匹配。
确认配置文件或证书是否含 BOM 头
这是最易被忽略的第一步。BOM 是 Windows 编辑器（如记事本）保存 UTF-8 文件时自动插入的三个不可见字节，Nginx 读取时会把它们当作 PEM 内容的一部分，导致解析中断。
- 用
file命令检查编码：file example.com.crt和file example.com.key
若输出含 UTF-8 Unicode (with BOM) text，即确认存在 BOM；正常应显示 ASCII text - 用十六进制查看前几个字节：
head -n1 example.com.crt | hexdump -C | head -n1
若开头出现 ef bb bf，就是 BOM 头 - 同理检查 Nginx 主配置文件（如
nginx.conf或server.conf），尤其当报错提示类似unknown directive “锘?”时，基本可锁定为配置文件带 BOM
清理 BOM 和 Windows 换行符
BOM 和 CRLF（\r\n）常同时存在，需一并清除，否则仍可能失败。
- 使用
dos2unix一键处理：dos2unix example.com.crt example.com.key nginx.conf - 若未安装
dos2unix：
CentOS/RHEL：yum install -y dos2unix
Debian/Ubuntu：apt-get install -y dos2unix - 无 root 权限时可用
sed清除 BOM：sed -i '1s/^\xEF\xBB\xBF//' example.com.crt
并用sed -i 's/\r$//' example.com.key清除行尾\r
验证 PEM 结构是否恢复干净
清理后必须肉眼+命令双重确认，避免残留或误操作。
- 检查开头结尾是否标准：
head -n1 example.com.crt→ 应为 -----BEGIN CERTIFICATE-----tail -n1 example.com.crt→ 应为 -----END CERTIFICATE-----
私钥同理，应为 -----BEGIN RSA PRIVATE KEY----- 或 -----BEGIN PRIVATE KEY----- - 再次运行模数比对，确保逻辑未被破坏：
openssl x509 -noout -modulus -in example.com.crt | openssl md5openssl rsa -noout -modulus -in example.com.key | openssl md5
两行 MD5 输出必须完全一致 - 用
nginx -t测试语法，再nginx -s reload观察是否启动成功
预防后续再出现 BOM 问题
根源在编辑习惯。运维中应建立统一的文本处理规范：
- 所有 Nginx 配置、证书、私钥文件，一律使用支持“UTF-8 无 BOM”保存的编辑器（如 VS Code、Notepad++、vim）
- VS Code 中：右下角点击编码格式 → 选择 Save with Encoding → UTF-8（非 UTF-8 with BOM）
- Linux 服务器上优先用
vim或cat >创建新文件，避免从 Windows 直接复制粘贴 - 自动化部署时，在脚本末尾加入
dos2unix *.crt *.key *.conf 2>/dev/null || true作为兜底
