今天（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，承担了这套镜像服务中很大一部分实际成本。正是因为有这种长期支持，镜像才得以持续运行十多年。
随着国内云服务市场逐渐成熟，厂商的社区合作和赞助策略也在发生变化。以前熟悉的合作渠道和联系人不断变动，重新沟通和申请赞助也变得越来越困难。
我们完全理解厂商在不同阶段需要调整自己的经营与合作策略，也非常感谢他们已经为 Ruby China 社区提供了这么多年的帮助。
综合这些因素，我们最终决定停止镜像服务。
回头来看，这套服务大致经历了三个主要阶段。
RubyGems 镜像最早可以追溯到 2011 年。
2011 年 11 月，我在社区介绍了 rubygems-mirror 和 geminabox，尝试寻找一种搭建 RubyGems 镜像的方式：
随后，淘宝内部提供了服务器和网络资源，ruby.taobao.org 正式上线：
当时的实现方式，是通过 rubygems-mirror 定期将 RubyGems.org 的数据同步到国内服务器，然后由国内的 Nginx 对外提供服务。
在当年的网络环境下，国内访问 RubyGems.org 非常困难。安装一个 Gem 经常需要等待很长时间，甚至会反复失败。ruby.taobao.org 的上线，解决了很多国内 Ruby 开发者安装依赖的问题。
这一阶段的服务器、网络以及相关费用，主要由淘宝和阿里巴巴提供。
但传统同步镜像的问题，不只是实时性。
同步任务需要持续、定期运行。同步过程中只要境外网络出现抖动、连接中断，或者上游的索引和文件发生异常，就可能导致同步失败、数据不完整，甚至整个镜像长时间停留在旧状态。
RubyGems 当时的镜像和索引生成机制本身也并不完善。将 .gem 文件下载到本地相对容易，但重新生成完整索引时，只要遇到一个格式不规范的旧 Gem，就可能导致整个过程失败。
同步失败后，通常还需要人工检查日志、重新执行任务、清理不完整文件，并确认索引与文件是否重新保持一致。
这套方案看起来比较直接，但实际运行起来需要持续关注。网络只要出现一次抖动，就可能需要人工介入，维护上需要投入不少时间。
同时，一个新的 Gem 版本发布以后，也必须等待下一轮同步完成才能从镜像中安装。如果同步任务刚好出现故障，新版本可能在较长时间里一直无法使用。
到了后期，随着维护人员的工作变动以及阿里内部服务器管理环境的变化，ruby.taobao.org 逐渐变得难以继续维护。
2016 年 3 月，我们宣布由 Ruby China 接手 RubyGems 镜像：
这一次，我们没有继续采用传统的定时全量同步，而是改成了一套基于 CDN 和实时回源的架构。
动态 API 和索引文件通过境外节点实时访问 RubyGems.org，可以长期缓存的 .gem 文件则进入国内 CDN 和镜像存储。
这套方案主要解决了两个问题：
实际安装过程中，RubyGems 会产生很多不同类型的请求。
其中 .gem 文件是静态文件，一旦某个版本发布，内容就不会再发生变化，因此可以长期缓存到国内 CDN。
但版本索引、API 以及部分元数据文件需要保持实时，无法简单地永久缓存。这部分请求仍然需要通过境外线路访问 RubyGems.org。
因此，这套方案本质上做了两件事情：
.gem 文件提供国内 CDN 加速。最初的实时镜像通过腾讯云 CDN 和境外服务器提供服务。随后，我们逐步将 .gem 文件迁移到又拍云的 CDN 和镜像存储中。
2016 年 5 月，镜像曾经因为缓存规则以及境外回源问题出现过一段时间的 502。当时的故障说明也记录了这套架构的具体工作方式：
问题解决后，当时 RubyGems 上的 60 多万个 .gem 文件被存储到又拍云的国内存储中。已经进入存储的文件不再需要回源，可以直接从国内 CDN 下载。
同年 4 月，我们又上线了 Ruby 官方安装包镜像：
这个服务通过又拍云 CDN 对 cache.ruby-lang.org 进行实时回源，并将访问过的 Ruby 源代码和安装包长期存储在国内。
它同样不需要定时同步：
在之后的很多年里，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
当年的公告：
这一次只是更换了服务域名，背后的架构没有发生变化。
又运行了几年以后，由于又拍云自身网络架构和境外回源线路的调整，动态请求的稳定性开始受到影响。
RubyGems 安装过程中，虽然体积较大的 .gem 文件可以从国内 CDN 获取，但 API、版本索引以及部分无法长期缓存的文件仍然需要实时回源。境外线路只要发生抖动，就可能导致一次 bundle install 失败。
为了改善这部分请求的稳定性，我们又将主要服务逐步迁移到腾讯云。
2023 年，我们对 RubyGems 镜像进行了最后一次比较大的架构调整：
最终的架构主要由以下几部分组成：
.gem 文件通过 302 跳转到 index.ruby-china.com；/versions 等常用索引文件通过腾讯云的预热机制定期更新；这套混合架构一直运行到今天。
2023 年，我在社区的回复里也再次说明过 Ruby China 镜像的设计方式：
简单来说，最后这套 RubyGems 镜像由三个部分共同支撑：
大多数时候，这套服务可以处于低维护状态，不需要频繁人工处理。但只要境外回源线路、CDN 缓存规则、SSL 证书或者账户费用出现变化，仍然需要人工介入。
2025 年 10 月，index.ruby-china.com 曾经因为又拍云境外回源异常，持续出现 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 Source 改回官方源：
gem sources --remove https://gems.ruby-china.com/
gem sources --add https://rubygems.org/
gem sources --list
如果 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 源代码和安装包请改用官方地址：
使用 RVM、rbenv 或 ruby-build 的用户，也请检查是否配置过：
https://cache.ruby-china.com
并将相关配置移除或改回 Ruby 官方地址。
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 自定义配置。
如果使用 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 和存储资源，这些镜像服务能够持续运行十多年，离不开他们的长期支持。
也感谢所有使用、反馈和帮助维护过这些服务的朋友。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。