ssl指令仅在server块生效，不继承；多server间按sni匹配或default_server优先级选择，同一server内同名指令全量覆盖。
当 Nginx 配置中出现多个 SSL 相关指令（如 ssl_certificate、ssl_ciphers、ssl_protocols 等）在不同作用域重复定义时，实际生效的并非“最后写的”或“最靠近请求的”，而是由明确的上下文继承规则和匹配优先级共同决定。理解这套逻辑，是避免证书错配、TLS 握手失败、降级到弱协议等生产问题的关键。
SSL 指令的作用域限制与继承边界
SSL 指令不能随意嵌套，它们仅在特定上下文中合法且有效：
-
必须出现在
server块内：像ssl_certificate、ssl_certificate_key、ssl_ciphers、ssl_protocols等，均不允许在http或location块中直接配置（否则启动报错） -
http块可设全局 TLS 参数（如ssl_buffer_size、ssl_session_cache），但不参与证书选择或加密套件协商 -
location块中无法覆盖 SSL 握手行为；它只影响请求到达后的 HTTP 处理阶段（如重写、代理、静态文件服务）
多 server 块间 SSL 配置的“谁生效”：SNI 匹配优先于书写顺序
当多个 server 块监听同一端口（如 listen 443 ssl）时，Nginx 不按配置文件顺序选 server，而是依赖客户端是否发送 SNI 扩展：
- 若客户端支持并发送了 SNI（绝大多数现代浏览器、curl、移动端 App），Nginx 会根据
server_name精确/通配符匹配对应server块，并使用其全部 SSL 指令（证书、密钥、套件等） - 若客户端无 SNI（老旧嵌入式设备、部分 IoT 终端），Nginx 将忽略所有
server_name，直接使用该端口下标记为default_server的块；若未显式声明，则取该端口第一个定义的server块 - 这意味着：即使你写了十个
server，只要没配default_server，无 SNI 请求就会“悄悄”落到第一个块上——可能用错证书，触发浏览器警告
同一 server 块内 SSL 指令的覆盖逻辑：无继承，仅唯一生效
在一个 server 块中，同一 SSL 指令不允许重复出现（语法错误），但可通过条件分支间接影响行为：
-
ssl_ciphers和ssl_protocols是“全量替换”型指令：后出现的完整覆盖前一个，不合并、不追加 -
ssl_ciphers对 TLS 1.2 和 TLS 1.3 生效机制完全不同：TLS 1.3 套件（以TLS13-开头）必须显式列出且置于最前；混入 TLS 1.2 命名套件不会报错，但会导致 TLS 1.3 客户端协商失败或降级 -
ssl_prefer_server_ciphers on对 TLS 1.3 完全无效，仅对 TLS 1.2 握手起作用——它让服务端强制按自己排序选择套件，而非接受客户端偏好
兜底与容错：显式 default_server 是防冲突的第一道防线
为避免隐式默认导致的证书错配或协议混乱，强烈建议为每个 HTTPS 端口单独定义最小化兜底 server：
- 使用
listen 443 ssl http2 default_server;明确标记 -
server_name _;表示不匹配任何域名（占位符） - 配置一套基础但安全的证书（可复用 Let’s Encrypt 泛域名或专用兜底证书）
- 返回
return 444;（关闭连接）或return 404;+ 自定义页面，不泄露服务信息
