Nginx反向代理HTTPS后端：关闭上游证书校验配置详解与502排查

Nginx 反代 HTTPS 后端最烦的就是证书校验，尤其是内网环境、测试环境，或者上游服务用自签名证书的时候，一配置就报 502，错误日志里全是 upstream SSL certificate verify error。这篇文章不废话，直接把你需要的配置讲清楚，再把这个配置背后的原理和坑都拆开揉碎。

1. 问题场景：什么时候需要忽略上游证书校验

先说清楚一个概念：Nginx 在做反向代理时，如果 proxy_pass 指向的是 https:// 开头的上游地址，Nginx 会以客户端身份去和上游服务器建立 TLS 连接。既然是 TLS 连接，Nginx 默认就会对这个上游服务器的证书做合法性校验，包括证书是否由受信任的 CA 签发、证书域名是否和请求的域名匹配、证书是否过期等等。

这本身是安全机制，正常情况下不该关。但在下面这几类场景里，你会发现这个默认校验非常碍事：

场景一：内网环境用自签名证书

很多企业内部系统，尤其是老系统，直接用的自签名证书或者内部 CA 签发的证书。Nginx 默认的 CA 信任链里当然没有这些证书机构，于是握手直接失败，日志里报 unable to get local issuer certificate。

场景二：上游是 IP 地址或内网主机名

如果 proxy_pass 写的是 https://192.168.1.10:8443，而对方的证书是签给 service.internal.example.com 这种域名的，就算证书本身合法，Nginx 校验主机名这一关也会挂掉，报 SSL: certificate does not match hostname。

场景三：测试环境临时证书

联调阶段，后端同事临时起了个服务，证书可能过期了，或者签错了域名，但你这边只是要验证链路通不通，不想被证书卡住。

这三种场景本质上是同一个诉求：我信任这个上游，我不需要 Nginx 替我做证书校验，请直接建立连接。

2. 标准配置：proxy_ssl_verify off 的正确写法

直接上可用的配置，假设你要把 /api/ 路径代理到内网一台 HTTPS 服务，证书是不可信的：

