Nginx无法对HTTPS流量“加密传输”而不终止TLS，因加密由客户端与后端直接完成；可行方案仅有TLS终止（解密转发）或TLS透传（SNI路由原样转发），后者保持后端协议不变但无法读取HTTP层内容。
不能实现“透明加密传输而不改变后端协议”——这个说法本身存在概念混淆。Nginx 无法在不终止 TLS 的前提下对 HTTPS 流量做“加密传输”，因为 HTTPS 的加密发生在客户端与目标服务器之间；若中间节点（如 Nginx）不参与 TLS 终止，它就只能透传原始加密 TCP 流，此时既不“加密”，也不“解密”，更谈不上“对流量加密”。真正可行的路径只有两种：TLS 终止（解密再发）或 TLS 透传（原样转发）。下面分情况说明核心逻辑和实操要点。
明确区分：TLS 终止 vs TLS 透传
这是理解所有配置的前提：
- TLS 终止（SSL 卸载）：Nginx 拿到客户端的 HTTPS 请求，用自己的证书私钥完成 TLS 握手、解密 HTTP 明文，再以 HTTP 或 HTTPS 转发给后端。此时后端收的是明文（HTTP）或新一层加密（HTTPS），协议可能改变。
- TLS 透传（SSL Passthrough）：Nginx 不解密，仅根据 Client Hello 中的 SNI 域名选择上游服务器，把整个加密 TCP 流原封不动转发过去。后端必须自己处理 TLS（即持有对应域名的证书并监听 443），协议完全不变，但 Nginx 无法读取或修改任何 HTTP 层内容（如 header、path、cookie）。
若目标是“不改变后端协议”，只能选 TLS 透传
这适用于后端已具备完整 HTTPS 能力（如另一台 Nginx、Apache 或云服务），你只需做四层路由：
- Nginx 必须启用
stream模块（编译时需含--with-stream）； - 配置中不能出现
http、ssl_certificate等 HTTP 层指令； - 典型配置片段如下：
stream {
upstream backend_example_com {
server 192.168.10.5:443;
}
upstream backend_api_com {
server 192.168.10.6:443;
}
map $ssl_preread_server_name $upstream {
example.com backend_example_com;
api.com backend_api_com;
default backend_example_com;
}
server {
listen 443;
ssl_preread on;
proxy_pass $upstream;
proxy_timeout 1s;
proxy_responses 1;
}
}
注意：$ssl_preread_server_name 依赖客户端发送 SNI，老旧客户端（如某些嵌入式设备）可能不支持，会导致匹配失败走 default。
若还需保留 HTTPS 到后端，TLS 终止后可再加一层 HTTPS
即：客户端 → Nginx（TLS 终止）→ 后端（HTTPS）。
- 前端 Nginx 配置自己的证书，解密请求；
- 用
proxy_pass https://backend/转发，此时需额外配置后端证书验证（如proxy_ssl_trusted_certificate）或跳过验证（仅测试）； - 后端仍运行 HTTPS 服务，协议未变，但多了一次加解密开销；
- 这种方式可配合
proxy_set_header注入真实 IP、X-Forwarded-Proto 等，功能更完整。
所谓“透明代理”不是免配置的魔法
真透明（如网关级拦截所有 443 流量并重定向）需要：
- Linux 内核开启
net.ipv4.ip_forward = 1； - iptables + TPROXY 规则将流量导向本地 stream 端口；
- Nginx 以 root 运行，并在 stream server 块中写
proxy_bind $server_addr transparent;； - 普通部署无需此步，仅适用于特定网络架构（如出口网关）。
