记一次折腾：利用 Gost V3 解决国内服务器导致 Chrome 插件审核失败的问题

背景与痛点

Chrome 插件审核遇到了一个非常头疼的问题：我的后端 API 和业务网站统一部署在国内的一台服务器上。因为某些原因，这台服务器的 IP 被海外阻断了。这就导致 Google 官方的审核员在审核插件时，根本无法请求到后端数据，核心功能判定不可用，审核直接被拒。

摆在我面前的有几个选择：

1. 海外重新部署一套：太折腾，数据难以同步，两边维护代码极其痛苦。
2. 常规反向代理：买一台香港服务器，装 Nginx、配置 SSL，再通过各种内网穿透工具把国内的 80 端口映射出去。但这会带来一个致命问题：国内这边的业务还要正常服务国内用户，国内本地的 SSL 和强制 HTTPS 绝不能关。如果在香港再套一层 SSL，会导致无限的 301 重定向 死循环。

为了实现单边维护、完美兼容国内用户、且让香港中转站极致省资源，我摸索出了一套基于 Gost V3 + KCP 协议的无面板极简透传架构。

终极架构思路

抛弃复杂的七层 HTTP 反代，直接做纯粹的四层 TCP 数据流透传。让香港的服务器变成一个“没有任何感情的数据管道”。

Google 审核员 -> 香港 VPS 公网 443 端口 (由 Gost 直接接管) -> UDP KCP 加密隧道 -> 国内本地 Gost -> 国内 Nginx 443 端口 (本地处理 SSL 解密)

这套架构的三大核心优势：

1. 去 Nginx 化，极致省资源：香港服务器不需要装宝塔，不需要装 Nginx，只要有个 Docker 环境就行。买最便宜的 1核 512M 纯净系统 VPS 即可，内存占用不到 30MB。
2. 原汁原味的 SSL 握手：香港只负责搬运加密的数据包，所有的 SSL 证书解密、多域名 Host 路由识别，全部在国内服务器 Nginx 本地完成。国内用户直接访问，海外用户通过隧道访问国内，两者体验完全一致。
3. 抗 QoS 阻断：跨境 TCP 长连接很容易被运营商阻断（表现为 timeout 或连不上），我们将隧道的底层通信协议换成了基于 UDP 的 KCP 协议，抗丢包能力极强，速度起飞。

避坑指南：为什么不选 Gost V2 的 RTCP？

在最初的尝试中，我使用的是 Gost V2（ginuerzh/gost），试图通过 rtcp（反向 TCP）让国内去“控制”香港开启 443 端口。但这带来了无数的坑：

• 端口冲突：如果国内端用了 host 网络模式，rtcp 指令很容易让 Gost 误以为要在国内本地监听 443，直接和宝塔 Nginx 撞车报错 address already in use。
• 协议限制：服务端和客户端的 rtcp 监听指令如果不匹配，外网访问就会报 Connection refused 或者内部路由报 missing address。
• 内网穿透隔离：如果不使用 host 模式改用 bridge 桥接网络，Gost 容器又会被宿主机（宝塔）的防火墙拦截，报 dial tcp 172.17.0.1:443: i/o timeout。

最终的解法是：全面拥抱 Gost V3（gogost/gost），并将两边角色对调，改用正向 Relay 隧道！

完整落地教程

第一步：国内（源站）配置为服务端

国内的 Gost 负责开门接客，拿到数据后直接敲本地 127.0.0.1:443 的门。因为没有了抢占端口的问题，直接使用 network_mode: "host"，完美绕过本地 Docker 桥接网卡的防火墙拦截。

第二步：香港（中转站）配置为客户端

买一台海外纯净 VPS，装好 Docker。这台机器上的 Gost 负责霸占公网 443，然后无脑往隧道里塞数据。

第三步：启动与解析

最后，去你的域名注册商那里，把 Chrome 插件使用的域名，解析到香港服务器的 IP上。

总结

通过这一套折腾，业务代码一行没改，国内的服务器依旧是唯一的“真神”。海外流量走香港 UDP 隧道，国内流量直连。Chrome 审核员也能正常访问插件了，完美通关！