从Unicorn迁移至Puma后随机启动失败：Ruby版本不匹配致503错误

我之前在从Unicorn切换到Puma时也碰到过几乎一模一样的问题，核心原因基本是旧Ruby版本的环境残留或者Bundler缓存未更新，导致部分Worker启动时误加载了旧版本的依赖路径，进而触发启动失败和SIGTERM终止信号。下面是我亲测有效的几个解决步骤：

1. 强制清理Bundler缓存并重新安装依赖 #

旧的Bundler缓存很可能还保留着Ruby 2.5.0时代的路径配置，即使你升级到了2.5.1，Worker启动时依然会读取旧缓存。执行以下命令彻底刷新依赖：

# 强制清理所有未在Gemfile.lock中指定的gem和缓存
bundle clean --force
# 重新安装依赖，确保绑定当前Ruby版本
bundle install

同时检查你的Gemfile顶部是否明确指定了正确的Ruby版本：

ruby '2.5.1'

这样Bundler会严格校验环境版本，避免加载不匹配的依赖。

2. 确保Puma启动时使用当前Bundle环境 #

很多时候问题出在启动命令没有通过bundle exec调用Puma，导致Worker脱离了当前的Ruby环境上下文。修改你的启动命令（比如Procfile或者启动脚本）：

# 正确的启动方式，确保Puma和Worker都使用bundle管理的Ruby版本
bundle exec puma -C config/puma.rb

另外检查config/puma.rb中是否有硬编码的路径或环境变量配置，比如env设置里有没有残留旧版本的GEM_PATH，如果有就删除或更新为当前环境的路径。

3. 清除环境变量和进程残留 #

部分Worker可能继承了旧的环境变量，导致加载错误的Ruby版本：

• 重启所有应用实例，彻底清除残留的旧进程和环境状态
• 验证当前环境变量的正确性，执行以下命令确认版本一致：

# 系统Ruby版本
ruby -v
# Bundler管理的Ruby版本
bundle exec ruby -v
# Puma的实际路径，应该指向2.5.1的bundle目录
which puma

如果bundle exec ruby -v输出的不是2.5.1，说明你的Bundle环境还没正确绑定当前Ruby版本，需要重新运行bundle install。

4. 调整Puma启动超时避免SIGTERM误判 #

报错里的SignalException: SIGTERM大概率是因为Worker启动超时被系统终止，而不是Worker本身的信号问题。你可以在config/puma.rb中增加启动超时时间：

# 给Worker足够的启动时间，默认可能较短
worker_timeout 30

等Worker能正常启动后，这个SIGTERM错误自然会消失。

内容的提问来源于stack exchange，提问作者F4Ke