今天（2026 年 7 月 21 日），Ruby China 正式停止以下镜像服务：

gems.ruby-china.com：RubyGems 镜像
cache.ruby-china.com：Ruby 源代码及安装包镜像
index.ruby-china.com：RubyGems 静态文件服务 (备用)

这些服务已经运行了十多年。

我们做出这个决定，主要还是因为费用以及长期赞助的问题。

为什么停止服务

Ruby China 的镜像一直是一项完全免费、面向所有人的公共服务。

这些年来，镜像能够持续运行，主要依赖阿里巴巴、腾讯云、又拍云等厂商在不同阶段提供的服务器、CDN 和网络资源，以及 Ruby China 社区自身承担的一部分费用。

Ruby China 本身没有稳定的商业收入。社区经费主要来自厂商赞助以及历届 RubyConf China 活动结束后剩余的少量资金。

最近一年，我们陆续向腾讯云账户充值了大约 6000 元。目前腾讯云部分平均每月产生四五百元费用，但这是在已经设置流量限制的情况下产生的，也并不是整套镜像服务的全部成本。

RubyGems 的大量静态文件以及 Ruby 安装包的流量，长期以来仍然由又拍云提供资源支持。如果把这一部分实际消耗的 CDN 和存储费用也计算进去，整体成本会高出很多。

这类公共镜像服务还有一个比较麻烦的问题：费用不是固定的。

镜像的费用主要根据流量计算，而公开服务的流量很难准确预测。

这些年来，我们经常会遇到一些程序持续下载大量文件、企业内部做全量镜像、基于本站再次搭建二次镜像，以及其他异常请求。有些单个 IP 每天就会产生几十 GB，甚至上百 GB 的流量。

以前我也曾经在很长一段时间里，经常检查每日流量，将消耗异常的 IP 手工封禁。但这些请求的来源和 IP 随时会发生变化，不可能完全依靠人工处理。

如果不设置限制，一次异常流量就可能在很短时间内产生上千元费用。因此，最近我们不得不为 CDN 增加单日流量封顶限制。当流量达到限制后，服务会被自动关闭。

今年社区中出现的 418、证书错误以及服务无法访问，部分也是因为触发了这套流量限制：

Ruby China Gems 变茶壶了

所以，这个问题并不只是再去找几千元赞助就能够解决。

理论上，我们仍然可以继续联系厂商，尝试申请新的赞助。但对于一个按照流量计费、费用可能随时发生较大变化的公共服务，我们很难准确判断一年究竟需要申请多少预算，也很难让赞助方长期承担一项没有明确费用边界的服务。

过去很多年里，又拍云以不计流量费用的方式支持 Ruby China，承担了这套镜像服务中很大一部分实际成本。正是因为有这种长期支持，镜像才得以持续运行十多年。

随着国内云服务市场逐渐成熟，厂商的社区合作和赞助策略也在发生变化。以前熟悉的合作渠道和联系人不断变动，重新沟通和申请赞助也变得越来越困难。

我们完全理解厂商在不同阶段需要调整自己的经营与合作策略，也非常感谢他们已经为 Ruby China 社区提供了这么多年的帮助。

综合这些因素，我们最终决定停止镜像服务。

Ruby China 镜像服务的历史

回头来看，这套服务大致经历了三个主要阶段。

第一阶段：ruby.taobao.org

RubyGems 镜像最早可以追溯到 2011 年。

2011 年 11 月，我在社区介绍了 rubygems-mirror 和 geminabox，尝试寻找一种搭建 RubyGems 镜像的方式：

有想搞 Rubygems 镜像的可以试试 rubygems-mirror 和 geminabox

随后，淘宝内部提供了服务器和网络资源，ruby.taobao.org 正式上线：

现在起，改用国内镜像服务器来装 Gem 吧

当时的实现方式，是通过 rubygems-mirror 定期将 RubyGems.org 的数据同步到国内服务器，然后由国内的 Nginx 对外提供服务。

在当年的网络环境下，国内访问 RubyGems.org 非常困难。安装一个 Gem 经常需要等待很长时间，甚至会反复失败。ruby.taobao.org 的上线，解决了很多国内 Ruby 开发者安装依赖的问题。

这一阶段的服务器、网络以及相关费用，主要由淘宝和阿里巴巴提供。

但传统同步镜像的问题，不只是实时性。

同步任务需要持续、定期运行。同步过程中只要境外网络出现抖动、连接中断，或者上游的索引和文件发生异常，就可能导致同步失败、数据不完整，甚至整个镜像长时间停留在旧状态。

RubyGems 当时的镜像和索引生成机制本身也并不完善。将 .gem 文件下载到本地相对容易，但重新生成完整索引时，只要遇到一个格式不规范的旧 Gem，就可能导致整个过程失败。

同步失败后，通常还需要人工检查日志、重新执行任务、清理不完整文件，并确认索引与文件是否重新保持一致。

这套方案看起来比较直接，但实际运行起来需要持续关注。网络只要出现一次抖动，就可能需要人工介入，维护上需要投入不少时间。

同时，一个新的 Gem 版本发布以后，也必须等待下一轮同步完成才能从镜像中安装。如果同步任务刚好出现故障，新版本可能在较长时间里一直无法使用。

到了后期，随着维护人员的工作变动以及阿里内部服务器管理环境的变化，ruby.taobao.org 逐渐变得难以继续维护。

