Nginx HTTPS配置需确保证书链完整、私钥无密码且权限为600、ssl_certificate指向fullchain.pem、listen必须含ssl关键字，否则将静默失败或握手错误。
直接配 ssl_certificate 和 ssl_certificate_key 就能跑 HTTPS，但路径错、权限松、格式混，Nginx 会静默失败或启动报错。
确认证书和私钥文件是否可用
别急着改配置，先验证两个文件本身没问题：
-
openssl x509 -in /etc/nginx/ssl/example.com.crt -text -noout—— 能打印证书信息，说明.crt是有效 PEM 格式证书；如果报错“unable to load certificate”，大概率是 DER 格式或内容损坏 -
openssl rsa -in /etc/nginx/ssl/example.com.key -check -noout—— 能返回 “RSA key ok”，说明私钥未损坏且未加密；若提示 “Enter pass phrase”，说明私钥带密码，Nginx 启动时无法自动读取（必须手动输入，不适用于生产） - 检查权限：
ls -l /etc/nginx/ssl/应显示私钥权限为-rw-------（即 600），否则 Nginx 会拒绝加载并报SSL_CTX_use_PrivateKey_file() failed
server 块里必须写对 listen 和 ssl_* 指令
Nginx 不会自动推断 HTTPS，listen 443 和 listen 443 ssl 完全不同：
- 必须显式写
listen 443 ssl;，漏掉ssl关键字，Nginx 就当普通 HTTP 服务处理，TLS 握手直接失败 -
ssl_certificate必须指向证书文件（含服务器证书 + 中间证书拼接后的完整链），不是单个.crt；常见错误是只放了域名证书，没拼中间 CA，导致部分客户端（如 Android、旧 iOS）握手失败 -
ssl_certificate_key只能是私钥文件，不能是 .pem 或 .pfx；Nginx 不支持 PKCS#12（.p12/.pfx）格式，得先用openssl pkcs12 -in cert.p12 -nodes -nocerts -out key.pem抽出私钥
多个域名共用 IP 时要注意证书覆盖逻辑
同一 IP 上多个 server 块监听 443，Nginx 默认按配置顺序匹配，但 TLS 层的 SNI（Server Name Indication）决定了哪个证书实际下发：
- 只要每个
server块都有独立的server_name和对应的ssl_certificate/ssl_certificate_key，SNI 正常时就能正确分发证书 - 但如果某个
server块没写ssl_certificate，或路径无效，Nginx 会 fallback 到第一个定义的 SSL 配置（哪怕它server_name不匹配），造成证书域名不一致警告 - 测试方法：用
curl -vI --resolve example.com:443:your.ip https://example.com看* Server certificate:是否匹配预期域名
reload 前必须做语法检查和路径校验
nginx -t 只检查语法，不校验证书文件是否存在或可读：
- 运行
nginx -t通过后，再手动用sudo -u www-data cat /etc/nginx/ssl/example.com.crt模拟 Nginx 进程身份读取，确认无 permission denied - 私钥路径若用相对路径（如
cert/server.key），Nginx 会相对于nginx.conf所在目录解析，极易出错；一律用绝对路径 - 修改后 reload：
sudo nginx -s reload，不要restart；如果 reload 失败，journalctl -u nginx --since "1 minute ago"看真实错误，比日志文件更及时
最常被忽略的是证书链完整性 —— 单独一个 .crt 文件几乎不够用，多数 CA（包括 Let’s Encrypt）要求把中间证书追加到域名证书后面，否则 iOS 和 Java 客户端容易校验失败。这个细节不报错，但用户访问时 HTTPS 就是黄色感叹号。
