nginx实现多域名https需为每个域名配置独立server块，绑定专属server_name与证书路径，sni在tls握手初期匹配；无sni请求由default_server或首个块兜底，可用openssl s_client验证。
HTTP/3 本身不改变 SNI 的工作机制，但因底层使用 QUIC（UDP），SNI 传递更依赖客户端与 Nginx 之间网络路径的完整支持。多域名绑定时出现 SNI 握手兼容性故障，本质仍是 TLS 层的 server_name 未被正确识别或传递，只是在 HTTP/3 场景下更容易暴露中间链路限制。
确保每个域名有独立且完整的 HTTPS+HTTP/3 server 块
Nginx 不支持在一个 server 块里用多个 server_name 共享一套证书来服务不同域名——哪怕启用了 HTTP/3。必须为每个域名单独配置：
- 独立的
server { listen 443 ssl http3; }块 -
server_name仅写该域名（如site-a.com），不混写其他域名 -
ssl_certificate和ssl_certificate_key必须精准指向该域名有效的证书（含完整链） - 若用通配符或 SAN 证书，需确认所有域名确实列在证书的
subjectAltName中
验证客户端发起的 SNI 是否真实到达 Nginx
HTTP/3 请求可能被中间设备（如 CDN、企业防火墙、家用路由器）截断或丢弃 Initial packet，导致 SNI 根本没发出去。不能只靠 reload 配置就认为生效：
- 用
openssl s_client -connect site-a.com:443 -servername site-a.com -alpn h3测试：若返回SSL routines::wrong version number或超时，说明 QUIC 连接未建立，先查 UDP 443 通路 - 在 Nginx error 日志中开启 debug：
error_log /var/log/nginx/error.log debug;，搜索quic connection received client hello或client sent server name，确认是否收到预期域名 - 用
tcpdump -i any udp port 443 -w quic.pcap抓包，再用 Wireshark 打开，看 Client Hello 的 SNI 字段是否为site-a.com
检查上游或网关是否干扰 SNI 透传
如果 Nginx 前面还有 CDN、WAF 或反向代理（如另一层 Nginx），它们可能未正确透传 SNI，或强制覆盖了 ALPN 协议列表：
- CDN 回源时，需确保它向上游（你的 Nginx）发送的是原始
Host头，并启用 SNI 透传（如 Cloudflare 的 “Origin Server Name” 设置） - 若你用 Nginx 做二级代理（例如前端 CDN → Nginx A → Nginx B），则 Nginx A 必须在
proxy_pass https://...时启用proxy_ssl_server_name on并设proxy_ssl_name "site-a.com" - 某些 WAF 会重写 ALPN 列表，移除
h3或强制降级为http/1.1，需在 WAF 控制台确认 HTTP/3 开关已打开且未拦截 UDP
避免默认 server 块干扰多域名匹配
当请求未带有效 SNI（如老旧客户端、部分扫描工具），Nginx 会 fallback 到标记 default_server 的块——如果这个块绑的是另一个域名的证书，就会造成“访问 site-a.com 却拿到 site-b.com 证书”的错觉：
- 显式指定一个兜底块：
server { listen 443 ssl http3 default_server; server_name _; ... }，并为其配置一张专用的泛域名或空证书（如自签 fallback.crt） - 不要让任意一个业务域名的 server 块成为隐式 default_server（即不加
default_server参数时，Nginx 取配置文件中第一个 listen 443 ssl 的块） - 用
nginx -T | grep "listen.*443.*default_server"确认只有一个块被标记为 default
