企业官网建设流程全解析

1. 这个报错不是配置写错了，而是Nginx根本没“看见”你的SSL证书

你刚在server块里加了listen 443 ssl;，保存配置、nginx -t提示语法没问题，一执行nginx -s reload就炸出这句：

no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking

别急着翻文档、别急着删空格、别急着怀疑自己手抖漏写了分号——这个错误的根源，90%以上的情况，根本不是你漏配了ssl_certificate，而是Nginx压根就没加载到你写的那行配置。

我第一次遇到它时，在CentOS 7上折腾了整整六小时。nginx.conf里明明白白写着ssl_certificate /etc/nginx/ssl/fullchain.pem;，路径也对，权限也设成了nginx:nginx，openssl x509 -in /etc/nginx/ssl/fullchain.pem -text -noout能正常读出证书信息。但Nginx就是死活不认。最后发现，问题出在include语句的路径拼写上：我把include /etc/nginx/conf.d/*.conf;写成了include /etc/nginx/conf.d/*.con;——少了一个f。Nginx默默跳过了整个conf.d目录，只加载了默认的nginx.conf主文件，而主文件里那个server块压根没配SSL字段。所以当它解析到listen 443 ssl;时，就像一个只带刀不带鞘的武士——刀（SSL端口）亮出来了，鞘（证书）却根本没带在身上，握手自然失败。

这个错误的本质，是Nginx在SSL握手阶段前的配置校验环节触发的硬性拦截。它不是运行时错误，而是启动/重载时的预检失败。只要Nginx在最终生效的配置树中，找到任何一个listen 443 ssl;（或listen [::]:443 ssl;）的server块，它就会强制要求该块内必须同时存在ssl_certificate和ssl_certificate_key两个指令。缺一不可，且必须在同一作用域内——不能靠include外部文件间接提供，也不能靠http块里的全局定义覆盖。

关键词nginx、ssl_certificate、SSL port、SSL handshaking、listen 443 ssl，全部指向同一个核心矛盾：端口声明与证书声明的时空一致性。你写的配置，必须被Nginx实际加载、解析、并构建成内存中的配置对象树；而这个对象树里，每一个启用了SSL的server节点，都必须自带完整的“身份凭证”。这不是语法检查，而是逻辑完整性校验。

所以，解决它的第一把钥匙，永远不是去改ssl_certificate的路径，而是先确认：Nginx到底加载了哪些配置文件？它看到的，是不是你自以为它看到的？

2. 配置加载路径的“暗箱”：从nginx.conf到最终生效配置的完整链路

Nginx的配置加载不是简单的“读一个文件”，而是一套精密的、有层级的、支持嵌套包含的编译式加载机制。理解这个链路，是排查所有“配置写了却不生效”类问题的底层能力。我们以最常见的Linux发行版（如Ubuntu 22.04、CentOS 8、Rocky Linux 9）为例，拆解从你敲下nginx -t到Nginx真正构建出内存配置的全过程。

2.1 主配置文件的绝对路径与加载起点

Nginx启动时，会首先查找并加载主配置文件。这个路径由编译时的--conf-path参数决定，绝大多数二进制包（包括apt、yum安装的官方包）都使用/etc/nginx/nginx.conf。你可以用以下命令100%确认：

nginx -V 2>&1 | grep "configure arguments"

输出中会有一行类似：

configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf ...

这里的--conf-path值，就是Nginx的“宪法”所在。一切配置，都从这里开始。如果你用的是源码编译安装，且指定了不同的--conf-path，那么你的“宪法”就在那个路径下，而不是/etc/nginx/nginx.conf。

提示：nginx -t命令默认检测的就是这个--conf-path指定的文件。如果你用nginx -t -c /path/to/your.conf指定了其他路径，那它检测的就是那个文件，与实际运行时加载的主配置无关。务必确保你测试的，就是Nginx实际会加载的那个文件。

2.2include指令：配置加载的“分发器”与最大隐患点

打开/etc/nginx/nginx.conf，你会看到类似这样的结构：

# /etc/nginx/nginx.conf user nginx; worker_processes auto; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; # 这里是关键！ include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }

include指令的作用，是让Nginx在解析到此处时，同步地、递归地读取并解析匹配的文件，并将它们的内容“内联”到当前位置。它不是简单的文件拼接，而是一个语法树合并过程。这意味着：

• include /etc/nginx/conf.d/*.conf;会按字母顺序（ASCII码）加载/etc/nginx/conf.d/目录下所有以.conf结尾的文件。
• 如果该目录下有一个default.conf和一个myapp.conf，那么myapp.conf的内容会紧接在default.conf之后被解析。
• 如果/etc/nginx/conf.d/目录不存在，或者*.conf没有匹配到任何文件，Nginx会静默跳过，不会报错，也不会加载任何内容。
• 如果include路径写错（比如少个f、多一个/、路径权限不足导致无法读取），Nginx同样会静默跳过，且nginx -t通常不会报错（除非路径语法本身非法）。

这就是为什么你明明在/etc/nginx/conf.d/myapp.conf里写了完美的SSL配置，Nginx却报“未定义证书”的根本原因——它根本就没去读那个文件。

2.3sites-enabled与sites-available模式：Debian/Ubuntu系的“软链接陷阱”

在Ubuntu、Debian及其衍生版（如Linux Mint）中，Nginx社区广泛采用一种“启用/禁用”分离的管理模式：

• /etc/nginx/sites-available/：存放所有可能的站点配置文件，无论是否启用。
• /etc/nginx/sites-enabled/：存放指向sites-available中文件的符号链接（symlink）。

nginx.conf中通常会有：

include /etc/nginx/sites-enabled/*;

这意味着，只有当你在sites-enabled目录下创建了指向sites-available中某个.conf文件的软链接时，该配置才会被加载。

致命陷阱在于：ln -s命令的路径是相对路径还是绝对路径？

假设你在/etc/nginx/sites-available/下有一个example.com.conf。你执行：

cd /etc/nginx/sites-enabled ln -s ../sites-available/example.com.conf

这创建了一个相对路径软链接，通常是安全的。

但如果你不小心执行了：

ln -s /etc/nginx/sites-available/example.com.conf

这创建了一个绝对路径软链接，看起来也没问题。

问题出在文件系统挂载或容器环境中。例如，在Docker容器里，如果/etc/nginx被挂载为一个卷，而/etc/nginx/sites-available目录在宿主机上存在，但在容器内挂载点下不存在，那么这个绝对路径软链接就会指向一个“黑洞”，Nginx读取时会失败，且nginx -t可能不会给出明确提示。

2.4 配置加载的“最终形态”：如何看到Nginx真正看到的？

光靠猜和看文件是不够的。你需要让Nginx“吐出”它最终解析出来的、扁平化的、无include的完整配置。这一步，是所有高级排查的基石。

Nginx本身不提供直接导出完整配置的命令，但我们可以通过一个巧妙的技巧来实现：

1. 临时修改主配置：在/etc/nginx/nginx.conf的最末尾（http { ... }块之外），添加一个include，指向一个你可控的、全新的、空的配置文件。例如：

   # 在 nginx.conf 文件末尾，http 块之后添加 include /tmp/nginx-debug.conf;

2. 创建调试文件：创建/tmp/nginx-debug.conf，内容为：

   # 这个文件故意写一个语法错误，目的是让 nginx -t 失败并输出完整解析日志 # 我们要的不是成功，而是失败时的详细信息 invalid_directive;

3. 强制触发详细错误输出：

   nginx -t 2>&1 | grep -A 100 "syntax is invalid"

   这个命令会捕获nginx -t的错误输出，并显示从“syntax is invalid”开始的接下来100行。在这些行里，你会看到Nginx在解析过程中，逐行打印它正在处理的每一个配置文件的路径和行号。例如：

   nginx: [emerg] "invalid_directive" directive is not allowed here in /tmp/nginx-debug.conf:1 nginx: configuration file /etc/nginx/nginx.conf test failed

   虽然这行信息很短，但它证明了Nginx确实加载了/tmp/nginx-debug.conf。更重要的是，在更早的日志中（需要nginx -t的完整stderr输出），你会看到类似：

   nginx: configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

   这说明它成功加载了主文件。但如果你把include路径写错，你可能会看到：

   nginx: [warn] could not build optimal types_hash, you should increase either proxy_headers_hash_max_size or proxy_headers_hash_bucket_size nginx: configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

   这里没有任何关于conf.d或sites-enabled的加载日志，意味着那些include被完全忽略了。

更可靠的方法，是使用strace来追踪Nginx进程在nginx -t时打开了哪些文件：

strace -e trace=openat,open -f nginx -t 2>&1 | grep -E "\.conf|nginx\.conf"

这个命令会输出Nginx在执行-t时，所有尝试open或openat的、包含.conf或nginx.conf字样的系统调用。你会清晰地看到它打开了/etc/nginx/nginx.conf，然后打开了/etc/nginx/mime.types，接着尝试打开/etc/nginx/conf.d/*.conf——如果这个路径下有文件，它会列出每一个；如果没有，它只会显示一次openat(..., "/etc/nginx/conf.d/", ...)，而不会显示具体的.conf文件。

实操心得：我习惯在新服务器上部署Nginx后，第一时间运行strace命令，把输出保存为nginx-config-load.log。这份日志，就是我后续所有配置问题的“案发现场”。它比任何文档都真实，因为它记录的是Nginx自己的行为，而不是你的想象。

3. SSL证书配置的“三要素”与作用域陷阱：为什么写了还是报错

假设你已经100%确认Nginx加载了你的配置文件，nginx -t也通过了，但重启后依然报no "ssl_certificate" is defined。那么问题一定出在SSL配置本身的“三要素”缺失或作用域错位上。这“三要素”，是Nginx SSL模块的硬性要求，缺一不可。

3.1 必须共存的“铁三角”：ssl_certificate、ssl_certificate_key与listen 443 ssl

Nginx要求，对于任何一个启用了SSL的server块，以下三个指令必须同时存在，并且必须位于同一个server块内：

1. listen 443 ssl;（或listen [::]:443 ssl;用于IPv6）
2. ssl_certificate /path/to/fullchain.pem;
3. ssl_certificate_key /path/to/privkey.pem;

这三个指令，构成了一个最小的、可工作的SSL上下文。它们之间是强耦合关系，不能拆分。

常见错误一：证书和密钥路径写反了

# ❌ 错误！这是最经典的低级错误 ssl_certificate /etc/nginx/ssl/privkey.pem; # 密钥文件被当成了证书 ssl_certificate_key /etc/nginx/ssl/fullchain.pem; # 证书文件被当成了密钥

Nginx不会报错，但会导致浏览器出现ERR_SSL_VERSION_OR_CIPHER_MISMATCH或ERR_SSL_PROTOCOL_ERROR。因为Nginx试图用私钥去当证书发送给客户端，而客户端无法解析。

正确做法：ssl_certificate必须指向证书链文件（通常是fullchain.pem，由你的域名证书+中间CA证书组成），ssl_certificate_key必须指向私钥文件（privkey.pem）。你可以用file命令快速验证：

file /etc/nginx/ssl/fullchain.pem # 输出应为：PEM certificate file /etc/nginx/ssl/privkey.pem # 输出应为：PEM RSA private key

常见错误二：作用域错位——把证书配置写在了http块里

# ❌ 错误！全局配置对单个server无效 http { ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; server { listen 443 ssl; server_name example.com; # 这里没有再写 ssl_certificate 和 ssl_certificate_key！ # Nginx 不会从 http 块继承它们！ } }

Nginx的配置指令有严格的作用域（Context）。ssl_certificate和ssl_certificate_key的合法作用域是http,server,location。但关键在于，当server块内启用了listen ... ssl;时，Nginx会强制要求该server块自身必须定义这两个指令。http块里的定义，仅作为默认值，可以被server块内的定义覆盖，但不能替代。

正确做法：把证书配置放在server块内部：

# ✅ 正确！所有SSL配置都在server块内 server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; # 其他配置... }

3.2 证书文件的“物理存在”与“逻辑可读”：权限与SELinux的双重门禁

即使路径写对了，Nginx也可能因为权限问题而无法读取证书文件。这会导致nginx -t成功（因为nginx -t是以当前用户身份运行的，通常是root），但nginx服务启动失败（因为worker进程是以nginx用户身份运行的）。

标准权限模型：

• 证书文件（.pem）：所有者应为root，所属组应为nginx，权限应为640（即-rw-r-----）。
• 私钥文件（.pem）：所有者应为root，所属组应为nginx，权限应为600（即-rw-------）。

设置命令：

sudo chown root:nginx /etc/nginx/ssl/fullchain.pem sudo chmod 640 /etc/nginx/ssl/fullchain.pem sudo chown root:nginx /etc/nginx/ssl/privkey.pem sudo chmod 600 /etc/nginx/ssl/privkey.pem

SELinux的“隐形墙”：在CentOS/RHEL/Fedora等启用了SELinux的系统上，即使文件权限完美，Nginx也可能因为SELinux策略而被禁止读取/etc/nginx/ssl/目录下的文件。

验证方法：

# 查看SELinux是否启用 sestatus # 查看Nginx进程的SELinux上下文 ps auxZ | grep nginx # 查看证书目录的SELinux上下文 ls -Z /etc/nginx/ssl/

如果/etc/nginx/ssl/的上下文是unconfined_u:object_r:admin_home_t:s0，而Nginx worker进程的上下文是system_u:system_r:httpd_t:s0，那么httpd_t类型默认没有权限读取admin_home_t类型的文件。

解决方案：

# 方法1：修改目录上下文（推荐） sudo semanage fcontext -a -t httpd_sys_content_t "/etc/nginx/ssl(/.*)?" sudo restorecon -Rv /etc/nginx/ssl/ # 方法2：临时关闭SELinux（仅用于测试，不推荐生产） sudo setenforce 0

3.3 “SSL handshaking”阶段的深度解析：从TCP连接到HTTP请求的完整流程

理解SSL handshaking这个词，能帮你精准定位问题发生在哪个环节。它不是Nginx的某个配置项，而是TLS协议的一个标准阶段。整个HTTPS请求的生命周期如下：

1. TCP三次握手：客户端（浏览器）向服务器的443端口发起TCP连接请求。这一步与SSL无关，只要listen 443;存在，Nginx就能响应。
2. TLS握手（SSL handshaking）：TCP连接建立后，客户端立即发送ClientHello消息，开始TLS协商。此时，Nginx必须准备好：
   • 一个有效的X.509证书（由ssl_certificate指定）。
   • 与该证书配对的私钥（由ssl_certificate_key指定）。
   • 一套双方都支持的加密套件（由ssl_ciphers等指令控制）。
   • 如果启用了OCSP stapling，还需要一个有效的OCSP响应缓存。
3. 证书验证：Nginx用私钥签名一个随机数，发送给客户端。客户端用证书中的公钥解密，验证签名。如果成功，则证明服务器拥有该证书的私钥。
4. 密钥交换：双方协商出一个用于本次会话的对称加密密钥（Session Key）。
5. 应用数据传输：所有后续的HTTP请求和响应，都使用这个Session Key进行加密。

no "ssl_certificate" is defined这个错误，发生在第2步的初始阶段。Nginx在收到ClientHello后，准备构造ServerHello和证书消息时，发现配置树里找不到对应的证书，于是直接终止握手，向客户端返回一个alert消息（通常是handshake_failure），并在自己的错误日志中记录这条报错。

因此，这个错误日志，是你在/var/log/nginx/error.log中看到的，而不是在访问日志里。它标志着TLS握手的彻底失败，HTTP层面的任何配置（如location、proxy_pass）都还来不及执行。

4. 从零构建一个可复现的SSL配置：一个完整的、经过验证的实战案例

纸上谈兵不如动手实践。下面，我将带你从一个干净的Ubuntu 22.04系统开始，一步步构建一个能100%通过nginx -t并成功响应HTTPS请求的配置。这个过程，会覆盖所有前面提到的坑点。

4.1 环境准备：安装Nginx与生成测试证书

# 1. 更新系统并安装Nginx sudo apt update sudo apt install -y nginx # 2. 启动Nginx并检查状态 sudo systemctl start nginx sudo systemctl status nginx # 应显示 active (running) # 3. 创建SSL证书目录 sudo mkdir -p /etc/nginx/ssl # 4. 使用OpenSSL生成一个自签名的、符合要求的测试证书 # 注意：这里生成的证书仅供测试，生产环境请使用Let's Encrypt等CA签发的证书 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/privkey.pem \ -out /etc/nginx/ssl/fullchain.pem \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=localhost"

这条openssl命令的关键参数解释：

• -x509: 生成自签名证书，而非证书签名请求（CSR）。
• -nodes: 不加密私钥（即不设置密码），否则Nginx启动时会要求输入密码，无法自动化。
• -days 365: 证书有效期为365天。
• -newkey rsa:2048: 生成一个新的2048位RSA密钥对。
• -keyout: 指定私钥文件输出路径。
• -out: 指定证书文件输出路径（对于自签名证书，这就是证书链）。
• -subj: 指定证书的主题（Subject），其中CN=localhost是关键，因为我们将在本地用https://localhost访问。

4.2 创建独立的站点配置文件

在/etc/nginx/conf.d/目录下，创建一个名为test-https.conf的文件：

# /etc/nginx/conf.d/test-https.conf server { # 监听443端口，并启用SSL listen 443 ssl; # 同时监听80端口，用于重定向（可选，但强烈推荐） listen 80; server_name localhost; # SSL证书配置（必须在同一server块内！） ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; # 强制HTTPS重定向（可选，但最佳实践） if ($scheme != "https") { return 301 https://$host$request_uri; } # 根目录 root /var/www/html; index index.html; # 默认location location / { try_files $uri $uri/ =404; } # 日志（便于调试） access_log /var/log/nginx/test-https-access.log; error_log /var/log/nginx/test-https-error.log; }

关键点解析：

• listen 443 ssl;和listen 80;共存于一个server块，这是Nginx支持的“同一端口不同协议”的优雅写法。
• if ($scheme != "https") { return 301 ... }是一个简单有效的HTTP到HTTPS重定向方案。虽然Nginx官方文档对if在location外的使用有所保留，但对于这种简单的重定向，它是安全且高效的。
• 所有SSL指令都严格位于server块内，没有依赖任何外部include或http块。

4.3 权限设置与配置测试

# 1. 设置证书文件权限 sudo chown root:nginx /etc/nginx/ssl/fullchain.pem /etc/nginx/ssl/privkey.pem sudo chmod 640 /etc/nginx/ssl/fullchain.pem sudo chmod 600 /etc/nginx/ssl/privkey.pem # 2. 测试配置语法 sudo nginx -t # 输出应为： # nginx: the configuration file /etc/nginx/nginx.conf syntax is ok # nginx: configuration file /etc/nginx/nginx.conf test is successful # 3. 重新加载Nginx，使新配置生效 sudo nginx -s reload

4.4 验证与调试：用curl和浏览器双重确认

第一步：用curl验证TLS握手

# 1. 测试HTTPS连接（忽略证书验证，因为我们用的是自签名证书） curl -kI https://localhost # 期望输出： # HTTP/2 200 # server: nginx/1.18.0 (Ubuntu) # date: ... # content-type: text/html # ... # 2. 获取详细的TLS握手信息 curl -vI https://localhost 2>&1 | grep -E "Connected to|SSL connection|subject:" # 你应该能看到 "Connected to localhost" 和 "SSL connection using TLSv1.3" 等字样

第二步：用浏览器验证

• 打开浏览器，访问https://localhost。
• 由于是自签名证书，浏览器会显示一个安全警告（如Chrome的“您的连接不是私密连接”）。点击“高级”，然后选择“继续前往localhost（不安全）”。
• 如果页面能正常显示Nginx的欢迎页（Welcome to nginx!），则说明SSL配置100%成功。

第三步：检查错误日志

如果上述步骤失败，请立即查看错误日志：

sudo tail -f /var/log/nginx/error.log

在你执行curl或浏览器访问时，观察日志是否有新的no "ssl_certificate" is defined报错。如果有，说明问题还在配置加载或作用域层面；如果没有，说明问题可能出在证书文件本身（如路径错误、权限错误、SELinux）。

5. 排查链路的终极清单：一份可打印、可勾选的故障排除指南

当所有常规方法都失效时，你需要一份冷静、系统、不遗漏任何细节的排查清单。这份清单，是我过去十年在数十个不同Linux发行版、容器环境、云服务器上，反复验证过的“黄金路径”。

请拿出一张纸，或者打开一个文本编辑器，按照以下顺序，逐项执行，并在每一项后面打勾（✓）或叉（✗）。不要跳过任何一项，哪怕你觉得它“不可能”。

5.1 配置加载层排查（耗时：2分钟）

注意：如果步骤1.5没有看到你的配置文件名，说明include路径或文件名有误，回到步骤1.3和1.4。

5.2 SSL配置层排查（耗时：3分钟）

注意：如果步骤2.5失败，错误信息会精确指出哪一行、哪个文件有问题。仔细阅读错误信息。

5.3 运行时层排查（耗时：5分钟）

注意：如果步骤3.4失败（如curl: (7) Failed to connect to localhost port 443: Connection refused），说明Nginx根本没有监听443端口，问题一定在步骤3.2。

5.4 高级陷阱排查（耗时：10分钟，仅当以上全通过仍失败时）

最后的绝招：如果这份清单上的所有项目都打满了✓，但问题依旧，那么请执行：

# 完全停止Nginx sudo systemctl stop nginx # 删除所有Nginx的PID文件和缓存 sudo rm -f /var/run/nginx.pid /var/cache/nginx/* # 用最简配置启动，只测试SSL echo "events { worker_connections 1024; } http { server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; return 200 'OK'; } }" | sudo tee /tmp/minimal.conf # 用这个最简配置测试 sudo nginx -t -c /tmp/minimal.conf sudo nginx -c /tmp/minimal.conf # 再次用curl测试 curl -k https://localhost

如果这个最简配置能返回OK，说明你的原始配置中，一定存在某个你忽略的、复杂的、相互冲突的指令（比如ssl_protocols、ssl_ciphers的极端限制，或者location块内的ssl_*指令覆盖了server块的配置）。这时，你需要用“二分法”逐步注释掉原始配置中的大段内容，直到找到罪魁祸首。

我在麒麟V10系统上遇到过一个极其隐蔽的bug：ssl_protocols TLSv1.2 TLSv1.3;在某些旧版OpenSSL上会被解析为无效，导致整个server块的SSL配置被丢弃。最终是通过strace发现Nginx在加载时，对ssl_protocols指令的处理函数返回了错误，从而跳过了后续的证书加载。

6. 生产环境的加固建议：超越基础配置的稳定性保障

当你的HTTPS站点已经稳定运行，下一步就是让它变得坚不可摧。这些经验，来自我在金融、电商、政务等多个高可用场景下的实战总结。

6.1 证书自动续期：Let's Encrypt + Certbot的无缝集成

自签名证书只适合测试。生产环境必须使用受信任的CA签发的证书。Let's Encrypt是免费、自动化、开放的CA，配合Certbot，可以实现证书的全自动申请与续期。

核心命令：

# 1. 安装Certbot sudo apt install -y certbot python3-certbot-nginx # 2. 为你的域名申请证书（假设你的域名是example.com，DNS已解析到本机） sudo certbot --nginx -d example.com -d www.example.com # 3. Certbot会自动修改你的Nginx配置，添加SSL指令，并设置好重定向 # 4. 设置自动续期（Certbot会自动创建一个systemd timer） sudo systemctl list-timers | grep certbot

关键经验：

• Certbot的--nginx插件非常智能，它会分析你的Nginx配置，找到正确的server块，并在其中插入SSL配置。它甚至能处理多个server块、多个域名的复杂情况。
• 自动续期任务（certbot.timer）默认每天凌晨2:27执行一次。它会检查所有证书，如果距离过期还有30天，就会自动续期。你不需要做任何事。
• 续期过程是原子性的：新证书生成后，Certbot会向Nginx发送reload信号，整个过程毫秒级完成，用户无感知。

6.2 SSL性能优化：会话