今天（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 和镜像存储。

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

1. 不再需要持续运行全量同步任务，减少因为同步失败而产生的人工维护；
2. 新发布的 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 镜像由三个部分共同支撑：

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

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

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

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

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

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

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

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

十多年前，国内开发者直接访问 RubyGems.org 非常困难。

当时很多 Rails 项目仍然通过 Capistrano 将源代码发布到服务器，然后直接在生产服务器上执行 bundle install。生产服务器通常不会配置代理，因此一个能够直接访问的国内 RubyGems 镜像非常重要。

今天的开发和部署方式已经发生了很大变化。

Docker、CI/CD 和容器镜像已经成为常见的发布方式。项目依赖通常会在 CI 或镜像构建阶段提前安装，并打包进最终的发布产物，而不是每次部署时都在生产服务器上重新下载。

开发者访问 GitHub、海外云平台以及其他开发基础设施的方式也比十多年前更加丰富。在一个可控的 CI 或构建环境中直接使用 RubyGems.org，通常会是更简单、直接的方案。

包括我自己在实际项目中的经验，也是尽量直接使用官方源，并在 CI 或 Docker 构建阶段提前准备好依赖。

公共镜像曾经很好地解决了那个阶段的问题，但它在今天已经不像当年那样不可替代。

如何迁移

请检查本地开发环境、生产服务器、CI 配置和 Dockerfile 中，是否还在使用 Ruby China 镜像。

RubyGems

将 RubyGems Source 改回官方源：

gem sources --remove https://gems.ruby-china.com/
gem sources --add https://rubygems.org/
gem sources --list

Bundler

如果 Gemfile 中使用了 Ruby China 镜像：

source "https://gems.ruby-china.com"

请修改为：

source "https://rubygems.org"

如果配置过 Bundler Mirror，可以移除对应配置：

bundle config unset --global mirror.https://rubygems.org

也请检查项目目录中的 .bundle/config，以及 CI 环境中是否存在相关配置。

Ruby 安装包

Ruby 源代码和安装包请改用官方地址：

• Ruby 官方下载页面
• Ruby 官方源代码文件目录

使用 RVM、rbenv 或 ruby-build 的用户，也请检查是否配置过：

https://cache.ruby-china.com

并将相关配置移除或改回 Ruby 官方地址。

RVM

Ruby China 以前的安装文档曾建议通过下面的命令，将 RVM 下载 Ruby 源代码的地址切换到本站镜像：

echo "ruby_url=https://cache.ruby-china.com/pub/ruby" > ~/.rvm/user/db

如果曾经执行过这条命令，停服后再次运行 rvm install 安装新的 Ruby 版本时，下载可能会失败。已经通过 RVM 安装好的 Ruby 不受影响；这项配置也不影响 RubyGems 或 Bundler 下载 Gem。

可以先检查是否存在该配置：

grep '^ruby_url=' ~/.rvm/user/db

如果输出指向 cache.ruby-china.com，请编辑 ~/.rvm/user/db，删除对应的 ruby_url 配置，或者改为 Ruby 官方地址：

ruby_url=https://cache.ruby-lang.org/pub/ruby

请不要直接覆盖或删除整个 ~/.rvm/user/db，因为其中可能还保存了其他 RVM 自定义配置。

rbenv 与 ruby-build

如果使用 ruby-build，也请检查 Shell 配置、CI 环境变量和 Dockerfile 中是否设置过：

RUBY_BUILD_MIRROR_URL=https://cache.ruby-china.com

请移除该环境变量，让 ruby-build 恢复使用默认下载地址。如果安装过 rbenv-china-mirror 等镜像插件，也需要将其禁用或移除。

感谢

感谢阿里巴巴、腾讯云、又拍云在不同阶段为 Ruby China 镜像服务提供的服务器、CDN、存储和资金支持。

尤其感谢又拍云，多年来一直为 Ruby China 提供大量 CDN 和存储资源，这些镜像服务能够持续运行十多年，离不开他们的长期支持。

也感谢所有使用、反馈和帮助维护过这些服务的朋友。