免费的Golang代理又要告别了？Hermes到期后，这3个替代方案更稳

最近不少开发者朋友都在群里抱怨，之前用的一个超级好用的免费Golang代理服务 mimo 突然“失联”了。用过的都知道，之前配合 Hermes 等节点，下载Go模块（go get）的速度简直起飞，完全不卡。

但对于大多数人来说，像 Hermese 这种“好梦”通常是短命的。一旦到期或者被封，瞬间就会从云端跌落谷底。我也刚经历了一次 Hermese 的到期，看着 go mod tidy 卡在 99% 不动，心里真的是一万个 不服。

那么，当所有的“白嫖”渠道都失效时，我们该怎么办？是继续寻找下一个“爆款”，还是自己动手丰衣足食？

为什么这些免费服务总是短命？

首先，我们要认清一个现实：免费的代理/镜像服务，本质上是个人或小团队用爱发电的结果。

1. 带宽成本高：Go 的服务下载量虽然不是巨大，但并发请求多，对小水管服务器压力极大。
2. 风控风险：涉及代理性质的服务，很容易触发云服务提供商的电文警告甚至封号。
3. 维护精力：没人愿意永远免费维护一个高负载的服务，尤其是当申请门槛提高（比如 mimo 现在很难通过审核）时，服务的质量也会随之下降。

所以,mimo 挂了不是终点，而是常态。下一个服务是谁？也许叫 Alice，也许叫 Bob，但它们的寿命都不会太长。

当前可用的替代方案（亲测有效）

既然不能只盯着一个“神”，那我们就得有几手准备。以下是目前社区反馈还比较稳定的几个方向：

方案一：转向更稳定的商业级国内镜像（最稳妥）

如果你追求稳定，不再想折腾，那么 Gitee Go Agent 或者 阿里云开发者平台提供的镜像 是目前的“正规军”。

• 优点：速度极快，国内访问无延迟，稳定，永不“失联”。
• 缺点对于某些被墙的特殊Go库（比如GitHub上的一些私有或敏感项目），它们可能无法拉取。

设置方法：

go env -w GOPROXY=https://goproxy.cn,direct

方案二：寻找小型社区维护的“长尾”服务

一些技术论坛和开源社区仍然在维护小型的Go代理。这些服务通常不会大肆宣传，但活得比较久因为负载较低。

• Go Module Proxy (GOPROXY): 可以尝试搜索最新的 goproxy.io 或是国内其他开源组织推送的镜像地址。很多高校的计算中心也提供免费的Go模块 proxy 服务，例如 goproxy.ustc.edu.cn (中科大)。
• 技巧：在 github.com 上搜索 golang proxy，按时间排序，找最近更新的 Repo，通常作者会在 README 里留下正在运行的服务地址。

方案三：自建 Go Module Proxy（终极方案，一劳永逸）

如果你有自己的海外小水管服务器，或者甚至是一台闲置的 Raspberry Pi，自己搭一个是最香的。虽然需要一点技术门槛，但完全可控。

步骤简述：

1. 使用 goproxy 官方提供的容器镜像，或者使用 athens 这样的开源模块代理服务器。
2. 容器化部署，只需不到5分钟。

你可以使用 goproxy 做前置代理，它将请求转发到 GitHub，或者你可以配置让它同时使用多个上游。

更高级的做法：使用 GitHub API Token 由于直接访问 raw.githubusercontent.com 经常被限流或封锁，自建代理时，可以在代理服务器上绑定一个 GitHub 的 Access Token。这样你的代理就拥有了一个“白名单”身份，且下载速度通常能解锁到更高带宽（1000 requests/hour vs 100 requests/hour），并且更稳定。

给开发者的建议：如何平滑过渡？

1. 不要依赖单一代理：在你的 Go 环境里，设置多个 GOPROXY 备胎。例如：

   go env -w GOPROXY=https://goproxy.cn,https://goproxy.ustc.edu.cn,direct
   

   这样，如果第一个挂了，Go 会自动尝试第二个，再失败才尝试直连。
2. 本地缓存是王道：养成在 CI/CD 流程中提前 go mod download 打包好的镜像或缓存的习惯，不要每次构建都实时从公网拉取。
3. 考虑 Docker 镜像预装：如果你的开发环境是容器化的，直接将编译好的依赖打入私有镜像仓库，彻底隔绝外网依赖。

结语

“mimo 无了”只是开发路上的一块小石头。 技术进步的同时，获取信息的渠道也在不断变化。与其纠结于下一个免费服务叫什么名字，不如掌握**“备份”和“自建”**的能力。毕竟，免费的羊毛是有限的，但技术的能力是无价的。

你在用哪个代理？也遇到了类似问题吗？欢迎在评论区一起交流你的解决方案！