如何在DigitalOcean上不重启服务器重启Rails应用并应对异常攻击

一、Rails 7.1.2生产日志不输出的修复 #

Rails 7.1对日志系统做了默认配置调整，仅修改log_level后部署不生效，大概率是旧Puma进程未加载新配置，或权限/路径配置缺失：

• 明确配置日志路径与级别，在config/environments/production.rb中补充：

  config.log_level = :warn
  config.logger = ActiveSupport::Logger.new(Rails.root.join('log', "production.log"), shift_age: 'daily')
  

• 检查部署目录下log文件夹权限，确保Puma运行用户（通常是deploy）有读写权限：

  sudo chown -R deploy:deploy /path/to/your/rails/app/log
  

• 修改配置后必须重启Puma（方法见下文），仅重新部署代码不会加载新配置。

二、无需重启服务器重启Puma的方法 #

1. Capistrano内置命令（推荐） #

如果Capfile已加载capistrano/puma插件，本地直接执行：

cap production puma:restart

该命令会远程发送USR2信号给Puma主进程，实现零停机平滑重启。

2. 远程手动操作 #

登录服务器后：

• 查找Puma主进程ID：

  ps aux | grep puma | grep -v grep
  

• 发送USR2信号触发重启：

  kill -USR2 <puma_master_pid>
  

Puma会启动新进程接管请求，旧进程处理完现有连接后自动退出。

3. 通过Puma控制文件重启 #

若配置了Puma PID文件（通常在tmp/pids/puma.pid），执行：

bundle exec pumactl -P /path/to/app/tmp/pids/puma.pid restart

三、异常HEAD请求攻击分析 #

你遇到的是目录扫描/路径探测攻击，攻击者高频发送拼接公开路径的HEAD请求，目的包括：

• 探测服务器上的可访问路径、敏感文件或未授权接口
• 消耗服务器带宽与CPU资源（高频请求会占用连接数）
• 为后续漏洞利用做铺垫（比如找到未修复的路径遍历漏洞）

优化应对方案 #

• 调整NGINX配置，拦截请求时直接关闭连接，避免日志冗余：
  在server块中添加：

  if ($request_method = HEAD) {
      set $block 1;
  }
  if ($request_uri ~* "(/../|/admin/|/backup/|/test/)") {
      set $block "${block}1";
  }
  if ($block = 11) {
      return 444; # 直接断开连接，不记录日志
  }
  

• 用fail2ban自动封禁高频请求IP：配置fail2ban监控NGINX日志，匹配这类异常HEAD请求，自动封禁IP一段时间，替代手动封禁。
• 限制单IP请求频率：在NGINX中添加限流规则，降低攻击影响：

  limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
  server {
      # 其他配置
      limit_req zone=req_limit burst=20 nodelay;
  }
  

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