server_name不可复用，因nginx按加载顺序取首个匹配块，导致其余配置失效；应合并域名于单个server块或拆分为唯一server_name的多个块，并确保证书san覆盖、default_server明确、匹配可验证。
不能安全复用相同的 server_name 规则——这不是复用问题，而是配置逻辑冲突。Nginx 的 server_name 本质是路由分发的唯一标识依据，多个 server 块若声明完全相同的 server_name（且监听相同端口），Nginx 会按配置加载顺序选择**第一个匹配的块**处理所有该域名请求，其余块形同无效，还可能引发不可预期的行为（如证书错配、日志混淆、location 覆盖等）。
明确区分：复用 upstream ≠ 复用 server_name
很多人混淆了两个概念：
-
upstream 可安全复用：一个
upstream块可被任意数量的server块引用，这是设计初衷，完全安全； -
server_name 不可“复用”：它不是资源，而是匹配规则。写两个
server { server_name a.com; ... }，等于让 Nginx 在同一端口上对同一个域名做两套互斥配置，违背虚拟主机基本原理。
正确做法：按业务意图组织 server 块
根据你要实现的目标，选一种清晰结构：
- 多个域名指向同一组后端？→ 用单个 server 块 + 多个空格分隔的域名：
server_name a.com www.a.com b.net; - 不同域名需不同根目录、证书或访问控制？→ 拆成多个独立 server 块，每个块有唯一且不重叠的
server_name：server_name a.com;和server_name b.net; - 需统一管理通配场景（如所有子域）？→ 用通配符或正则，但注意优先级：
server_name *.example.com;或server_name ~^shop\..*;
避免隐性冲突的实操要点
以下细节常被忽略，却直接影响安全性与稳定性：
-
默认 server 必须明确指定：加
default_server参数，防止未匹配 Host 的请求落入意外块：listen 443 ssl default_server; - HTTPS 场景必须匹配证书 SAN：单个 server 块若含多个域名，SSL 证书必须包含全部域名（Subject Alternative Name），否则浏览器报错；
-
不要依赖文件加载顺序做“覆盖”：把不同域名的配置拆到不同 conf 文件，靠文件名排序（如
01-site-a.conf,02-site-b.conf）无法保证语义安全，应靠server_name明确隔离； -
测试匹配结果用 nginx -t + curl -H：
curl -H "Host: example.com" http://127.0.0.1验证是否命中预期 server 块。
小结：安全 = 明确 + 隔离 + 可验证
所谓“安全复用”，其实是放弃对 server_name 的错误复用幻想，转而用更清晰的结构表达真实需求：要么合并域名进一个块，要么分离配置进多个块。Nginx 的匹配机制本身足够可靠，风险只来自人为模糊配置。只要每个 server 块的 server_name 是唯一、无歧义、可验证的，多虚拟主机就天然安全稳定。
