Nginx 反向代理 + Let's Encrypt 自动续期：一次配好就不用再管

本文记录于 2026-11-12 的一次实际操作过程，环境为 Linux + 常见开源组件，所有命令均在测试机上验证可执行。

代理规则的最小可用配置

把上游服务藏在 Nginx 后面，只需要一个 server 块。关键是三件事：proxy_set_header 传真实 IP、client_max_body_size 放开上传、proxy_read_timeout 覆盖慢接口。

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    client_max_body_size 20m;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

漏掉 X-Forwarded-Proto 是最常见的坑：后端生成的重定向会变成 http，浏览器直接报混合内容；应用日志里的客户端 IP 也会全部变成 127.0.0.1，排查时毫无用处。

证书申请与续期

用 webroot 方式申请，不占用 80 端口的独占权：

certbot certonly --webroot -w /var/www/html -d example.com
systemctl enable --now certbot.timer
systemctl list-timers certbot.timer

certbot 自带 timer，默认每天跑两次，只有距离到期 30 天内才会真正续期。续期成功后如果 Nginx 没重新加载，浏览器拿到的还是旧证书，所以必须挂 deploy hook：

# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/sh
systemctl reload nginx

怎么确认它真的在续期

配完不等于有效。三个命令可以直接验证：

• certbot renew --dry-run：走完整流程但不落盘，能暴露权限和路径问题；
• openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/cert.pem：看当前证书实际到期时间；
• journalctl -u certbot -n 30：续期是否执行、失败原因都在这里。

另外建议加一条监控：证书剩余天数小于 14 天就告警。证书过期往往发生在周末，而它导致的故障是「整站不可访问」，代价远高于配置成本。

小结

以上步骤在 2026-11-12 的环境里完整走了一遍，结论是：配置本身不难，难点在于「怎么确认它真的生效」。把验证命令固化下来，比记住配置项更有价值。