HTTPS转TCP经TCP代理后再转回HTTPS的可行性咨询

你描述的通信链路完全可实现，不存在底层技术障碍。HTTPS本身就是承载在TCP之上的应用层协议，你提到的“七层HTTPS转四层TCP过代理再转回HTTPS”的表述，本质上不存在额外的协议转换动作——所有HTTPS报文从客户端发出时就已经封装在TCP段中传输，中间的四层代理仅需要根据IP、端口信息转发TCP字节流，不需要解析上层HTTPS内容，流量到达代理后端的HTTPS终结节点后，自然可以还原出完整的HTTPS请求，最终访问公网目标服务器。

这是非常成熟的业界通用架构，已经大规模落地多年，常见的落地场景包括：

• 入口层分层负载架构：中大型互联网服务的入口通常会先部署LVS、F5这类四层负载均衡（就是你说的TCP代理），先在TCP层面做大规模流量分发、流量清洗，再把流量转发给后端Nginx、Envoy这类七层反向代理集群，由七层网关和后端服务或者公网源站建立HTTPS连接处理业务逻辑，这套架构是目前绝大多数大型站点入口的标准部署方式。
• 跨网传输TCP优化场景：跨运营商、跨IDC、跨境访问的链路中，通常会部署TCP代理做传输优化（比如调整TCP拥塞控制参数、实现断连续传、降低链路丢包影响），这类代理仅处理TCP层传输逻辑，完全不触碰上层HTTPS内容，流量离开代理后即可正常发起HTTPS请求访问公网服务。
• 零信任安全接入场景：部分零信任接入点会先在TCP层面做设备身份校验、流量准入，校验通过后直接透传TCP字节流到后端HTTPS接入网关，全程不解密HTTPS内容，兼顾传输性能和数据安全性。

首先要纠正一个认知偏差：如果中间的TCP代理采用纯四层透传模式，根本不会读取或修改HTTPS报文内容，完全不存在“HTTPS七层信息丢失”的问题，所有七层信息（包括TLS握手参数、SNI、HTTP请求头、请求体、Cookie、客户端证书等）都会完整封装在TCP字节流中，只要代理不篡改TCP载荷，这些信息可以100%被后端还原。
只有当代理主动终结客户端TCP连接、自己作为客户端重新向后端发起HTTPS连接时，才可能出现七层信息丢失的问题，这类场景下也有成熟方案可以完整保留信息：

• 优先采用TCP透传模式：代理不终结客户端的TCP连接，仅做报文转发，让客户端直接和最终的HTTPS终结节点（公网源站或代理后端的七层网关）完成TLS握手，所有HTTPS内容全程不被代理解析或修改，是成本最低、信息保留最完整的方案。
• 必须在代理处终结TCP时，采用透明代理+字段透传配置：代理转发流量时保留原始客户端的源IP、源端口信息，同时配置规则将所有原始HTTPS头字段原样转发给后端，比如通过X-Forwarded-For、X-Forwarded-Proto这类标准头传递原始请求信息，TLS层的SNI、客户端证书等内容也可以通过代理的注入规则原样传递给后端，不会丢失核心七层信息。
• 需要基于HTTPS域名做路由但不想解密流量时，开启TLS透传（SSL Passthrough）模式：代理仅读取TCP握手阶段报文明文携带的SNI信息做路由决策，不解密后续TLS加密内容，所有加密的HTTPS报文直接透传给后端对应服务，七层信息不会有任何损耗。

内容的提问来源于stack exchange，提问作者Mze