我会尽量简短。
我有多个 Rails 应用程序在 Digital Oceans rps 上运行。目前有 3 个，但我已经有更多了。全部与 Capistrano 一起部署。两个还是rails 7.0，一个是7.1.2。服务器是 Ubuntu 18.04，我已经使用它超过 5 年了。
前几天我快速浏览了日志。我在 7.1.2 应用程序中遇到了一些垃圾。我刚刚注意到没有生产日志。在配置/生产中，我有一些用于设置日志级别的旧东西。
config.log_level = ENV.fetch("RAILS_LOG_LEVEL", "info")
我设置为:warn并重新部署，但还是不行。经过大量阅读后，我现在了解到，除非版本发生变化，否则很多配置选项都不会在部署中设置。
我还注意到我的 NGINX 日志很大并且没有轮换。修复了一个应用程序受到某种垃圾邮件或拒绝服务攻击的问题。每隔一秒左右我就会进入 nginx 访问日志
47.76.35.19 - - [05/Jan/2024:16:22:56 -0600] "HEAD /payouts/score_sheet/new_score_sheet/new_score_sheet/new_score_sheet/score_sheet/new_score_sheet/new_score_sheet/payouts/payouts/new_score_sheet/payouts/score_sheet/
new_score_sheet/new_score_sheet/about/new_score_sheet/payouts/new_score_sheet/about/new_score_sheet/score_sheet/score_sheet/new_score_sheet/payouts/new_score_sheet/
new_score_sheet/new_score_sheet/new_score_sheet/payouts/payouts/new_score_sheet/score_sheet/new_score_sheet/about/score_sheet/payouts/about/score_sheet/new_score_sheet/
about/score_sheet/new_score_sheet/payouts/payouts/score_sheet/payouts/score_sheet/about/payouts/payouts/score_sheet/payouts/score_sheet/payouts/about/new_score_sheet
payouts/score_sheet/new_score_sheet/new_score_sheet/new_score_sheet/score_sheet/
new_score_sheet/score_sheet/about/new_score_sheet/new_score_sheet/payouts/about/
about/payouts/score_sheet/new_score_sheet/about/about/payouts/new_score_sheet/
new_score_sheet/new_score_sheet/payouts/score_sheet/new_score_sheet/
HTTP/1.1" 403 0 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3522.153 Safari/537.36"
它们都是无需登录即可在主页菜单上使用的路径 - 只是串在一起。路径只是在每次访问时轮换名称。
我看起来重启服务器的唯一方法就是重启linux机器，但我几乎害怕了！
It uptime is :18:29:15 up 949 days, 5:32, 3 users, load average: 0.00, 0.01, 0.00
不知道为什么我害怕 - 我重新启动我的临时服务器（本地 debian 盒子），一切都出现了。
尽管我会问除了重新启动之外是否还有其他方法。 “rails restart”不起作用，这是针对 Passenger 的，我正在使用 Puma。
另外，如果有人知道什么类型的垃圾邮件和什么东西正在攻击我的服务器，我将不胜感激。我拒绝了该 IP，但它仍然出现在日志中。
提前致谢
关于重启：我不完全确定你的 Puma 设置。我们的一种设置是 puma 是一个单独的 unix 进程，而 nginx 是单独的。两者都有自己的 systemd 文件入口点，通过套接字连接。因此，如果您想要轮换 nginx 日志或重新启动 nginx，则无需重新启动 Rails 应用程序即可执行此操作，因为这些应用程序未在进程 ID (pid) 级别上连接。可能会有（非常小的）停机时间，但由于 Rails 应用程序（无论它有多大）尚未重新启动，nginx 应该会在一秒钟内启动。
关于这些日志：不用担心，任何暴露在公共互联网上的东西都会时不时地被机器人攻击，所以这是正常的。但是，请确保您的 gems 和操作系统保持升级，这样您的应用程序中就不会出现任何严重的漏洞，导致其遭受攻击。