nginx 代理 https 后端必须启用证书校验，关键配置是 proxy_ssl_verify on、proxy_ssl_trusted_certificate 指向可信 ca 文件、proxy_ssl_verify_depth 设为 2 或 3、proxy_ssl_protocols 限定 tlsv1.2+，并确保 proxy_ssl_name 与后端证书 san 严格匹配，所有指令须在 location 或 upstream 块内生效。
Nginx 使用 proxy_pass 转发到 HTTPS 后端时，要实现安全可靠的证书处理，关键不是“让 Nginx 自己签发证书”，而是正确验证后端 HTTPS 服务的证书真实性，防止中间人攻击。这属于“Nginx → 后端 HTTPS 服务”的 TLS 链路加固，和 Nginx 对外提供 HTTPS（客户端 → Nginx）是两个独立环节。
HTTPS 后端代理必须开启证书校验
生产环境绝不能关闭验证（如 proxy_ssl_verify off），否则所有加密形同虚设：
-
proxy_ssl_verify on;—— 强制启用上游证书验证 -
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;—— 指定可信根证书文件（含后端服务所用 CA 的公钥） -
proxy_ssl_verify_depth 2;—— 允许证书链最多 2 级（根 CA → 中间 CA → 服务器证书） -
proxy_ssl_protocols TLSv1.2 TLSv1.3;—— 明确限制协议版本，禁用不安全旧版
⚠️ 注意：如果后端用的是自签名证书或私有 CA 签发的证书，必须把该 CA 的
.crt文件内容追加进proxy_ssl_trusted_certificate所指文件中，不能只依赖系统默认 CA 存储。
WeChat macOS Proxy下载macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
正确配置 proxy_pass 地址与 Host 匹配
Nginx 校验证书时会检查证书中的 Subject Alternative Name (SAN) 是否匹配请求域名：
-
proxy_pass https://api.internal.example.com:8443/; - 必须确保
api.internal.example.com出现在后端证书的 SAN 列表里 - 若用 IP 直连（如
https://10.0.1.5:8443/），证书必须包含该 IP 地址在 SAN 中（普通域名证书不支持 IP） - 不推荐写
localhost或127.0.0.1，多数证书不为此签发，易触发验证失败
必传请求头与连接健壮性设置
保障后端能正确识别原始请求来源和协议：
-
proxy_set_header Host $host;—— 传递原始 Host，避免后端路由错乱 -
proxy_set_header X-Forwarded-Proto $scheme;—— 告诉后端这是 HTTPS 请求（影响重定向、URL 生成等逻辑） -
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For $proxy_add_x_forwarded_for;—— 保留真实客户端 IP - 调整超时以适应 TLS 握手开销：
-
proxy_connect_timeout 60s; -
proxy_read_timeout 120s; -
proxy_send_timeout 120s;
-
常见错误与对应解法
-
502 Bad Gateway + SSL handshake failed
→ 检查proxy_ssl_trusted_certificate路径是否可读、内容是否完整、是否包含后端 CA -
SSL certificate verify failed
→ 用openssl s_client -connect api.internal.example.com:8443 -CAfile /path/to/ca-bundle.crt手动测试验证链 -
ERR_SSL_PROTOCOL_ERROR（Nginx 报）
→ 确认proxy_pass地址协议写对了https://，且后端确实在监听 HTTPS（不是 HTTP）
不复杂但容易忽略
