给网站启用HTTPS已经是当下的标配操作，不仅浏览器会对纯HTTP站点提示“不安全”，搜索引擎排名、小程序接口要求、第三方支付回调等都明确依赖HTTPS。而在众多Web服务器中，nginx凭借高性能和灵活的配置成为部署HTTPS的首选。这篇文章将从证书的获取讲起，一步步完成nginx的HTTPS配置，并汇总常见问题与排查方法，看完就能动手实践。
一、HTTPS证书从哪里来：三种获取方式对比
在动手改nginx配置之前，首先要拿到证书文件。证书本质上是由CA机构签发的一份数字凭证，包含公钥和站点身份信息。获取途径主要有三种，各有适用场景。
第一种是免费证书，最常见的是Let's Encrypt。它提供完全免费的证书，有效期90天，配合certbot工具可以自动申请和续期，非常适合个人网站和中小型项目。第二种是付费商业证书，由DigiCert、GlobalSign或国内的各大云厂商提供，价格从几百元到上万元不等，优点是有效期长、支持通配符和多域名、有商业保障。第三种是自签名证书，用openssl命令自己生成，不需要任何费用，但浏览器不信任，只适合内网测试或开发环境。
无论哪种方式，最终你都会拿到两个关键文件：证书文件（后缀通常是crt、pem或pfx中的前两者）和私钥文件（后缀为key）。nginx需要这两个文件才能完成HTTPS握手。这里要注意，私钥必须妥善保管，绝对不能提交到代码仓库或泄露给外部人员，一旦私钥泄露，证书就失去了意义。
二、nginx配置HTTPS的完整步骤
拿到证书文件后，先在nginx的配置目录下建一个存放证书的文件夹，比如/etc/nginx/cert/，把证书和私钥放进去。然后修改nginx配置文件。假设证书为example.ipipp.com.pem，私钥为example.ipipp.com.key，一个基础的HTTPS配置如下：
# 创建证书目录并上传文件 mkdir -p /etc/nginx/cert # 修改配置前先备份 cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
接着编辑站点配置。如果使用的是默认配置结构，通常在/etc/nginx/conf.d/目录下新建一个default.conf，或者直接修改/etc/nginx/nginx.conf中的server块：
server {
listen 443 ssl;
server_name example.ipipp.com;
ssl_certificate /etc/nginx/cert/example.ipipp.com.pem;
ssl_certificate_key /etc/nginx/cert/example.ipipp.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
# HTTP强制跳转到HTTPS
server {
listen 80;
server_name example.ipipp.com;
return 301 https://$host$request_uri;
}
这段配置里有几个指令需要理解。listen 443 ssl表示监听443端口并启用SSL；ssl_certificate指向证书文件，ssl_certificate_key指向私钥文件；ssl_protocols限定允许的TLS协议版本，建议只保留TLSv1.2和TLSv1.3，禁用早已不安全的老协议；ssl_session_cache和ssl_session_timeout用于会话复用，能减少握手开销，提升HTTPS性能。
第二个server块的作用是把所有HTTP请求301重定向到HTTPS，这是启用HTTPS后的标准做法，可以避免用户手动输入网址时停留在不安全的HTTP连接上。配置完成后，执行以下命令检查语法并重新加载：
# 检查配置语法是否正确 nginx -t # 语法正确后重新加载配置 nginx -s reload
nginx -t这一步千万不要省略。如果配置有语法错误，直接reload会导致失败甚至服务异常。看到test is successful的提示后再执行reload，新的HTTPS配置就生效了。
三、常见问题解答与排查方法汇总
配置过程看似简单，但实际操作中踩坑的人不在少数。下面汇总最高频的几类问题。
问题一：浏览器提示证书链不完整。这种情况通常出现在使用商业证书时。CA签发的证书往往是一条链，包含站点证书和中间证书。如果只上传了站点证书，部分客户端（尤其是手机浏览器和一些编程语言的HTTP库）会校验失败。解决办法是把中间证书内容追加到站点证书文件末尾，顺序是站点证书在前、中间证书在后，中间不能有空行遗漏。用openssl命令可以验证链是否完整：
# 验证证书链（s_server方式模拟） openssl verify -CAfile ca-bundle.crt example.ipipp.com.pem # 查看证书有效期 openssl x509 -in example.ipipp.com.pem -noout -dates
问题二：配置正确但访问不了443端口。nginx配置没问题、reload也成功了，浏览器却一直转圈，这大概率是防火墙或云服务器安全组没有放行443端口。需要同时检查系统防火墙（firewalld或iptables）和云厂商控制台的安全组规则，两边都要放行443的入站流量。
问题三：证书与私钥不匹配。更换证书时如果误用了旧的私钥，nginx虽然可能正常启动，但握手会失败。可以用下面两条命令分别计算证书和私钥的摘要，输出的哈希值必须完全一致：
# 计算证书公钥摘要 openssl x509 -noout -modulus -in example.ipipp.com.pem | md5sum # 计算私钥摘要 openssl rsa -noout -modulus -in example.ipipp.com.key | md5sum
问题四：证书过期忘了续期。Let's Encrypt的证书只有90天有效期，虽然certbot可以自动续期，但建议加上监控，在证书到期前30天收到提醒。可以用crontab定时执行检测脚本，一旦发现剩余天数不足就发通知。另外要养成习惯：替换证书文件后必须执行nginx -s reload，否则nginx还在内存里用旧证书，这是运维中非常经典的乌龙。
问题五：混合内容警告。站点启用HTTPS后，如果页面里还引用了http协议的图片、脚本或接口，浏览器会拦截这些请求并在控制台报警。解决方法是全面排查页面资源，把所有引用统一改为https协议，或者使用相对协议写法，让浏览器自动跟随当前页面的协议。
四、进阶优化建议
基础配置跑通之后，还可以做几项优化。首先是启用HTTP/2，只需把listen指令改为listen 443 ssl http2，能显著提升多资源页面的加载速度。其次是启用OCSP Stapling，让nginx代替客户端去查询证书状态，减少握手延迟，配置中加入ssl_stapling on和ssl_stapling_verify on即可。最后可以引用Mozilla官方推荐的现代加密套件配置，兼顾安全性与旧设备兼容性。安全与性能从来不是二选一，花点时间调优配置，能给用户带来更快的访问速度和更高的安全保障。
nginx配置httpshttps证书ssl证书配置修改时间：2026-09-09 07:08:36