要使Nginx真正校验后端HTTPS证书，必须同时配置proxy_ssl_verify on; proxy_ssl_trusted_certificate; proxy_ssl_name; proxy_ssl_server_name on;四条指令，并配以proxy_ssl_verify_depth、protocols和session_reuse等增强项。
要让 Nginx 真正校验后端 HTTPS 服务的 SSL 证书是否合规，不能只写 proxy_ssl_verify on; —— 这一行单独存在时，Nginx 会静默降级或直接返回 502 错误。必须在同一个 location 或 upstream 上下文中，配齐四个核心指令，并确保信任链和匹配逻辑正确。
必须同时配置的四项指令
proxy_ssl_verify on;
明确启用上游证书校验开关；默认是off，不开启等于完全不检查（哪怕证书已过期、域名错配、链断裂）。proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;
指向 PEM 格式的可信根证书文件；推荐使用系统级证书包（如/etc/ssl/certs/ca-certificates.crt）或 Mozilla 的cacert.pem；若后端用私有 CA 或自签名证书，需把其根证书内容追加进该文件。proxy_ssl_name "backend.example.com";
显式声明期望的后端域名，用于匹配证书中的 Subject Alternative Name（SAN）；当proxy_pass使用 IP 地址、变量（如https://$host）或泛域名时，此项不可省略，否则校验必然失败。proxy_ssl_server_name on;
启用 TLS SNI 扩展，确保 Nginx 在握手阶段向后端发送正确的域名；对接云服务（如阿里云 API）、多租户后端或泛域名证书时必需。
增强验证可靠性的补充配置
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
proxy_ssl_verify_depth 3;
默认只验 1 层（终端证书直连根 CA），但多数生产环境是三级链（终端 → 中间 CA → 根 CA），设为3更稳妥；值过小会导致“certificate verify failed”，过大则削弱安全性。proxy_ssl_protocols TLSv1.2 TLSv1.3;
明确禁用 TLSv1.0 和 TLSv1.1，防止协议降级干扰证书校验逻辑。proxy_ssl_session_reuse off;
关闭 TLS session 复用，避免缓存异常证书状态；开启时可能绕过重校验，导致失效证书被复用。
配置位置与权限要求
- 所有
proxy_ssl_*指令必须放在location或upstream块内，不能写在http或server全局块中，否则无效。 -
proxy_ssl_trusted_certificate所指文件需满足：- 路径正确，Nginx worker 进程（如
www-data或nginx用户）有读取权限； - 内容为纯 PEM 格式，每张证书以
-----BEGIN CERTIFICATE-----开头、-----END CERTIFICATE-----结尾； - 只含根 CA 和中间 CA 证书，不能混入私钥、终端证书或 fullchain.pem 中的服务器证书。
- 路径正确，Nginx worker 进程（如
快速验证是否生效
- 修改后执行
nginx -t检查语法，再nginx -s reload重载； - 发起请求，观察响应状态码和错误日志；
- 若仍报
SSL_do_handshake() failed或certificate verify failed，重点排查：- 后端是否返回完整证书链（可用
openssl s_client -connect backend:443 -servername backend.example.com查看Verify return code和证书输出行数）； -
proxy_ssl_name是否与证书 SAN 完全一致（注意大小写、通配符限制，*.example.com不匹配api.example.com）； -
proxy_ssl_trusted_certificate文件里是否真包含对应签发 CA。
- 后端是否返回完整证书链（可用
不复杂但容易忽略。
