Nginx 无法将非加密 TCP 流量直接“转换”为 TLS，proxy_ssl 系列指令仅在 proxy_pass 指向 https:// 后端时生效；必须先配置 proxy_pass https://backend:443，再启用 proxy_ssl_on、proxy_ssl_trusted_certificate、proxy_ssl_verify 等指令协同工作，否则仍走 HTTP 或报 502 错误。
不能直接用 proxy_ssl 把非加密 TCP 流量“转换”成 TLS。这个指令本身不负责加解密，它只在 Nginx 已经作为 HTTPS 客户端发起上游连接时，控制如何与后端 TLS 服务交互。真正的加密发生在连接建立阶段，而起点必须是明确的 TLS 协议行为。
核心前提：你得先让 Nginx 主动发起 TLS 连接
proxy_ssl 系列指令（如 proxy_ssl_on、proxy_ssl_trusted_certificate）只在 proxy_pass 指向 https:// 地址时才生效。如果你写的是 proxy_pass http://backend:8080，Nginx 就走纯 HTTP，这些指令完全被忽略。
所以第一步不是配 proxy_ssl，而是把后端地址写成 HTTPS：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 确保后端服务实际监听在 HTTPS 端口（比如 443 或 8443），且已部署有效证书
- 在
location块中使用proxy_pass https://backend:443; - 此时 Nginx 才会尝试 TLS 握手，
proxy_ssl_*配置才有意义
启用并配置 proxy_ssl 的关键项
当 proxy_pass 指向 HTTPS 后端后，以下配置决定 TLS 连接是否能成功建立：
-
proxy_ssl on;—— 必须显式开启，否则即使写了 https://，Nginx 仍可能降级为 HTTP -
proxy_ssl_trusted_certificate—— 指定信任的 CA 证书文件路径；后端用公共 CA（如 Let's Encrypt）签发可省略；若为自签名或内网 CA，则必须提供 -
proxy_ssl_verify on;—— 启用证书校验（推荐生产环境开启）；若设为off，则跳过验证，存在中间人风险 -
proxy_ssl_protocols和proxy_ssl_ciphers—— 显式限定支持的协议版本和加密套件，避免协商出弱算法
常见失败原因与对应处理
配置完仍报 502 或日志显示 SSL connect error，大概率是以下情况之一：
- 后端服务没真正启用 HTTPS，只是开了 443 端口但跑的是 HTTP —— 用
openssl s_client -connect backend:443直连测试确认 -
proxy_ssl_trusted_certificate路径错误或权限不足（Nginx worker 进程需有读取权限） - 后端证书域名与
proxy_pass中写的主机名不匹配 —— 可临时加proxy_ssl_name "backend.example.com";指定 SNI 名 - 防火墙或安全组拦截了 Nginx 服务器 outbound 到后端 443 的连接
透明性不是由 proxy_ssl 决定的，而是由整体代理模式决定
所谓“透明转换”，实际是指客户端无感知：它发 HTTP 请求给 Nginx，Nginx 内部转成 HTTPS 去连后端。要实现这点，还需注意：
- 保持原始 Host 头：
proxy_set_header Host $host;或更稳妥的proxy_set_header Host $http_host; - 避免暴露代理痕迹：
proxy_hide_header X-Powered-By;、proxy_hide_header Server; - 如果后端依赖客户端真实 IP，别忘了
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
