旧版Rails应用升级到6.0.4后健康检查接口响应大幅变慢求助

排查方向和解决方案 #

优先验证高频触发问题 #

• 先验证是否是DNS解析/IPv6 fallback问题：本地直接请求IP+端口测试：time curl 127.0.0.1:${你的服务端口}/health_check，如果耗时恢复正常，说明是app.local域名的解析问题：通常是本地DNS先尝试AAAA（IPv6）记录查询，等待1秒超时后才 fallback 到A（IPv4）记录，刚好匹配你遇到的耗时区间，可以修改/etc/hosts强制绑定域名到127.0.0.1，或者禁用IPv6解析即可解决。
• 关闭IP欺骗检查验证：Rails 6默认开启了严格的ip_spoofing_check，如果请求头带了X-Forwarded-For等代理相关头，会触发反向DNS解析，超时时间通常为1秒。可以在配置中临时添加config.action_dispatch.ip_spoofing_check = false测试，如恢复正常即可确认是该问题，后续按实际场景配置可信代理列表即可。
• 验证Host白名单配置问题：Rails 6新增了config.hosts白名单校验，不在白名单内的Host请求会被中间件拦截，部分小版本的校验逻辑存在性能缺陷。开发环境可以临时加config.hosts.clear关闭校验测试，生产环境将健康检查的请求Host加入白名单即可。

次优先排查中间件链路 #

Rails 日志的耗时仅统计Controller层处理的时间，请求进入Controller前的中间件链路耗时不会被统计，升级版本后默认新增或第三方插件新增的中间件都可能导致耗时：

• 执行rails middleware列出所有加载的中间件，重点检查：
  • 你日志中提到的ActionDispatch::SSL中间件：如果开启了config.force_ssl但未将健康检查路径加入豁免列表，可能存在多余的重定向校验逻辑
  • 自定义的认证、限流、日志中间件：是否在未匹配到路由/未排除健康检查路径的情况下执行了多余逻辑（比如拉取配置、查询数据库等）
• 可以给中间件加简单的耗时埋点，快速定位卡住的中间件。

底层链路排查 #

• 用strace工具跟踪Unicorn worker进程的系统调用：执行ps aux | grep unicorn找到worker进程ID，然后执行strace -tt -p ${进程ID}，再发起健康检查请求，直接查看慢请求卡住的系统调用，即可100%定位阻塞点（比如DNS查询、网络IO、文件IO等阻塞场景CPU采样无法捕获，strace可以直接定位）。
• 如果你本地用了Nginx反向代理到Unicorn，检查Nginx的proxy_buffering配置：如果开启了缓冲且响应大小触发了磁盘缓冲，会导致响应延迟，将健康检查路径的缓冲关闭即可。
• 检查Unicorn worker的排队情况：预发布环境的CPU尖峰如果伴随请求排队，可以调整worker_processes数量，或者检查是否有其他请求阻塞了worker进程导致健康检查请求排队。

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