Nginx 配置 HTTPS 全攻略：从免费证书申请到安全性能调优

发布时间：2026-09-07 11:35 更新时间：2026-09-08 17:04 阅读量：7

如今 HTTPS 早已不是网站的加分项，而是默认门槛。没有加密的 HTTP 页面会被浏览器直接打上"不安全"的标签，搜索引擎也更愿意把靠前的排名给到 HTTPS 站点，至于那些需要用户输入密码、填写收货地址的网站，明文传输几乎等同于把隐私直接写在公开的包裹单上。好在这件事并不需要花一分钱，借助 Let's Encrypt 免费证书和 Certbot 自动化工具，配合一点点配置，就能让 Nginx 站点完整跑在 HTTPS 上。下面就把从证书申请、站点配置到性能调优、自动续期的整条链路从头到尾走一遍。

申请证书的第一步是选对验证方式。最省事的是 Certbot 的 Nginx 插件，它适合 Nginx 已经在 80 端口正常提供服务、目录结构也比较标准的场景，执行一条命令后 Certbot 会自动把证书签下来并写进 Nginx 配置，再自动重载生效。如果不想让工具改动任何配置文件，也可以改用 webroot 验证，Certbot 会在网站根目录放一个临时验证文件，等 Let's Encrypt 通过 HTTP 请求确认域名归属后完成签发。而需要泛域名证书（也就是 *.example.com 这类通配域名）时，就只能走 DNS 验证了，先安装对应 DNS 服务商的插件，再通过 dns-01 挑战拿到证书。无论用哪种方式，最终证书文件都会统一落在 /etc/letsencrypt/live/你的域名/ 目录下，其中 fullchain.pem 是包含中间证书的完整证书链，privkey.pem 是私钥，这两份文件正是后面 Nginx 配置要引用的核心，随时可以用 certbot certificates 命令查看证书的到期时间和存放路径。以最常见的 Nginx 插件方式为例，签发命令大致是这样的：

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

证书到位后，接下来就是在 Nginx 里把 HTTPS 站点搭起来。做法是在站点的 server 块中把监听端口改为 443 并声明启用 SSL，然后填上证书与私钥的路径，同时把协议收紧到 TLSv1.2 与 TLSv1.3，避免老旧的加密协议拖后腿。这一小段配置里有几个细节非常容易踩坑：证书路径一定要指向 fullchain.pem，如果只填单独的证书文件，浏览器会因为没有中间证书链而报错；证书链的拼接顺序必须是服务器证书在前、中间证书在后，一旦顺序颠倒，Nginx 会直接启动失败并提示密钥不匹配；很多老教程里出现的 ssl on; 写法在新版 Nginx（1.25.1 起）中已经移除，现在统一用 listen 443 ssl; 来表达；另外私钥文件建议把权限收紧到 600，防止服务器上的其他用户顺手把它读走。核心配置段大致如下：

server {
    listen       443 ssl;
    server_name  example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers   HIGH:!aNULL:!MD5;
}

既然把网站迁到了 443，别忘了把原来的 80 端口降级成"跳板"，单独建一个监听 80 的 server 块，把所有 HTTP 请求通过 301 永久重定向到 HTTPS 地址，这样用户无论敲哪个地址都会被自动带到加密通道上，也利于搜索引擎把权重集中到唯一的主域名上。配置写完后务必先用 nginx -t 做一次语法校验，确认没有问题再重载 Nginx，避免手误导致整个站点短暂中断。

配置生效只是第一步，HTTPS 还有一个绕不开的话题就是性能。SSL 握手是整个 TLS 过程中最消耗 CPU 的操作，因此首先要保证 Nginx 的工作进程数不低于 CPU 核数，最简单的方式就是设置 worker_processes auto 让系统自动分配。更关键的优化是开启 SSL 会话缓存，让同一客户端在短时间内复用之前的握手结果，而不必每次都重新完成一遍完整的密钥协商，这对 TLS 1.2 场景的提速尤其明显。缓存建议放在 http 层级配置，这样所有虚拟主机都能共享同一份会话缓存，再配合一个合理的 keepalive 时长，HTTPS 带来的那点性能损耗基本可以忽略不计。

因为 Let's Encrypt 签发的证书有效期只有九十天，自动续期就成了必须提前安排好的功课。官方推荐的做法是每天在固定时间跑一次续期命令，不必担心空跑，因为 Certbot 只在证书临近过期时才会真正触发续期，平时执行几乎不产生任何开销。先在服务器上执行 certbot renew --dry-run 验证整条续期链路是否通畅，确认无误后把续期命令写进 crontab，并利用 --deploy-hook 参数在续期成功时自动重载 Nginx。这里要留意 --renew-hook 和 --deploy-hook 的区别，前者无论续期成败都会执行，后者只会在真正续期成功后触发，所以刷新 Nginx 配置这种操作应该交给 deploy-hook 来做。定时任务可以写成这样：

0 3 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

最后聊几个日常运维中常见的问题。如果一台服务器上通过不同域名跑了多个 HTTPS 站点，要明白 SSL 握手发生在 HTTP 请求之前，Nginx 在握手阶段无法靠域名判断该用哪张证书，这项能力依赖 SNI 扩展，好在现代浏览器全都支持、TLS 1.3 更是强制要求，所以只要为每个站点分别配置各自的 server_name 和证书文件即可，千万不要把多个域名的证书混在同一个 server 块里。申请证书时也建议优先考虑一张证书挂多个域名，比如上面命令里用 -d 并列指定 example.com 和 www.example.com，比为每个域名单独维护证书要省心得多。需要下线某个站点时更要格外小心，不要直接手工删除 /etc/letsencrypt/ 下的文件，正确做法是先找出 Nginx 配置里所有引用该证书的地方并替换掉，再用 certbot delete --cert-name 做安全移除，否则线上站点可能瞬间无法访问。平时也可以定期用 openssl s_client -connect 域名:443 检查证书链是否完整、证书是否临近到期，把它纳入月度巡检。HTTPS 的部署其实并不复杂，难的是把申请、配置、优化、续期这条链路上的每一个细节都处理到位，一旦彻底打通，全站加密就能长久稳定地运转下去。如果使用宝塔面板，在"网站 → SSL"里一键申请 Let's Encrypt 证书并开启强制 HTTPS 即可，底层原理与上面这套命令方式完全一致。

继续阅读