nginx复制location /api/ {
    proxy_pass https://192.168.1.10:8443;
    
    # 关键配置：关闭对上游证书的校验
    proxy_ssl_verify off;
    
    # 如果不写，默认是 on，但关闭校验时建议显式写 off
    proxy_ssl_server_name off;
    
    # 常规反代头信息，按需保留
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

配置完成后，重载 Nginx：

bash复制nginx -t
nginx -s reload

重点说一下这几行的作用：

proxy_ssl_verify off; 是核心指令，它告诉 Nginx 在向上游发起 TLS 握手时，不再对上游返回的证书链做信任校验。这是解决“证书不被信任”和“证书域名不匹配”问题的直接手段。

proxy_ssl_server_name off; 很多人容易漏掉。这个指令控制的是 Nginx 向上游发起 TLS 握手时是否发送 SNI（Server Name Indication），以及是否用 proxy_ssl_name 指定的名称来校验上游证书。当上游是 IP 地址、并且证书和域名无关时，如果开着 proxy_ssl_server_name on，Nginx 会发送 SNI 并且继续做主机名校验，导致即使 proxy_ssl_verify off 也仍然报错。所以稳妥的做法是：

• 上游是 IP：proxy_ssl_server_name off;
• 上游是域名且证书匹配：可以保持默认 on
• 上游是域名但证书不匹配测试环境：proxy_ssl_verify off 已经足够了，proxy_ssl_server_name 开不开影响不大

如果你的 proxy_pass 上游是一个有域名的地址，但证书是自签的，那么用下面的配置也可以：

nginx复制location /api/ {
    proxy_pass https://internal-service.example.com:8443;
    proxy_ssl_verify off;
}

这种情况下不需要特意加 proxy_ssl_server_name off，因为 Nginx 会自动把 proxy_pass 里的主机名作为 SNI 发送，握手阶段服务器只要不强制校验 SNI，基本都能通。

3. 踩坑排查实录：从 502 到定位证书问题的完整链路

我不止一次见过同事配完这个配置后仍然 502，怎么改都没用。这里把我实际排查这类问题的过程完整写出来，你照着这个思路走，能少走一大截弯路。

第一步：看错误日志

Nginx 报 502 的时候，第一件事不是改配置，而是看日志。默认日志位置是 /var/log/nginx/error.log，如果你自定义了 error_log 路径，就去那里找。

bash复制tail -f /var/log/nginx/error.log

出现证书校验问题时，日志特征非常明显：

code复制[error] 12345#0: *678 upstream SSL certificate verify error: (20:unable to get local issuer certificate) while SSL handshaking to upstream, client: 10.0.0.5, server: _, request: "GET /api/test HTTP/1.1", upstream: "https://192.168.1.10:8443/api/test"

看到 upstream SSL certificate verify error 这行，基本可以断定是证书校验没过。但这里有个细节要注意：错误码 (20:unable to get local issuer certificate) 说明是 CA 信任链问题；如果错误码是 (18:self-signed certificate)，说明是自签名证书；如果是 (51:certificate has expired) 则是证书过期。错误码不同，处理方式其实一样——proxy_ssl_verify off 全都能解决。

第二步：用 curl 复现验证

为什么要先用 curl 验证？因为 curl 和 Nginx 用的都是 OpenSSL，在命令行里可以看到更详细的握手过程。

bash复制curl -v https://192.168.1.10:8443/api/test

如果 curl 报 SSL certificate problem: self-signed certificate，这就确认了上游证书确实不可信。注意加上 -k 参数可以临时绕过验证测试连通性：

bash复制curl -k https://192.168.1.10:8443/api/test

如果 -k 之后接口通，那基本可以确定就是证书校验问题。但此时还不能急着配 proxy_ssl_verify off，因为有可能存在另一种情况。

第三步：检查是不是 SNI 的问题

这一步是我实战中踩过的坑，也是最容易被忽略的。某些 HTTPS 服务（比如启用了 TLS 证书自动选择的服务、或者基于 SNI 做虚拟主机的服务），如果客户端握手时没有发送正确的 SNI，服务端连证书都不会发给你，直接握手失败。这时候错误日志显示的不是证书验证失败，而是 SSL handshake failed 或者 no suitable key share。

排查方法很简单：在 Nginx 配置里先加上 proxy_ssl_server_name on; 和 proxy_ssl_name your.domain.com;，指定正确的 SNI，看看握手是否恢复。如果你确定上游不需要 SNI，再改成 proxy_ssl_server_name off;。

第四步：确认 Nginx 是否真的重载了配置

这个听起来很蠢，但确实发生过。nginx -s reload 成功后，老的 worker 进程会优雅退出，新 worker 进程加载新配置。但如果你是通过 systemctl restart nginx 重启的，注意观察是否有配置语法错误导致重启失败。稳妥做法是：

bash复制nginx -t && nginx -s reload

nginx -t 只检查语法，不检查 SSL 握手是否真的能成功，所以即使 nginx -t 通过了，也不代表代理就一定通。配置完务必实际请求一次接口验证。

第五步：终极验证

配置完后，在 Nginx 所在机器上直接用 curl 走本机端口测试：

bash复制curl -v http://127.0.0.1:80/api/test -H "Host: your.public.domain.com"

这一步能确认 Nginx 的代理链路是否真的通了，同时也验证你的 proxy_set_header Host 配置是否正确。如果这里通了，再从外部访问验证。

整套流程走下来，基本能把 502 的证书问题定位到根上。这里我不建议直接甩一个 proxy_ssl_verify off 就算完，因为如果你不清楚问题是出在证书信任、域名匹配还是 SNI，后续排查其他问题时会非常被动。

4. 指令详解：proxy_ssl_verify 相关的全部关键参数

很多教程只提一句 proxy_ssl_verify off 就结束了，但实际上 Nginx 和上游 TLS 相关的指令成体系，理解它们之间的关系，才能在不同场景下灵活组配。

4.1 proxy_ssl_verify

这是总开关，默认值是 on（Nginx 1.17.4 之前默认也是 on，更早版本不一定）。设置为 off 后，Nginx 不再对上游证书做任何信任链和域名校验。

nginx复制proxy_ssl_verify off;

需要注意的是，这个指令只影响 Nginx 作为客户端去连接上游时的行为，不影响 Nginx 作为服务器时对客户端证书的验证。如果你用的是双向 TLS（mTLS），那是另一套指令，别搞混。

4.2 proxy_ssl_server_name

这个指令控制是否启用 TLS 扩展中的 SNI。默认是 off（Nginx 版本不同默认不同，1.7.0 之后默认 off）。

nginx复制proxy_ssl_server_name on;
proxy_ssl_server_name off;

开启后，Nginx 会把 proxy_ssl_name 指定的域名（或 proxy_pass 中的域名）通过 SNI 发给上游。如果上游服务器的 HTTPS 配置里有多个虚拟主机证书，且需要通过 SNI 区分，那就必须开启。如果是 IP 直连、上游是单一证书的老服务，保持 off 更稳。

4.3 proxy_ssl_name

这个指令配合 proxy_ssl_server_name on 使用，用来指定 SNI 里携带的域名。默认值是 proxy_pass 中写的 hostname。

nginx复制proxy_ssl_name internal.service.example.com;

当 proxy_pass 里写的是 IP，而上游证书其实是签给一个域名的，你就可以显式指定这个域名，既能让 SNI 正确发送，又能在开启校验时让证书域名匹配通过。如果 proxy_ssl_verify 是 off，那么 proxy_ssl_name 对校验没有影响，但仍然会影响 SNI 的内容。

4.4 proxy_ssl_trusted_certificate

这个指令指定一个 PEM 格式的 CA 证书文件，用于在 proxy_ssl_verify on 时验证上游证书链。这个指令对"内网自建 CA 签发的证书"场景非常有用——它不是一个开关，而是一个信任锚点。

nginx复制proxy_ssl_trusted_certificate /etc/nginx/certs/internal-ca.crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

如果你只是要临时忽略校验，proxy_ssl_verify off 就够了。但如果是在一个长期稳定的内网环境里，我更推荐用 proxy_ssl_trusted_certificate 把内网 CA 导入信任链，这样既不用关闭校验，又能正常访问自签证书的上游服务。这个方案比一刀切地关掉校验要安全得多。

4.5 proxy_ssl_verify_depth

设置证书链校验的最大深度。默认值是 1，当你的上游证书链中间有多级 CA 时，可能需要调大。

nginx复制proxy_ssl_verify_depth 3;

这个参数本质上是一个细节参数，日常用 off 时不需要关心。但如果用了 on + trusted_certificate 的组合方案，证书链层级较深时，这里不调整会出现 certificate chain too long 的报错，很多人会栽在这个参数上。

这四个指令之间的关系可以用一个表格来说明：

5. 安全性讨论：什么时候可以关，什么时候绝不能关

每次教人配 proxy_ssl_verify off，我都必须强调风险，因为这个配置本质上是把 Nginx 对上游的 TLS 信任校验给禁掉了。它带来的风险是：如果有人在内网做了 ARP 欺骗、DNS 劫持或者路由劫持，把流量引到一个伪造的 HTTPS 服务器上，Nginx 完全无法察觉，因为你不校验证书了。敏感数据照样会发过去，TLS 加密形同虚设。

所以我的建议分几种情况：

测试环境、联调环境：放心关。

这种环境里所有服务都是临时的，数据也是测试数据，关掉校验完全不心疼。甚至可以说，不关才是给自己找麻烦。但关之前确认一点：你访问的确实是预期的服务器，而不是你根本不知道的某个旁路服务。

内网生产环境：优先用 trusted_certificate。

如果你的内网有自建 CA，最正规的做法是把内网 CA 证书导出来，放到 proxy_ssl_trusted_certificate 里，然后保持 proxy_ssl_verify on。这样既解决了信任问题，又保留了完整性校验。如果你的内网连自建 CA 都没有，那么退而求其次可以关掉校验，但要清楚这是临时方案，后续应该推动内网统一部署证书。

公网生产环境：绝对不能关。

公网环境里，正确做法是确保上游证书是由正规 CA 签发的（Let's Encrypt 也行），或者至少要正确配置证书链。如果公网环境里你还需要关掉 proxy_ssl_verify，那说明你的架构有问题，应该停下来解决证书问题，而不是绕过它。

另外还有一个我必须单独提醒的场景：如果 Nginx 后面还接了日志采集、监控告警、审计系统，关闭 TLS 校验可能不直接影响业务，但会让审计日志里的"连接是否安全"字段失去意义，安全团队会跳脚的。在这种环境里，哪怕只是内网，也尽量别图省事。

6. 更多避坑细节：stream 模块、403 和证书过期的"假死"现象

最后再补充几个实际使用中容易遇到的细节问题。

stream 模块下的配置差异

如果你用的是 Nginx 的 stream 模块（四层代理），也就是 stream {} 块里做 TCP/UDP 转发，针对 HTTPS 上游的指令名会变成 proxy_ssl_verify 前缀不变，但作用范围是针对 stream 上下文的。示例如下：

nginx复制stream {
    server {
        listen 8443;
        proxy_pass https://192.168.1.10:443;
        proxy_ssl_verify off;
    }
}

这里注意，stream 模块里的 proxy_ssl_server_name 默认是 off，如果你需要 SNI 也要手动开启。本质上和 http 模块的指令逻辑一致，只是上下文不同，容易记混。

403 不一定是证书问题

很多人一看到 403 就以为是证书问题，其实 403 是 HTTP 状态码，说明 TLS 握手已经成功了，是上游应用层拒绝了请求。证书校验失败一般表现是 502 或 504。所以遇到 403，先去查上游服务的访问控制配置、IP 白名单、认证头，别在 Nginx SSL 参数上死磕。

证书过期导致的"假死"

有时候上游证书上周还是好的，这周突然 502 了，日志里报 certificate has expired。这种场景下如果不想立即让后端换证书，用 proxy_ssl_verify off 确实能马上恢复。但我不建议这样做——因为证书过期往往意味着上游服务本身已经处于不健康状态，你应该通知对应负责人尽快更新证书，而不是让 Nginx 兜底。临时兜底 1 小时可以，兜底 1 个月就是给自己埋雷。

配置文件片段化管理

最后给一个普适的建议：把上游 SSL 相关的配置提取成独立的配置文件片段，方便在各 site 之间复用：

nginx复制# /etc/nginx/conf.d/ssl_upstream_common.conf
proxy_ssl_verify off;
proxy_ssl_server_name off;

然后在 server 或 location 里通过 include 引入：

nginx复制location /api/ {
    proxy_pass https://192.168.1.10:8443;
    include /etc/nginx/conf.d/ssl_upstream_common.conf;
}

这样做的好处是，当你需要从"忽略校验"切换到"正确校验"时，只需要改这一个文件，不用到处找散落的 proxy_ssl_verify off。

我再分享一个我实际维护环境的习惯：每次在上游证书即将到期前，我会先手动用 echo | openssl s_client -connect upstream:443 -servername your.domain.com 2>/dev/null | openssl x509 -noout -dates 查看证书有效期，提前规划是更新证书还是临时关闭校验。这个命令比配置 Nginx 更早发现风险，比任何监控都直接。