Nginx多环境HTTPS反向代理关键在于按环境选用匹配证书（生产用公共CA、预发/测试用Let’s Encrypt或mkcert自签、开发用mkcert本地可信证书），严格分离证书路径与配置，精准设置ssl_certificate及proxy_ssl_verify，并通过nginx -t、openssl s_client和真实浏览器三步验证确保证书可信。
在 Nginx 中实现多环境（开发、测试、预发、生产）反向代理并保障 HTTPS 证书信任，关键不在“Nginx 输出证书”，而在于：不同环境使用匹配的证书类型、正确加载与验证链路、配合客户端/浏览器信任机制，并通过配置隔离避免混用。Nginx 本身不“输出”证书供用户主动下载，它只在 TLS 握手时按需提供证书链给客户端。运维重点是让每个环境的证书可被对应客户端无警告信任。
一、按环境选对证书类型与来源
不同环境对证书信任要求差异大，不能统一套用：
-
生产环境：必须使用公共 CA 签发的 DV/OV 证书（如 Let’s Encrypt、腾讯云 SSL），域名严格匹配
server_name，浏览器自动信任，无需人工干预。 -
预发/测试环境：若已有公网域名（如
test.example.com），仍推荐 Let’s Encrypt；若仅内网 IP 或私有域名（如test.internal），可用自签名证书 + 内部根证书分发方案（如 mkcert）。 - 本地开发环境（Windows/macOS）：强烈推荐 mkcert 工具生成本地可信证书。它会自动将自建根证书安装到系统信任库，Chrome/Firefox/Safari 均识别为有效，无需手动点击“继续访问”。
二、Nginx 配置中证书路径与链路要精准分离
多环境共存时，绝不能共用同一组证书文件。建议按环境划分目录结构，例如：
/etc/nginx/ssl/
├── prod/
│ ├── example.com.crt # 域名证书
│ ├── example.com.key # 私钥（chmod 600）
│ └── fullchain.pem # 域名证书 + 中间证书合并体
├── test/
│ ├── test.example.com.crt
│ ├── test.example.com.key
│ └── fullchain.pem
└── dev/
├── localhost.crt # mkcert 生成的 localhost 证书
└── localhost.key
对应 server 块中明确指定路径，避免混淆：
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/prod/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/prod/example.com.key;
# … 其他配置
}
三、反向代理场景下证书信任的两个关键点
Nginx 作为反向代理时，存在两层 HTTPS：客户端 ⇄ Nginx（需证书）、Nginx ⇄ 后端服务（可选 HTTPS）。证书信任问题主要出现在第一层：
-
客户端访问 Nginx 的 HTTPS 必须可信：即上文所述，Nginx 的
ssl_certificate必须由客户端信任的 CA 签发（或已导入根证书）。 -
Nginx 访问后端 HTTPS 时的证书校验（可选）：若后端也用 HTTPS（如
proxy_pass https://backend:8443），默认会校验后端证书。若后端是自签证书，需显式关闭校验（仅限测试环境）：proxy_ssl_verify off;proxy_ssl_trusted_certificate /etc/nginx/ssl/dev/ca-root.crt;（更安全的做法是把后端 CA 根证书放入 trusted_certificate 并保持 verify on）
四、自动化与验证：避免“以为配好了”
每次更换或新增环境证书后，务必执行三步验证：
-
语法检查：
nginx -t—— 确保配置无误，路径存在且权限正确（.key文件必须 root 可读）。 -
握手验证：用
openssl s_client -connect your-domain:443 -servername your-domain查看返回的证书信息、Verify return code 是否为 0（成功）。 - 真实终端访问：在目标环境的真实浏览器（非 curl）中打开，确认地址栏显示锁图标、无警告，点击证书可查看颁发者是否为你预期的 CA（如 R3、Let’s Encrypt、mkcert local CA）。
