Rails应用部署至AWS Elastic Beanstalk后出现nginx/1.18.0 502 Bad Gateway问题咨询

优先定位Puma进程本身的异常 #

upstream prematurely closed connection while reading response header from upstream的本质是Nginx尝试连接后端Puma服务时，还没完成正常的HTTP响应交互，连接就被Puma端主动断开，这是最常见的触发场景：

• 登入对应EC2实例，执行ps aux | grep puma，确认Puma进程是否真的在运行，且监听地址和配置预期一致。常见异常包括：Puma进程完全未启动、绑定的地址和Nginx预期不匹配（比如配置写了绑定Unix套接字，实际Puma绑定了TCP端口，或端口号配置错误）。
• 查看Puma专属日志路径/var/log/puma/stderr.log、/var/log/puma/stdout.log，定位进程崩溃的直接原因：
  • 检查是否存在OOM（内存溢出）杀进程记录，可在实例上执行dmesg | grep -i oom，如果Puma进程因为占用内存超过实例可用上限被内核杀掉，就会触发这个Nginx报错。
  • 检查是否存在初始化阶段的报错：比如未正确注入SECRET_KEY_BASE环境变量、RDS连接初始化超时、Asset资源缺失（找不到manifest.json文件）、权限不足无法读写Puma的套接字文件。
  • 检查是否因为配置冲突导致Puma异常退出：比如在puma.rb中手动开启daemonize true，和Elastic Beanstalk默认的systemd托管逻辑冲突，导致Puma启动后被托管进程判定为异常退出反复重启。

对齐Puma与Nginx的配置匹配度 #

很多部署场景的502是两层服务的配置不匹配导致的：

• 查看Nginx的实际upstream配置（路径一般为/etc/nginx/conf.d/elasticbeanstalk/下的自定义配置文件），确认proxy_pass指向的Puma地址、端口/套接字路径，和Puma实际绑定的地址完全一致，哪怕少一个斜杠、端口号差一位都会触发连接中断。
• 检查超时配置匹配性：Nginx默认proxy_read_timeout为60秒，如果Rails应用首次请求需要加载大量代码、建立RDS连接、完成Asset预加载，响应时间超过阈值就会被Nginx判定为连接异常。临时调整时可通过EB扩展配置将代理超时值临时提升到120秒验证。
• 检查权限配置：确认Nginx运行用户、Puma运行用户对Puma绑定的套接字文件有一致的读写权限，如果套接字文件权限被设置为仅root可访问，Nginx连接时就会被直接拒绝，触发upstream提前断连的报错。

核对现有自定义配置的常见踩坑点 #

结合当前使用的Rails 6.0.3.5、Puma 4.3.7、Ruby 2.6.6版本组合，以及你自定义的扩展配置，重点排查以下容易被忽略的问题：

• 针对production.rb配置：检查是否在production环境中残留了会阻塞初始化的逻辑，比如需要连接外部调试服务、本地文件路径无读写权限的代码，避免应用刚启动就抛异常退出。
• 针对puma.rb配置：检查preload_app!开启时，是否正确配置了worker启动后的数据库连接重连逻辑；该版本组合下，如果未正确重连数据库，会导致worker进程接收到第一个请求就崩溃。
• 针对EB扩展配置（Packages.config、yarn.config）：检查yarn安装、前端资源编译的步骤是否完整执行，是否存在依赖版本和Ruby/Puma版本不兼容的问题（比如OpenSSL版本不匹配导致Puma原生扩展加载失败）。

快速验证的排障步骤 #

• 登入EC2实例，手动执行curl -v <Puma实际监听地址>，如果直接请求Puma本地地址都出现连接被拒、连接重置的问题，可直接排除Nginx配置问题，聚焦Puma进程本身的启动逻辑排查。
• 临时手动重启Puma进程，观察是否因为长期运行内存泄漏导致进程被回收，重启后恢复访问即可确认是内存溢出类的问题。

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