Nginx在Service Mesh中不参与mTLS数据面治理，而是作为边缘入口执行SSL卸载，并通过透传X-Forwarded-Proto、X-Real-IP等头部与网格互信，兼顾边界防护与零信任内网通信。
在云原生 Service Mesh 架构中，Nginx 并不直接作为数据面组件参与服务间 mTLS 流量治理——那是 Envoy（Istio 默认 Sidecar）的职责。但 Nginx 仍可承担边缘入口（Ingress）或 API 网关角色，对进入集群的外部 HTTPS 流量执行 SSL 卸载，并与内部 Service Mesh 实现安全互信。这种分层设计兼顾了边界防护能力与网格内零信任通信。
SSL 卸载：Nginx 作为 TLS 终止点
Nginx 在 Service Mesh 前置部署时，负责终结来自公网的 HTTPS 连接：
- 客户端与 Nginx 建立完整 TLS 握手（含证书校验、密钥交换），流量全程加密
- Nginx 解密请求后，以明文 HTTP 或内部可信协议（如 HTTP/1.1 或 gRPC）转发至网格入口（如 Istio Ingress Gateway 或后端服务）
- 卸载后，后端无需处理 TLS 计算，节省 CPU 资源，尤其利于资源受限的容器化服务
- 配置需启用 ssl_protocols TLSv1.2 TLSv1.3、禁用弱加密套件，并开启会话复用（ssl_session_cache）提升吞吐
与 Service Mesh 的互信衔接方式
Nginx 卸载 SSL 后，需确保转发请求被网格正确识别和信任：
- 透传原始协议信息：设置 proxy_set_header X-Forwarded-Proto $scheme，让后端判断是否来自 HTTPS
- 保留真实客户端身份：通过 X-Real-IP 和 X-Forwarded-For 头传递源 IP，供网格策略（如 RBAC）或可观测性使用
- 注入可信标识：可在 Nginx 层添加自定义头（如 X-Edge-Auth: verified），配合网格网关做二次鉴权
- 若需网格内也走 mTLS，Nginx 到 Ingress Gateway 之间应走受信网络（如 VPC 内网），并由 Istio 自动签发和轮换证书，无需 Nginx 参与密钥管理
避免常见信任断裂问题
卸载不当会导致身份丢失、协议误判或安全降级：
- 不配置 proxy_set_header Host $host → 后端无法匹配虚拟主机，返回 404 或错误重定向
- 未设 X-Forwarded-Proto → 应用生成的跳转链接可能为 http://，引发混合内容警告或登录失败
- 关闭 ssl_verify_client off 但未在上游启用双向认证 → 外部客户端证书无法传递给网格做细粒度授权
- 证书路径配置错误或私钥权限过高（如非 root 可读）→ Nginx 启动失败，TLS 终止中断
对比原生 Istio Ingress Gateway 的定位差异
虽然 Istio 提供了内置的 Ingress Gateway（基于 Envoy），但 Nginx 仍有其适用场景：
- 已有成熟 Nginx 运维体系，需复用现有 WAF、限流、日志格式等配置
- 需要支持非 HTTP 协议（如 WebSocket、gRPC-Web）或复杂 rewrite 规则，Envoy 配置相对受限
- 对 TLS 卸载有定制需求（如国密 SM2/SM4 支持，需集成 tassl 引擎）
- 作为多租户网关，按域名或路径将流量路由到不同 Istio 控制平面实例
