关键在于构建环状+心跳探测的分布式TCP代理拓扑，通过逻辑ID注册、token校验、延迟感知路由及连接复用等机制实现可预测、低延迟、去单点的多机房内网穿透。

用TCP代理做多机房内网穿透，关键不是堆机器，而是让中继链路可预测、低延迟、不单点。核心思路是：每个机房部署一个轻量级TCP代理节点，通过统一调度策略把流量导向最优路径，避免全量镜像或盲目转发。

多节点TCP代理架构设计

不推荐“一主多从”星型结构——主节点一旦故障，全部中断。建议采用“环状+心跳探测”的分布式代理拓扑：

• 每台代理节点同时作为客户端和服务端：既监听本地内网服务（如192.168.10.5:3306），也主动连接相邻两个机房的代理节点（如连A机房和C机房）
• 所有节点定期上报延迟、带宽、连接数到中心协调器（可简化为Redis Pub/Sub或轻量HTTP API）
• 当某机房服务需被其他机房访问时，请求不直连目标，而是发给本地代理；该代理查实时路由表，选择延迟最低且负载未超阈值的下一跳节点中继

协议层优化降低中继开销

TCP代理默认逐包转发，多跳后易放大抖动。实际部署中应启用以下机制：

• 连接复用：对同一目标服务（如MySQL实例）的多个外网连接，复用代理节点到该服务的单条长连接，减少三次握手与TIME_WAIT堆积
• 缓冲区分级：设置小包直通（64KB加seq_id防乱序）
• 心跳保活不走业务端口：单独开一个低频TCP端口（如9999）跑纯ACK探测，避免业务连接因防火墙空闲断连

跨机房身份与路由控制

多个机房意味着网络策略不统一，必须在代理层解决权限和寻址问题：

• 每个内网服务注册唯一逻辑ID（如svc-mysql-prod-sh），而非IP+端口；代理启动时向中心注册ID、真实地址、标签（region=sh, env=prod）
• 外网访问请求携带目标ID和token；代理节点校验token有效性及调用方白名单（例如只允许北京机房调用上海MySQL）
• 支持路由策略表达式：比如“访问svc-redis-*优先走同城，若延迟>50ms则切到杭州节点”，规则热加载无需重启

典型部署示例（以FRP扩展模式为例）

原生FRP不支持多跳，但可通过嵌套配置模拟中继链路：

• 上海机房frpc配置：将本地MySQL映射为remote_port=6306，目标指向杭州frps
• 杭州frps开启dashboard，并作为客户端再连北京frps，把6306映射为新remote_port=7306
• 北京frps对外暴露7306，同时启用plugin=health_check自动剔除不可达的上游节点
• 最终效果：北京用户连beijing-frps-ip:7306 → 自动经杭州中继 → 到达上海MySQL，全程TCP透传无协议解析