工具
使用 C 语言编写的全平台命令行换源工具，目标支持 Linux, Windows, macOS, BSD 等尽可能多的操作系统，龙芯、飞腾等尽可能多的 CPU。
公开提供 gem 源的服务
chsrc 共搜集 5 个公开可访问的 gem 源：
我们用该软件来测速：
chsrc cesu ruby
经过数十次测速，可以得出大概结论（我这里 (西安电信) 的测速情况）： ruby 源
- bfsu 最快，最稳定
- tencent 挺快，个别时候不稳定，能达到 4.5MB 左右
- tuna 有时快有时慢，不稳定，一般在 3MB 以下
- rubychina 有时快有时慢，快时一般在 2MB 以下，慢时一般在 1MB 以下
- 阿里云最不稳定，经常最慢
但是如上图所示，每次测试其实都不太一样，最好自己本地多试几次 chsrc cesu ruby
但是！这几个源都可用吗？
Ruby 的源并非都可用
记得 @huacnlee 以前在哪个帖子里说过，清华还是哪个源其实有问题。于是我用 gem install rails 挨个试了一遍，果真有问题。
北外，清华，阿里这三个源会循环遍历每个 gem 的每一个版本，导致安装时间拉长至 1 分 30 多。而只有腾讯和 RubyChina 的源没有这个问题。
所以我们把chsrc的 ruby 可用源只设定为这两个。
我们直接换源的同时测速
chsrc set ruby
我们实战试一下
以下图中我运行前，已经安装好所有 Rails 的依赖，所以不包含下载依赖的时间
使用腾讯源：
chsrc set ruby tencent
可以看到只花费了 6 秒
使用 Ruby China 源：
chsrc set ruby rubychina
可以看到花费了 20 秒
总结
测速还是跟地区有关，上述只是在我这里的实际情况。
最后依然要感谢 @huacnlee 等前辈对源的维护。 【日常零成本维护】
Edit
请务必自己测速，比如同在西安，mac 下测速：
Ruby China 的镜像，如果不考虑实时性，也可以快。
早期的时候就是国内其他 RubyGems 镜像那样的，后面发现不行，刚发布的 Gem 要等很久，要手动更新 CDN 等等。
于是就改了，让动态 API 请求直接以代理的方式回源到 rubygems.org 这样肯定实时，实际的 .gem 文件下载有国内 CDN 离线的缓存，那个肯定快的。你测试方法不对，只测试到了 API。受下载速度影响的主要是 .gem 文件，小的 1M，大的有几十 M。
所以大家记住，Ruby China 的 Gems 镜像就两个功能：
- 作为 RubyGem API 的代理，降低直连或其他代理容易被 DNS 污染问题（跟你开代理效果差不多），服务器对服务器，被墙影响概率低。
- 那些可以离线缓存的文件如（.gem 文件）做国内的 CDN 离线加速，提高访问下载速度，99.9% 的情况，这些文件都是国内服务器的。
此外，日常零成本维护，一般一年我都不用管它。
科大镜像站 https://mirrors.ustc.edu.cn/rubygems/ 现在也修正了「需要循环遍历每个每一个 gem 版本」的问题，观察 bundler -V 的输出，我们加上了 https://mirrors.ustc.edu.cn/rubygems/versions 这个文件，并且为它返回一个 Bundler 期望的 ETag header。
科大镜像站的 RubyGems 每天大约 6:50 AM 同步一次，服务器端的修改可以看第二个链接。详情参考 issues：
。已添加，见