前几天我在公司新装了一台 CentOS 虚拟机,准备给项目装一堆 Ruby gem,结果一执行 gem install bundler,页面立刻炸了:SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed。我一脸懵逼,心想这不就是网络问题吗?其实,真正的根源往往是「Gem 源」卡在了已经死掉的镜像上。
ruby.taobao.org 镜像已不再维护,SSL 证书失效。gem,导致写入 /usr/local 失败。https://rubygems.org,所以即使换了源也会卡住。我先打开终端敲了 gem sources -l,果然只剩下 https://ruby.taobao.org/,这就是灾难的根源。接下来,我把它踢出,顺手加上国内的 Ruby China 镜像:
gem sources --remove https://ruby.taobao.org/
gem sources --add https://gems.ruby-china.com/
gem sources -l # 再确认一下只剩下 ruby-china
如果你像我一样遇到「证书校验」的报错,先把 RubyGems 升级到 2.7 以上:
gem update --system
gem -v # 确认是 2.7.x 以上
升级完后,我再次尝试 gem install bundler,这回顺利跑通。但有时候即使源换了,仍然提示权限不足,这时只需要在命令前加个 sudo,或者把 ~/.gem 目录的所有者改成当前用户:
sudo gem install bundler
# 或者
chown -R $(whoami) ~/.gem
还有一种「隐形」的坑——公司网络的 HTTP 代理。gem env 能看到 HTTP_PROXY、HTTPS_PROXY 环境变量,如果它们指向了内部代理且代理不通 rubygems.org,就会卡死。解决办法是临时取消代理:
unset http_proxy https_proxy
gem install bundler
gem source -c 清空所有源,重新添加,防止残留的旧地址偷偷跑进来。~/.gemrc 写入 gem: --no-document,省去每次下载文档的时间。gem sources、gem update --system 自动化。说到底,Gem 源切换失败往往是「老旧镜像+旧版 RubyGems」的组合拳。只要把镜像搬到活跃的源、把 RubyGems 升级到新版本、确保网络或权限没拦路,后面的安装基本就是一键搞定。以后再碰到类似的 SSL 报错,我已经可以直接跑上面的几条命令,省得再去翻文档。
参与讨论
证书错误搞了我半天,原来要先升级gem系统啊🤔
公司代理真的坑,unset proxy才跑通,血泪教训
sudo都不加就直接装?新手别学他,权限问题迟早炸
gem -v 看了下才2.0,难怪死活连不上,升完立马行了
淘宝源早挂了,我上周还踩这坑,换了ruby-china秒好
~/.gemrc 加 --no-document 这招省了好多时间,666
为啥我加了ruby-china还是慢得要死?网络问题还是源的问题?
清源重配确实稳,之前残留的taobao地址偷偷作祟过hhh