可直接用tcp代理承载原生git流量，因其ssh/https均基于tcp，代理只需透传字节流；higress、nps或自研方案均可实现，需禁用连接池、关闭nagle算法、合理设超时，并支持认证、acl与审计。
可以直接用 TCP 代理承载原生 Git 流量，构建轻量、可控的研发中心代码网关。Git 的 git:// 协议（虽已逐步弃用）和更主流的 ssh://、https:// 方式中，SSH 和 HTTPS 本身都基于 TCP，而 Git over SSH 实质就是复用标准 SSH 端口（22）上的长连接隧道；Git over HTTPS 则走标准 443 端口 TLS 流量。因此，TCP 层代理不需解析 Git 协议内容，只需稳定透传字节流即可——这正是 TCP 代理最擅长的场景。
选择支持纯 TCP 转发的网关组件
优先选用对连接生命周期管理成熟、低延迟、高并发的 TCP 代理方案：
-
Higress：原生支持 Gateway API 的
TCPRoute，可监听 22 或自定义端口，将流量无修改转发至后端 Git 服务（如 Gitea、GitLab CE、或自建 bare repo + git-shell）。适合已接入 Kubernetes 体系的研发环境。 - NPX / nps（内网穿透工具）：轻量级、零依赖，支持多路复用和 TLS 加密中转。适用于无 K8s 的中小研发团队，能快速在公网服务器上暴露内网 Git 服务，同时隐藏真实 IP 和端口。
-
自研 Netty/Envoy 代理：若需深度控制（如连接鉴权、审计日志、IP 白名单、会话超时），可在 TCP 层注入简单协议识别逻辑（例如检测前几个字节是否为
git-upload-pack\0），再做路由或拦截。
关键配置要点：保持 Git 协议语义完整
Git 客户端（尤其是 SSH 模式）对连接稳定性、首包延迟、Keep-Alive 行为敏感。配置 TCP 代理时需注意：
- 禁用代理侧的连接池复用——Git SSH 连接是独占式、有状态的，不能像 HTTP 那样复用连接；
- 关闭 Nagle 算法（
TCP_NODELAY），避免小包合并导致命令响应卡顿； - 设置合理的空闲连接超时（如 30 分钟），既防资源堆积，也不中断长时间的
git clone； - 若走 HTTPS，确保代理终止 TLS 后仍透传 SNI 和 ALPN，以便后端 Git 服务（如 GitLab）正确路由到对应实例。
安全与管控增强建议
单纯透传不够，代码网关还需承担基础治理职责：
- 在 TCP 层前置一层轻量认证：例如用 nps 的
auth_key或 Higress 的ExtensionService插件校验请求来源 Token； - 结合 ACL 控制访问权限：限制某 IP 段仅能拉取（
git-upload-pack），禁止推送（git-receive-pack），靠解析初始握手字符串实现； - 记录原始客户端 IP 和操作类型（通过解析 Git 协议头），用于审计溯源；
- 对高危操作（如强制推送、删除远端分支）触发 Webhook 通知安全团队。
典型部署拓扑示例
研发中心内网部署 Gitea（监听 2222 端口），公网出口有一台带固定 IP 的 Linux 服务器：
- nps 服务端运行于公网机，监听 22 端口；
- nps 客户端部署在 Gitea 所在机器，反向连接公网服务端，并注册服务名
git-internal； - 研发人员克隆地址统一为：
ssh://git@public-ip:22/username/repo.git； - nps 自动将该连接转发至内网
Gitea:2222，全程透明，Git 客户端无感知。
