Nginx在透明代理模式下无法直接解密HTTPS流量，但可通过TPROXY+iptables+Nginx stream模块实现SSL Passthrough透传：基于SNI路由加密TCP流，不终止TLS，仅支持域名级转发，无法获取HTTP层信息。
在透明代理模式下，Nginx 本身不支持直接解密和转发原始 HTTPS 流量（即 TLS 握手前的 TCP 流量），因为它不是专门设计为 L4 层透明代理。但可通过组合系统级配置与 Nginx 的特定能力，实现“类透明代理”的 HTTPS 流量转发效果——核心在于：让客户端仍访问原始域名和端口（如 https://example.com），而流量经由中间节点（运行 Nginx 的机器）转发至上游服务器，且不修改客户端请求头或证书信任链。
前提：必须启用 Linux TPROXY + iptables/netfilter 重定向
真正的透明代理需内核支持 TPROXY（Transparent Proxy），它允许 Nginx 绑定到非本机 IP 或监听 0.0.0.0:443 同时获取原始目标地址（即客户端想访问的 example.com:443）。仅靠 Nginx 配置无法完成此步骤：
- 开启内核参数：
net.ipv4.ip_forward = 1和net.ipv4.conf.all.forwarding = 1 - 用 iptables 将入站 443 流量标记并重定向到本地 TPROXY 端口（如 10000）：
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 1iptables -t mangle -A PREROUTING -p tcp --dport 443 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 10000 - Nginx 必须以 root 运行，并在配置中启用
proxy_bind $server_addr transparent;
配置 Nginx 作为 TLS 透传代理（SSL Passthrough）
这是最贴近“透明 HTTPS 转发”的实用方式：Nginx 不终止 TLS，仅根据 SNI 字段（Client Hello 中的域名）选择上游服务器，将原始加密 TCP 流量转发过去。适用于反向代理多租户 HTTPS 服务：
- 使用
stream模块（需编译时启用--with-stream --with-stream_ssl_module --with-stream_ssl_preread_module） - 启用
ssl_preread on;提取 SNI - 用
map根据$ssl_preread_server_name匹配后端 IP/端口 - 示例配置片段：
stream {
map $ssl_preread_server_name $upstream_backend {
example.com 192.168.1.100:443;
api.example.org 192.168.1.101:443;
default 127.0.0.1:443;
}
upstream backend {
server $upstream_backend;
}
server {
listen 443;
ssl_preread on;
proxy_pass $upstream_backend;
proxy_timeout 1s;
proxy_responses 1;
}
}
注意事项与常见限制
- 无法记录 HTTP 层日志：因未解密，Nginx access_log 中只有连接信息（$remote_addr、$time_iso8601），无 URI、状态码等
- 不支持基于路径或 Header 的路由：SNI 只含域名，无法识别 /api/v1 这类路径
- 客户端证书不可见：若上游需要双向 TLS，Nginx 无法提取或验证客户端证书
- 健康检查困难：stream 模块的 upstream 健康检查仅支持 TCP 连通性，不能做 HTTP 状态探测
- 若需 HTTPS 终止+重加密（非透明），应改用
http块中的proxy_pass https://...，但这属于常规反向代理，非透明模式
替代方案建议
若业务需深度干预 HTTPS 流量（如内容过滤、Header 修改、WAF 功能），透明代理不是最优选。更可行的路径是：
- 部署中间人（MITM）代理（如 Squid + 自签名 CA，需客户端信任该 CA）
- 使用 eBPF 工具（如 Cilium、Envoy + Istio）在服务网格层面实现 L4/L7 透明拦截
- 在客户端侧配置显式代理（HTTP_PROXY/HTTPS_PROXY 环境变量或系统代理设置）
