1. 项目概述为什么在 Ubuntu 上用 nginx Passenger 部署 Rails 不再是“备选方案”而是生产环境的务实选择你刚写完一个 Rails 应用本地rails server跑得飞快但一想到要上线脑子里立刻蹦出一堆问号是继续用puma自己管进程还是上unicorn配systemd要不要再套一层nginx做反向代理如果真这么干那得写好几份配置文件、设好 socket 权限、处理日志轮转、监控进程存活……光是列清单就让人手抖。而这篇要讲的不是“又一种部署方式”而是我过去八年在电商、SaaS、教育类 Rails 项目中反复验证过、被团队从质疑到全员默认采用的最小可行生产栈Ubuntu 系统上用 nginx 直接内嵌 Passenger 模块运行 Rails。它不炫技不堆概念但胜在稳定、透明、易调试——你改一行 configsudo systemctl reload nginx5 秒内生效出问题时错误直接打在 nginx error log 里而不是散落在 puma stdout、journalctl 和自定义日志之间来回切换排查。核心关键词Rails、nginx、Passenger、Ubuntu在这里不是并列关系而是有明确主次的协作链Ubuntu 是确定性最强的基础操作系统比 CentOS Stream 更可控比 Debian 更新更及时nginx 是高性能、低内存占用的 HTTP 服务器兼反向代理Passenger 是那个“看不见却无处不在”的应用服务器胶水层它让 nginx 不再只是转发请求而是能直接加载 Ruby 运行时、管理 Rails 进程生命周期、自动处理预热与空闲回收Rails 则完全按标准方式启动无需修改config/puma.rb或config/unicorn.rb。这种组合规避了“多层代理”带来的延迟叠加和故障点扩散——没有nginx → puma socket → Rails app的三级跳只有nginx → Passenger → Rails的两级穿透网络路径更短超时配置更统一日志上下文更完整。尤其对中小团队或独立开发者它把部署复杂度从“需要专职运维介入”拉回到“开发者自己敲几条命令就能搞定”的量级。我见过太多项目前期为“用不用 Docker”争论两周结果上线后发现真正卡住交付的往往是 nginx 配置里少了一个try_files或是 Passenger 的ruby路径指向了系统默认的 2.7 而不是 rbenv 安装的 3.1。这篇文章就是帮你把这几十个关键细节一次性理清楚、踩过的坑标明白、实操步骤拆解到键盘敲击级别。2. 整体架构设计与方案选型逻辑为什么不是 Puma nginx也不是 Docker nginx而是 nginx Passenger2.1 三种主流 Rails 部署模式的硬核对比不只是“能跑”更要“好管”在 Ubuntu 上部署 Rails目前最常被讨论的其实是三套方案纯 Puma nginx 反向代理、Docker 容器化 nginx、以及本文聚焦的nginx 内嵌 Passenger。很多人选方案只看教程多不多但实际踩坑后才明白决定长期维护成本的是日志可追溯性、配置变更原子性、以及故障定位速度。我们来逐项拆解维度Puma nginx 反向代理Docker nginxnginx Passenger进程管理需手动写 systemd unit 文件Restartalways有时不生效Puma worker crash 后需journalctl -u puma查日志再sudo systemctl restart pumaDocker daemon 管理容器生命周期docker ps一眼看清状态但容器内 Puma 日志需docker logs -f与宿主机 nginx access log 分离Passenger 内置进程监控passenger-status命令直接显示所有 Rails 实例 PID、内存占用、请求队列长度passenger-memory-stats看 Ruby 对象分布sudo nginx -t sudo systemctl reload nginx即完成配置热更新与进程平滑重启Ruby 环境隔离依赖 rbenv/rvm 全局设置若多个 Rails 应用用不同 Ruby 版本需在 Puma config 中指定bundle exec puma -C config/puma.rb容易因 PATH 错误导致启动失败Dockerfile 中FROM ruby:3.1明确锁定版本环境绝对隔离但每次 Ruby 小版本升级如 3.1.4 → 3.1.5都需 rebuild 镜像并 push registryCI/CD 流水线变长Passenger 支持 per-app 指定ruby解释器路径例如/home/deploy/.rbenv/versions/3.1.5/bin/ruby同一台服务器可混跑 Rails 6Ruby 2.7和 Rails 7Ruby 3.1互不干扰无需重建任何东西静态资源服务nginx 需额外配置location /assets指向public/assets且 Rails 生成的 manifest.json 路径需与 nginxalias匹配稍有不慎就 404Docker 中通常把public目录 COPY 进镜像nginx 容器通过 volume 或 multi-stage build 提供静态文件但 assets 缓存头Cache-Control需在 nginx 配置中单独设置Passenger 自动识别 Rails 的public目录对/assets/*、/packs/*Webpacker、/assets/images/*等路径原生支持高效缓存expires 1y和add_header Cache-Control public, immutable默认启用无需额外配置HTTPS 与 SSL 终止nginx 配置ssl_certificate和ssl_certificate_keyPuma 仍走 HTTP配置集中nginx 容器或 ingress controller 处理 SSLPuma 容器内仍是 HTTP但证书文件需挂载进 nginx 容器密钥管理复杂度上升完全由 nginx 层处理Passenger 无感知listen 443 ssl http2;一行搞定 HTTP/2ALPN 协商、OCSP Stapling、HSTS 头均可在 nginx server block 中精细控制提示很多教程说“Passenger 性能不如 Puma”这是严重误解。Passenger Enterprise 版确实有连接池优化但开源版在绝大多数中等流量场景日均 PV 50 万下QPS 差异小于 8%。真正拉开差距的是运维效率——当你的 SRE 团队只有 1 人他花 2 小时调通 Puma 的preload_app!和prune_bundler不如花 15 分钟配好 Passenger 的passenger_min_instances 2和passenger_max_pool_size 6然后去喝杯咖啡。2.2 为什么 Ubuntu 是这个组合的“天选之子”Debian/CentOS 的隐性代价选 Ubuntu 而非其他发行版不是因为“教程多”而是三个硬性事实官方包源支持、内核调度器适配、以及社区问题响应速度。先看数据Passenger 官方文档明确列出 Ubuntu 22.04 LTS 为首选支持平台其 APT 仓库提供预编译的nginx-full包含所有模块包括http_ssl_module,http_v2_module,http_realip_module而 Debian 12 的nginx-full默认不包含http_v2_module需手动编译CentOS Stream 9 的nginx包来自 EPEL版本滞后当前为 1.20.x而 Passenger 要求 nginx ≥ 1.16.0 且需--with-http_v2_module编译选项。这意味着在 Ubuntu 上你执行sudo apt install nginx-extras passenger一条命令就装齐所有依赖在 CentOS 上你得先dnf install gcc make pcre-devel zlib-devel openssl-devel再./configure --with-http_v2_module --add-module/path/to/passenger/src/nginx_module最后make sudo make install——编译时间 8~12 分钟出错概率陡增。更关键的是内核层面。Ubuntu 22.04 默认使用 5.15 内核其mq-deadlineI/O 调度器对 SSD 随机读写优化极佳而 Rails 应用大量依赖数据库查询随机 I/O和 asset 文件读取小文件密集读。我们曾用相同硬件、相同 Rails 应用、相同数据库在 Ubuntu 22.04 和 CentOS Stream 9 上做 ab 压测ab -n 10000 -c 100 http://localhost/healthUbuntu 平均响应时间低 17%错误率socket timeout低 3 倍。这不是玄学是io_uring支持更成熟、page cache回收策略更激进的结果。另外Ubuntu 的systemd-resolvedDNS 缓存机制能显著降低 Rails 应用中Net::HTTP请求的 DNS 解析延迟这点在调用外部 API如 Stripe、SendGrid时尤为明显。注意别迷信“最新版”。Ubuntu 24.04 LTS 尚未发布预计 2024 年 4 月当前生产环境强烈推荐Ubuntu 22.004.3 LTS。它已进入“扩展安全维护ESM”阶段Canonical 承诺提供长达 12 年的安全补丁至 2034 年且 22.04.3 的内核已回滚修复了早期 5.15 版本中影响 ext4 文件系统的 journal commit 延迟 bug。我亲眼见过一个客户在 22.04.1 上Rails 日志写入延迟高达 800ms升级到 22.04.3 后降至 12ms——这就是 LTS 版本迭代的真实价值。2.3 Passenger 的“隐形优势”不只是应用服务器更是 Rails 的“健康管家”Passenger 常被简化为“Ruby 应用服务器”但它在 Rails 生态中的角色远不止于此。它的设计哲学是“让 Web 服务器理解应用语义”而非像 Puma 那样纯粹做 TCP 连接池。这带来三个被严重低估的生产力提升第一零配置预热Zero-Config Warmup。Rails 7 默认开启zeitwerk自动加载但首次请求仍需加载数百个常量。Passenger 的passenger_pre_start指令可让 nginx 在启动时主动发起一个GET /请求触发 Rails 初始化确保第一个真实用户访问时无冷启动延迟。而 Puma 需手动写on_worker_boothook且无法保证所有 worker 同时完成预热。第二智能空闲回收Smart Idle Recycling。Passenger 默认passenger_max_idle_time 3005 分钟当一个 Rails 实例连续 5 分钟无请求它会优雅退出释放内存。但关键在于它不是简单 kill 进程而是先发送SIGTERM等待 Rails 的at_exit钩子执行如关闭数据库连接池、刷新缓存再SIGKILL强制终止。Puma 的worker_timeout仅是硬性超时可能中断正在执行的 DB transaction。第三应用级健康检查App-Level Health Check。Passenger 提供passenger_health_check_path /health你只需在 Rails 中加一个get /healthaction返回{status: ok}Passenger 就会定期探测若连续 3 次失败自动将该实例从负载均衡池中剔除并尝试重启。这比 nginx 的health_check只检查端口是否 open精准得多能捕获 Rails 内部 DB 连接池耗尽、Redis 超时等深层故障。3. 核心细节解析与实操要点从系统初始化到 Rails 上线每一步背后的“为什么”3.1 Ubuntu 系统初始化不是装完就完事而是为 Passenger 埋下稳定基石很多教程跳过系统初始化直接apt update apt upgrade但这恰恰是后续 Passenger 启动失败的根源。Passenger 对系统环境有隐性要求必须禁用 swap或严格限制 swappiness、必须启用 systemd-resolved、必须校准时钟同步。我们来逐条实操第一步永久禁用 swap非删除 swapfilePassenger 的内存管理基于 RSSResident Set Size监控若系统频繁 swappassenger-memory-stats会误判为内存泄漏触发不必要的进程回收。执行# 查看当前 swap 状态 sudo swapon --show # 临时关闭立即生效 sudo swapoff -a # 永久禁用注释 /etc/fstab 中所有 swap 行 sudo sed -i /swap/d /etc/fstab # 验证重启后 free -h 中 swap 行应为 0注意不要用sudo rm /swapfile删除 swapfile某些云厂商如 AWS EC2的 AMI 依赖 swapfile 存在以触发内核 OOM killer 保护。禁用即可保留文件。第二步强制启用 systemd-resolved 并配置 DNSUbuntu 22.04 默认启用systemd-resolved但 Rails 应用若使用Net::HTTP或pggemDNS 解析延迟会直接影响首屏渲染。执行# 确保 resolved 正在运行 sudo systemctl enable --now systemd-resolved # 创建 /etc/systemd/resolved.conf.d/cloudflare.conf echo -e [Resolve]\nDNS1.1.1.1 1.0.0.1\nFallbackDNS8.8.8.8\nDomains~.\nLLMNRno\nMulticastDNSno | sudo tee /etc/systemd/resolved.conf.d/cloudflare.conf sudo systemctl restart systemd-resolved # 验证resolvectl status | grep DNS Servers此配置让所有应用包括 Passenger 加载的 Ruby 进程通过127.0.0.53:53查询 DNSsystemd-resolved会缓存结果平均解析延迟从 35ms 降至 2ms。第三步配置 chrony 精确时钟同步Rails 的ActiveSupport::TimeWithZone依赖系统时钟若服务器时间漂移 1s会导致 JWT token 验证失败、缓存 key 错乱。Ubuntu 22.04 默认用systemd-timesyncd但精度仅 ±200ms。换成chronysudo apt install chrony -y # 编辑 /etc/chrony/chrony.conf注释掉 pool 行添加 echo -e pool ntp.ubuntu.com iburst maxsources 4\nrtcsync\nmakestep 1 3 | sudo tee -a /etc/chrony/chrony.conf sudo systemctl enable --now chrony # 验证chronyc tracking | grep Last offsetmakestep 1 3表示若时钟偏差 1s平滑调整1s 则立即跳变确保 Rails 时间戳绝对可靠。3.2 nginx 与 Passenger 的安装为什么必须用nginx-extras而非nginx-fullPassenger 官方推荐nginx-extras但很多人不解其意。关键在nginx-extras包含了http_geoip_module、http_image_filter_module等 12 个额外模块其中http_realip_module对 Rails 获取真实 IP 至关重要。当你的 Rails 应用需要记录用户 IP如风控、审计request.remote_ip必须准确。若只装nginx-full它默认不编译http_realip_module你得手动编译 nginx而nginx-extras已预编译好。安装命令必须严格按顺序执行# 1. 添加 Passenger 官方 APT 源关键 sudo apt install -y dirmngr gnupg sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7 echo deb https://oss-binaries.phusionpassenger.com/apt/passenger jammy main | sudo tee /etc/apt/sources.list.d/passenger.list sudo apt update # 2. 安装 nginx-extras非 nginx-full sudo apt install -y nginx-extras # 3. 安装 Passenger 及其依赖 sudo apt install -y libnginx-mod-http-passenger提示libnginx-mod-http-passenger是 Ubuntu 22.04 的包名旧版 Ubuntu如 20.04是passenger。若执行sudo apt install passenger报错E: Unable to locate package passenger说明你漏了添加 APT 源的步骤。这是新手最高频的卡点务必检查/etc/apt/sources.list.d/passenger.list是否存在且内容正确。验证安装是否成功# 检查 nginx 是否加载 Passenger 模块 sudo nginx -V 21 | grep -o http_passenger # 应输出 http_passenger # 检查 Passenger 版本 passenger -v # 输出类似 Phusion Passenger 6.0.193.3 Rails 应用部署前的终极检查清单12 个必须确认的配置点Passenger 启动失败90% 源于 Rails 应用自身配置。以下清单是我从上百个项目中提炼的“必检项”每一条都对应一个真实报错config/environments/production.rb中config.public_file_server.enabled truePassenger 要求 Rails 主动声明“我允许 public 目录被直接访问”否则会 403 Forbidden。Puma 下可省略但 Passenger 强制。config/database.yml的 production 环境必须用host: /var/run/postgresqlUnix socket若写host: localhostPostgreSQL 会走 TCP loopback增加 0.3ms 延迟用 Unix socket 可降至 0.05ms。且 Passenger 进程与 PostgreSQL 同服务器socket 更安全。config/credentials.yml.enc的 master key 必须放在/home/deploy/.railsrc或RAILS_MASTER_KEY环境变量Passenger 不读取.env文件必须显式设置。echo export RAILS_MASTER_KEYxxx | sudo tee -a /etc/environment。public/robots.txt必须存在哪怕为空Passenger 启动时会检查public/下关键文件缺失robots.txt会导致Passenger core进程拒绝启动日志报Cannot stat /var/www/myapp/public/robots.txt。config.ru第一行必须是# frozen_string_literal: trueUbuntu 22.04 的 Ruby 3.1 默认启用frozen_string_literal若config.ru无此声明Passenger 加载时会报SyntaxError: ... cant modify frozen String。Gemfile中gem pg必须在group :production外Passenger 启动时需加载所有 gem若pg在 production groupbundle install --without development test会跳过它导致LoadError: cannot load such file -- pg。log/目录权限必须为deploy:deploy且chmod 755Passenger 以www-data用户运行但日志写入需deploy用户可读便于tail -f log/production.log故sudo chown -R deploy:www-data log/ sudo chmod 755 log/。tmp/目录必须存在且chmod 1777Rails 的tmp/cache、tmp/pids依赖 sticky bitsudo chmod 1777 tmp/。config/puma.rb必须删除或重命名如config/puma.rb.disabledPassenger 会忽略puma.rb但若文件存在且语法错误bundle exec rails runner puts 1会报错干扰调试。config/environments/production.rb中config.assets.check_precompiled_asset falsePassenger 不走 Sprockets 的rake assets:precompile流程此配置防止启动时校验 assets。config/application.rb中config.load_defaults 7.0或对应 Rails 版本必须存在缺失会导致 Zeitwerk 自动加载器未初始化Passenger 报uninitialized constant ApplicationController。public/下必须有404.html和500.htmlPassenger 静态服务 404/500 页面缺失则返回 nginx 默认错误页破坏品牌一致性。实操心得我写了一个check_rails_for_passenger.sh脚本每次部署前自动运行覆盖以上 12 项。脚本核心逻辑是grep -q config.public_file_server.enabled true config/environments/production.rb || echo MISSING: public_file_server。把它放在项目根目录chmod x check_rails_for_passenger.sh成为团队 SOP。4. 实操过程与核心环节实现从 nginx 配置到 Passenger 启动手把手复现生产环境4.1 nginx 主配置文件/etc/nginx/nginx.conf的黄金模板Passenger 的性能与稳定性70% 取决于 nginx 主配置。网上流传的“精简版”配置往往埋雷。以下是我在 32 核 128GB 内存服务器上压测验证的生产级模板已去除所有注释仅保留必要指令user www-data; worker_processes auto; worker_rlimit_nofile 65535; events { use epoll; worker_connections 4096; multi_accept on; } http { sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; # Gzip for text-based assets gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss text/javascript; # SSL settings (required even if not using HTTPS yet) ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # Logging log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $request_time $upstream_response_time; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; # Passenger global settings passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini; passenger_ruby /home/deploy/.rbenv/shims/ruby; passenger_max_pool_size 6; passenger_min_instances 2; passenger_max_idle_time 300; passenger_stat_throttle_rate 5; passenger_abort_websockets_on_process_shutdown on; include /etc/nginx/conf.d/*.conf; }关键参数详解worker_processes autoUbuntu 22.04 的auto会根据 CPU 核心数自动设为32但 Passenger 的passenger_max_pool_size 6限制了 Ruby 进程数故实际并发由 Passenger 控制nginx worker 只需处理网络 I/O。use epollLinux 专用高效事件模型比select/poll性能高 3 倍。gzip_types中必须包含application/javascriptRails 7 的 JS 通过importmap加载MIME 类型是application/javascript非text/javascript漏掉则 JS 不压缩。passenger_ruby必须指向rbenv的shims/ruby而非/usr/bin/ruby。rbenv的shims会动态解析当前目录的.ruby-version确保 Passenger 加载正确的 Ruby 版本。passenger_abort_websockets_on_process_shutdown on当 Passenger 因空闲回收杀死 Rails 进程时主动关闭 WebSocket 连接避免前端出现WebSocket is closed before the connection is established错误。4.2 Rails 站点配置/etc/nginx/conf.d/myapp.conf一行代码解决 90% 的 403/500 问题这是 Passenger 启动失败的“重灾区”。一个标准的myapp.conf应如下以/var/www/myapp为应用根目录upstream myapp { server unix:/var/run/passenger.sock; } server { listen 80; server_name myapp.example.com; root /var/www/myapp/public; index index.html; # Force all requests to Rails (except static files) location / { try_files $uri rails; } # Static assets: let nginx serve directly location ~ ^/(assets|packs|system)/ { expires 1y; add_header Cache-Control public, immutable; add_header X-Content-Type-Options nosniff; add_header X-Frame-Options DENY; add_header X-XSS-Protection 1; modeblock; } # Rails app via Passenger location rails { passenger_enabled on; passenger_app_env production; passenger_ruby /home/deploy/.rbenv/shims/ruby; passenger_user deploy; passenger_group deploy; passenger_restart_dir /var/www/myapp/tmp/restart.txt; passenger_friendly_error_pages off; } # Health check endpoint location /health { return 200 {status:ok}; add_header Content-Type application/json; } }逐行避坑指南root /var/www/myapp/public;必须指向public目录不是应用根目录。Passenger 会自动在public下查找index.html、404.html等。若写成root /var/www/myapp;则location /会尝试找/var/www/myapp/index.html而 Rails 的入口是/var/www/myapp/public/index.html导致 404。location ~ ^/(assets|packs|system)/正则必须以^开头确保精确匹配/assets/开头的路径。漏掉^会导致/admin/assets/也被匹配而 admin 的 assets 可能需鉴权造成权限泄露。passenger_user deploy;必须显式指定用户。Passenger 默认以www-data运行但 Rails 的tmp/、log/目录属主是deploy权限不匹配会导致Permission denied - /var/www/myapp/tmp/pids/server.pid。passenger_restart_dir /var/www/myapp/tmp/restart.txt;这是 Passenger 的“热重载开关”。当你修改 Rails 代码后只需touch /var/www/myapp/tmp/restart.txtPassenger 会在 2 秒内检测到文件 mtime 变化优雅重启 Rails 进程无需sudo systemctl reload nginx。passenger_friendly_error_pages off;生产环境必须关闭。开启后 Passenger 会返回美化过的 HTML 错误页掩盖真实 Ruby 异常堆栈。关闭后错误直接写入error.log格式为App 12345 stdout:方便grep ERROR /var/log/nginx/error.log快速定位。实操心得我习惯在myapp.conf末尾加一段# DEBUG注释里面写常用调试命令# DEBUG: # 1. Reload config: sudo nginx -t sudo systemctl reload nginx # 2. Trigger Rails restart: touch /var/www/myapp/tmp/restart.txt # 3. View Passenger status: sudo passenger-status # 4. View memory usage: sudo passenger-memory-stats4.3 Passenger 启动与验证从502 Bad Gateway到200 OK的完整排障链配置完成后执行sudo nginx -t验证语法再sudo systemctl reload nginx。但此时大概率遇到502 Bad Gateway。别慌这是 Passenger 启动流程的正常阶段。按以下顺序排查第一步检查 Passenger 核心进程是否运行# 查看 Passenger core管理进程是否启动 sudo systemctl status nginx | grep passenger # 应看到 Starting Phusion Passenger core... # 若无手动启动 Passenger core sudo /usr/bin/passenger-core --nginx-mode --pid-file /var/run/passenger.pid --log-file /var/log/nginx/passenger.log # 检查日志 sudo tail -f /var/log/nginx/passenger.log常见错误Could not start Passenger core: Permission denied。原因是/var/run/passenger.pid目录属主不是www-data。修复sudo mkdir -p /var/run/passenger sudo chown www-data:www-data /var/run/passenger sudo chmod 755 /var/run/passenger第二步验证 Rails 应用能否被 Passenger 加载# 切换到 deploy 用户模拟 Passenger 启动环境 sudo -u deploy -H bash -c cd /var/www/myapp /home/deploy/.rbenv/shims/bundle exec rails runner puts Rails.env # 应输出 production # 检查 Passenger 是否识别到应用 sudo passenger-status # 应看到类似 # Version : 6.0.19 # Date : 2024-03-15 10:23:45 0000 # Instance: 12345 # ----------- General information ----------- # Max pool size : 6 # Processes : 2 # Requests in top-level queue : 0第三步检查 nginx error log 中的 Passenger 关键错误# 实时跟踪错误日志 sudo tail -f /var/log/nginx/error.log | grep -i passenger\|ruby\|loaderror高频错误及修复Could not spawn process for application /var/www/myapp: 检查passenger_ruby路径是否正确执行sudo -u deploy -H /home/deploy/.rbenv/shims/ruby -v。Cannot execute /home/deploy/.rbenv/shims/bundle:bundle命令未找到执行sudo -u deploy -H /home/deploy/.rbenv/shims/bundle -v若报错说明rbenv未正确初始化需在/etc/nginx/nginx.conf中passenger_ruby改为/home/deploy/.rbenv/versions/3.1.5/bin/ruby绝对路径。App 12345 stderr: /var/www/myapp/config/environments/production.rb:12:intop (required): undefined method public_file_server: 说明 Rails 版本 5.2config.public_file_server.enabled true无效改为config.serve_static_files true。第四步最终验证# 发送健康检查请求 curl -I http://localhost/health # 应返回 HTTP/1.1 200 OK # 访问 Rails 应用 curl -s http://localhost | head -20 # 应看到 Rails 的 HTML 输出而非 nginx 默认页5. 常见问题与排查技巧实录那些官方文档不会写的“血泪经验”5.1 “502 Bad Gateway” 的 7 种真实原因与秒级定位法502 Bad Gateway是 Passenger 新手的第一道墙。但 95% 的情况只需一条命令定位# 一键诊断同时查看 nginx error log、Passenger status、Rails log sudo tail -n 20 /var/log/nginx/error.log | grep -i passenger\|ruby\|spawn\|load \ sudo passenger-status 2/dev/null | head -10 \ sudo tail -n 10 /var/www/myapp/log/production.log 2/dev/null根据输出快速匹配原因现象原因修复命令error.log中App 12345 stderr: /var/www/myapp/config.ru:1:in \require: cannot load such file -- /var/www/myapp/config/environmentconfig.ru第一行缺少# frozen_string_literal: true或require路径错误sed -i 1s/^/# frozen_string_literal: true
