HTTPS代理中Nginx不支持直接解密流量，必须通过TLS终止（SSL卸载）实现解密转发，即配置证书私钥并以明文HTTP/HTTPS向后端转发；TLS透传则无法修改内容。
HTTPS代理本身不支持直接解密流量（即“SSL解密”），因为Nginx作为反向代理默认只做TLS终止或透传，不能在不解密的前提下修改或查看原始HTTP内容。若需实现“解密后转发”，必须由Nginx主动终止TLS（即做SSL卸载），再以明文HTTP/HTTPS向后端转发——这要求你持有并配置服务端证书和私钥，且客户端信任该证书。
一、Nginx作为TLS终止代理（推荐常规方案）
这是最常见、最安全的HTTPS代理模式：Nginx接收客户端HTTPS请求，用自己的证书解密，再以HTTP或HTTPS转发给上游服务。
- 需准备域名对应的有效证书（如
example.com.crt）和私钥（example.com.key），可为自签名（仅测试用）或由Let’s Encrypt签发 - 在server块中启用
ssl on（旧版本）或直接使用listen 443 ssl（推荐1.15+） - 指定证书路径：
ssl_certificate和ssl_certificate_key - 建议启用现代TLS配置（如TLSv1.2+、strong ciphers、HSTS）提升安全性
二、Nginx配置示例（HTTPS → HTTP后端）
适用于后端服务本身不处理HTTPS（如本地运行的Flask/FastAPI/Node.js）：
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
三、Nginx配置示例（HTTPS → HTTPS后端，即双TLS）
若后端也要求HTTPS（如另一台带证书的API服务器），Nginx不参与解密，仅做TLS透传代理——此时无法修改请求头或做内容级控制，但能保持端到端加密：
- 使用
proxy_ssl_*指令配置上游TLS参数（如验证后端证书） - 关键配置包括：
proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_protocols - 注意：
proxy_pass https://...后必须确保后端域名与证书匹配，否则连接失败
四、关于“中间人式解密转发”的重要提醒
Nginx原生不支持像Fiddler或mitmproxy那样的主动中间人（MITM）解密——它无法动态生成并签发针对任意目标域名的证书，也无法拦截并重写SNI或ClientHello。强行实现需额外工具链（如配合openssl自建CA + 客户端强制信任 + 自定义TLS握手代理），已超出Nginx职责范围，且存在法律与安全风险（尤其在生产环境未经明确授权时）。
如确有深度检测或审计需求，应评估专用SSL/TLS代理网关（如Traefik with forward auth、Envoy with TLS inspector）或应用层日志/埋点方案，而非改造Nginx做协议层解密。
