Nginx 不支持在 ssl_certificate 或 ssl_certificate_key 中直接使用变量，因 TLS 握手时请求上下文未解析；可行方案是：①用 map + if + return 实现 IP 段跳转至专用证书页；②用 map + 多 server 块按 SNI 子域名分流，各块独立配置证书。
Nginx 本身不支持在 ssl_certificate 或 ssl_certificate_key 指令中直接使用变量（如 $backend_cert），因此无法通过 map 指令动态切换 SSL 证书文件路径。这是由 OpenSSL 和 Nginx 的 TLS 握手机制决定的：证书必须在 TCP 连接建立初期（ServerHello 阶段）就确定并发送，而此时请求上下文（包括 $remote_addr、$http_host 等）尚未完全解析，map 变量也未完成查表。
但“按客户端 IP 段提供不同品牌 SSL 证书”这一需求，在真实场景中通常指向两个可落地的目标：
- ✅ 目标一：为不同来源的客户端（如内网/合作方）提供专属 TLS 配置（如自签名或私有 CA 证书），用于 API 对接或设备认证；
- ✅ 目标二：实现基于源 IP 的 SNI 分流，将不同 IP 段的请求导向不同 server 块，各块独立配置证书（即“逻辑多站点”）。
下面分两种可行路径说明，均基于 map + 标准 Nginx 机制，无需 Lua、OpenResty 或外部服务。
H3 使用 map + if + return 实现“IP 段专属证书提示页”（轻量验证型）
适用于内部系统、测试环境或设备对接场景：当特定 IP 段（如 192.168.100.0/24）访问时，不走主站 HTTPS，而是返回一个带自签名证书的专用响应页（含证书下载链接、校验说明等）。
-
在
http{}块顶层定义 IP 映射：map $remote_addr $is_internal { default 0; 192.168.100.0/24 1; 10.50.0.0/16 1; } -
在
server { listen 443 ssl; }块中添加判断：server { listen 443 ssl; server_name example.com; # 主站证书（默认） ssl_certificate /etc/nginx/ssl/public/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/public/privkey.pem; location / { # 若为指定内网 IP，重定向到专用证书页（该页可配另一 server 块） if ($is_internal) { return 302 https://cert.example.com/internal-info; } proxy_pass http://app_backend; } } -
单独配置
cert.example.com的 server 块，使用私有 CA 证书：server { listen 443 ssl; server_name cert.example.com; ssl_certificate /etc/nginx/ssl/internal/ca-bundle.crt; ssl_certificate_key /etc/nginx/ssl/internal/ca.key; location /internal-info { root /usr/share/nginx/html; try_files /cert-page.html =404; } }
⚠️ 注意：
if在 location 中虽不推荐用于复杂逻辑，但此处仅作简单跳转，安全且稳定；return不触发 rewrite 循环，开销极低。
H3 使用 map + split_clients（伪）+ 多 server 块实现 SNI/IP 感知分流（生产级）
Nginx 原生不支持基于 $remote_addr 动态选 server，但可通过 SNI 域名 + 客户端 IP 辅助识别，结合前置 DNS 或客户端 Hosts 控制，达成“不同 IP 段看到不同证书”的效果。
实际做法是：让不同 IP 段的客户端访问不同子域名（如 cn.example.com / int.example.com），再用 map 将域名映射为后端组，同时各子域名对应独立 server 块并配置专属证书。
-
步骤 1：在
http{}中定义域名 → 后端组映射（也可扩展为 IP+Host 复合判断）map $host $upstream_group { default "prod"; cn.example.com "cn_cluster"; int.example.com "int_cluster"; } -
步骤 2：为每个子域名配置独立
server，绑定不同证书：server { listen 443 ssl; server_name cn.example.com; ssl_certificate /etc/nginx/ssl/cn/_.cn.example.com.pem; ssl_certificate_key /etc/nginx/ssl/cn/_.cn.example.com.key; location / { proxy_pass http://$upstream_group; proxy_set_header Host $host; } }
server { listen 443 ssl; server_name int.example.com;
ssl_certificate /etc/nginx/ssl/int/internal-ca-bundle.crt;
ssl_certificate_key /etc/nginx/ssl/int/internal-ca.key;
location / {
proxy_pass http://$upstream_group;
proxy_set_header Host $host;
}}
- 步骤 3（关键）：让目标 IP 段自动访问对应子域名
- 内网 DNS：将 `example.com` A 记录对 `192.168.100.0/24` 解析为 `int.example.com` 的 CNAME 或直接返回其 IP；
- 或前端 JS 重定向（适用于 Web 客户端）：
```js
// 检测内网 IP 后跳转
if (window.location.hostname === 'example.com' &&
/^192\.168\.100\./.test(getClientIP())) {
window.location.host = 'int.example.com';
}✅ 优势：完全符合 TLS 规范，证书在 SNI 阶段即正确协商，无兼容性问题；运维清晰，证书更新互不影响。
H3 补充：为什么不能直接 ssl_certificate $cert_path？
- Nginx 官方文档明确说明：
ssl_certificate和ssl_certificate_key不接受变量（see nginx.org）； - 变量解析发生在 HTTP 请求阶段（
rewrite/proxy_pass时），而 TLS 握手发生在 TCP 层之上、HTTP 之前； - 即使强行用
perl或lua模块注入，也会破坏握手时序，导致浏览器报ERR_SSL_VERSION_OR_CIPHER_MISMATCH或SEC_ERROR_UNKNOWN_ISSUER。
所以，任何声称“用 map 直接换证书”的方案，本质都是绕过该限制的间接实现——要么靠 SNI 分流，要么靠应用层跳转，要么靠客户端配合。
不复杂但容易忽略。