第二阶段：迁移到 Ruby China，改用实时回源

2016 年 3 月，我们宣布由 Ruby China 接手 RubyGems 镜像：

Ruby China 的 RubyGems 镜像上线

这一次，我们没有继续采用传统的定时全量同步，而是改成了一套基于 CDN 和实时回源的架构。

动态 API 和索引文件通过境外节点实时访问 RubyGems.org，可以长期缓存的 .gem 文件则进入国内 CDN 和镜像存储。

这套方案主要解决了两个问题：

不再需要持续运行全量同步任务，减少因为同步失败而产生的人工维护；
新发布的 Gem 不需要等待下一轮同步，可以立即通过镜像获取。

实际安装过程中，RubyGems 会产生很多不同类型的请求。

其中 .gem 文件是静态文件，一旦某个版本发布，内容就不会再发生变化，因此可以长期缓存到国内 CDN。

但版本索引、API 以及部分元数据文件需要保持实时，无法简单地永久缓存。这部分请求仍然需要通过境外线路访问 RubyGems.org。

因此，这套方案本质上做了两件事情：

为 RubyGems 的动态 API 和索引请求提供实时代理；
为可以长期缓存的 .gem 文件提供国内 CDN 加速。

最初的实时镜像通过腾讯云 CDN 和境外服务器提供服务。随后，我们逐步将 .gem 文件迁移到又拍云的 CDN 和镜像存储中。

2016 年 5 月，镜像曾经因为缓存规则以及境外回源问题出现过一段时间的 502。当时的故障说明也记录了这套架构的具体工作方式：

gems.ruby-china.org 最近两天 Bad Gateway 502 的问题

问题解决后，当时 RubyGems 上的 60 多万个 .gem 文件被存储到又拍云的国内存储中。已经进入存储的文件不再需要回源，可以直接从国内 CDN 下载。

同年 4 月，我们又上线了 Ruby 官方安装包镜像：

上线 Ruby 安装包镜像 - cache.ruby-china.org

这个服务通过又拍云 CDN 对 cache.ruby-lang.org 进行实时回源，并将访问过的 Ruby 源代码和安装包长期存储在国内。

它同样不需要定时同步：

Ruby 官方发布新版本后可以立即获取；
不需要人工运行同步任务；
Ruby 源代码和安装包通过国内 CDN 下载；
RVM、rbenv 和 ruby-build 都可以使用。

在之后的很多年里，cache.ruby-china.com 一直是国内开发者安装 Ruby 时常用的下载地址。

2018 年，由于 .org 域名无法备案，两个镜像域名从 .org 更换为 .com：

gems.ruby-china.org → gems.ruby-china.com
cache.ruby-china.org → cache.ruby-china.com

当年的公告：

Ruby China 镜像域名变化

这一次只是更换了服务域名，背后的架构没有发生变化。

第三阶段：腾讯云与又拍云的混合架构

又运行了几年以后，由于又拍云自身网络架构和境外回源线路的调整，动态请求的稳定性开始受到影响。

RubyGems 安装过程中，虽然体积较大的 .gem 文件可以从国内 CDN 获取，但 API、版本索引以及部分无法长期缓存的文件仍然需要实时回源。境外线路只要发生抖动，就可能导致一次 bundle install 失败。

为了改善这部分请求的稳定性，我们又将主要服务逐步迁移到腾讯云。

2023 年，我们对 RubyGems 镜像进行了最后一次比较大的架构调整：

Ruby China Gems 镜像变更公告

最终的架构主要由以下几部分组成：

动态 API 请求通过腾讯云境外 CDN 节点回源到 RubyGems.org；
可以长期缓存的 .gem 文件通过 302 跳转到 index.ruby-china.com；
静态文件继续通过又拍云国内 CDN 下载；
/versions 等常用索引文件通过腾讯云的预热机制定期更新；
又拍云上原有的服务继续作为备用线路；
后来又增加了全球 CDN 节点，减少国内网络直连香港时可能出现的丢包问题。

这套混合架构一直运行到今天。

2023 年，我在社区的回复里也再次说明过 Ruby China 镜像的设计方式：

镜像站速度哪家强？Ruby 的源到底有哪些可用？

简单来说，最后这套 RubyGems 镜像由三个部分共同支撑：

腾讯云 CDN 负责动态 API 和索引请求；
又拍云 CDN 和存储负责大量静态文件；
Ruby China 社区经费负责腾讯云动态回源部分产生的费用。

大多数时候，这套服务可以处于低维护状态，不需要频繁人工处理。但只要境外回源线路、CDN 缓存规则、SSL 证书或者账户费用出现变化，仍然需要人工介入。

2025 年 10 月，index.ruby-china.com 曾经因为又拍云境外回源异常，持续出现 503：

index.ruby-china.com/gems 的相关 Gem 开始报 503

当时经过临时调整后恢复了服务，但这也再次说明，实时回源方案仍然依赖云厂商跨境网络的稳定性。

到了 2026 年，腾讯云 CDN 又开始出现明显的异常流量。为了避免账户余额在短时间内被大量消耗，我们不得不增加单日流量封顶限制。

随着又拍云长期社区赞助政策发生变化，这套由腾讯云、又拍云和 Ruby China 社区经费共同维持的架构，也无法再按照过去的方式继续运行。

为什么今天不再那么依赖公共镜像

十多年前，国内开发者直接访问 RubyGems.org...

Ruby China

Message History

Delivery option(s)