Nginx应在边缘层终结TLS，Istio在网格层启用服务间mTLS；二者需明确分工：Nginx处理HTTPS入口、证书校验与重定向，Istio负责Pod间自动加密，避免重复终止与配置冲突。
在云原生架构中，Nginx 与 Service Mesh（如 Istio）共存时，SSL 终止的位置选择直接影响安全性、可观测性与运维复杂度。关键原则是：**避免重复终止，明确责任边界——通常由 Nginx 承担边缘 TLS 终结，Service Mesh 负责服务间 mTLS 加密**。
边缘层：Nginx 做 HTTPS 入口终结
这是最常见且推荐的分工方式。Nginx 部署在集群最外侧（如云负载均衡后或裸机边缘节点），直接面向公网，负责：
- 接收 443 端口 HTTPS 请求，完成 TLS 握手与解密
- 校验证书有效性（OCSP Stapling、证书链验证）
- 强制 HTTP → HTTPS 重定向（
return 301 https://$host$request_uri） - 将明文 HTTP/1.1 或 HTTP/2 流量转发至内部服务（或 Istio Ingress Gateway）
- 设置可信头：
proxy_set_header X-Forwarded-Proto $scheme、X-Real-IP，并用set_real_ip_from提取真实客户端 IP
网格层：Istio 管理服务间 mTLS
当流量进入集群后，应由 Istio 控制面统一启用服务间双向 TLS（mTLS），此时 Nginx 不再参与加密：
- Istio Sidecar 自动为 Pod 间通信加解密，无需应用修改代码
- Nginx 后端目标应设为内部服务域名（如
http://user-service.default.svc.cluster.local），走 plain HTTP - 确保 Istio 的
PeerAuthentication和DestinationRule启用 STRICT mTLS 模式 - 若需保留部分明文流量（如健康检查探针），可通过
PortLevelMtls精细控制
安全与可观测性协同要点
二者配合时，容易忽略的关键细节包括：
-
头信息净化：Nginx 必须清除客户端可能伪造的
X-Forwarded-For、X-Forwarded-Proto，仅信任来自内网固定段的转发头 -
协议标识传递：Nginx 转发时必须带
X-Forwarded-Proto: https，否则后端应用无法正确生成 HTTPS 链接（如 OAuth 回调地址） - 证书管理分离：Nginx 使用公信 CA 或私有 PKI 签发的边缘证书；Istio 使用 Citadel（或 Istiod 内置 CA）签发短期服务证书，两者生命周期与存储完全隔离
-
日志与追踪对齐：Nginx 记录原始 TLS 客户端 IP 和 SNI；Istio Sidecar 记录服务级调用链。两者通过
request_id或自定义 header 关联，形成端到端审计路径
不建议的混合模式
以下做法会引入冗余、故障点或安全隐患，应避免：
- Nginx 终结 TLS 后，再让 Istio Ingress Gateway 做二次 TLS 终结（性能损耗 + 配置复杂）
- 跳过 Nginx，直接让 Istio Ingress Gateway 对接公网并托管公信证书（暴露控制面、缺乏边缘防护能力）
- 在 Nginx 中配置 upstream HTTPS 并开启
proxy_ssl_verify on，同时又启用 Istio mTLS（双重加密无意义，且证书校验易冲突）
