Nginx在location中校验后端HTTPS安全性需同时配置四个核心指令：proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name、proxy_ssl_server_name，缺一不可且必须同处一个location块内。
要让 Nginx 在 location 块中真正校验后端 HTTPS 服务的安全性，关键不是只写 proxy_ssl_verify on，而是构建一套完整、闭环的 TLS 验证机制。它必须同时满足四个硬性条件，否则会静默失败或直接返回 502。
必须配齐的四个核心指令
这四项必须全部写在同一个 location 块内，缺一不可，顺序无关，但作用域不能跨出该块：
-
proxy_ssl_verify on;—— 显式开启校验开关；默认是off，不写等于完全不检查证书是否过期、是否被吊销、是否域名错配 -
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;—— 指向 PEM 格式的可信 CA 文件；内容只能是根证书和中间 CA（不含私钥、不含后端终端证书），支持多个证书拼接 -
proxy_ssl_name "backend.internal.company.com";—— 显式声明期望匹配的主机名；用于比对后端证书中的 SAN 字段；若proxy_pass写的是 IP（如https://10.0.1.5）或变量（如https://$host），此项不设则校验必然失败 -
proxy_ssl_server_name on;—— 启用 TLS SNI 扩展；确保 Nginx 握手时发送正确的域名，避免后端返回默认证书（比如泛域名或自签名证书）
常见配置陷阱与规避方式
很多配置看似正确，却仍报 SSL_do_handshake() failed 或 certificate verify failed，问题往往出在细节：
- 信任证书路径不可读：确认 Nginx 工作进程（如
www-data或nginx用户）有权限读取proxy_ssl_trusted_certificate指定的文件 - 证书链不完整：用
openssl s_client -connect backend:443 -servername backend.internal.company.com观察返回的证书块数量；少于 2 个说明后端没返回中间 CA，需补进ca-bundle.crt中 - 域名匹配失效：后端证书若只含
DNS:backend.internal.company.com，但proxy_ssl_name写成backend.company.com，校验即失败；IP 地址不能替代 DNS 名参与 SAN 匹配 - 指令位置错误：写在
http或server块顶层无效，必须嵌套在location或upstream内部
增强安全性的可选配置项
基础四指令跑通后，建议追加以下几项提升鲁棒性和合规性：
-
proxy_ssl_verify_depth 2;—— 默认只验证深度为 1（终端直连根 CA），多数私有 PKI 是三级链（终端 → 中间 CA → 根 CA），设为2或3更稳妥 -
proxy_ssl_protocols TLSv1.2 TLSv1.3;—— 明确禁用 TLSv1.0/TLSv1.1，防止协议降级攻击 -
proxy_ssl_session_reuse off;—— 关闭会话复用，避免因缓存旧会话绕过证书重校验（适合高敏感场景）
一个可用的典型 location 示例
以下配置适用于企业内网调用带私有 CA 签发证书的后端服务：
location /api/ {
proxy_pass https://10.0.1.5:443/;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/nginx/ssl/internal-ca.pem;
proxy_ssl_verify_depth 2;
proxy_ssl_name "api.internal.company.com";
proxy_ssl_server_name on;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
}
只要后端证书由 internal-ca.pem 中的 CA 签发、SAN 包含指定域名、且支持 SNI，该配置就能完成端到端的证书有效性校验。
