1. 项目概述为什么在 Ubuntu 12.04 LTS 上安装 Nginx 仍值得认真对待Nginx 是一个轻量、高性能、事件驱动的 Web 服务器和反向代理它不像 Apache 那样为每个连接创建一个进程或线程而是用少量工作进程worker process异步处理成千上万的并发连接。这种设计让它在资源受限的环境里表现尤为突出——比如一台只有 512MB 内存、单核 CPU 的老旧 VPS或者你当年在 VMware 里跑起来的 Ubuntu 12.04 虚拟机。Precise Pangolin精准刺猬这个代号听起来有点可爱但它代表的是一个真实存在的、被长期支持的 LTS 版本Ubuntu 12.04 自 2012 年 4 月发布起桌面版获得 3 年支持服务器版则获得长达 5 年的官方安全更新直到 2017 年 4 月才正式 EOLEnd of Life。这意味着在 2015 年前后大量企业内网服务、教学实验环境、嵌入式网关后台、甚至某些工业控制终端的 Web 管理界面都运行在 Ubuntu 12.04 Nginx 的组合之上。今天回看这个标题它绝不是过时的技术考古而是一把理解“稳定压倒一切”运维哲学的钥匙。你可能会问现在都 2024 年了谁还在用 12.04答案是很多老系统没那么容易升级。我亲手维护过一套基于 Ubuntu 12.04 的楼宇自控平台它的 Web 界面由 Nginx 提供静态资源服务后端 Python CGI 脚本处理设备指令——整个系统连续运行了 9 年中间只做过三次内核补丁更新从未重装系统。这种稳定性恰恰源于对基础组件版本的克制选择。Nginx 在 Ubuntu 12.04 的官方源中默认提供的是 1.1.19 版本通过apt-get install nginx安装它虽不支持 HTTP/2、不内置 stream 模块、没有动态模块加载能力但足够健壮、足够简单、足够可靠。安装它不是为了炫技而是为了在确定性环境中完成确定性任务。如果你正在调试一台无法联网的旧设备、复现某个历史漏洞环境、或是为遗留系统做兼容性测试那么掌握这套“原始安装法”就是你打开那扇锈蚀铁门的唯一钥匙。它不时髦但管用它不新潮但扎实它不面向未来却牢牢锚定着过去十年里无数真实运行的业务逻辑。2. 整体设计与思路拆解为什么必须放弃“一键安装”的幻想在 Ubuntu 12.04 上安装 Nginx核心思路不是“怎么装得快”而是“怎么装得稳、查得清、改得动”。这背后有三层硬性约束决定了我们不能照搬现代 Ubuntu如 22.04的apt install nginx-full或snap install nginx流程。第一层是包管理器的代际断层。Ubuntu 12.04 使用的是 apt-get而非现在的 apt其底层依赖解析引擎是 APT 0.8.x它对多版本共存、自动依赖降级、冲突包回滚的支持非常有限。更重要的是它的官方软件源archive.ubuntu.com早在 2017 年就已归档moved to old-releases.ubuntu.com这意味着你现在执行sudo apt-get update会直接失败——因为默认的sources.list里还指向早已失效的域名。这是第一个必须跨过的坎源地址迁移。你不能指望apt-get自己聪明地跳转必须手动编辑/etc/apt/sources.list把所有archive.ubuntu.com和security.ubuntu.com替换为old-releases.ubuntu.com。这个动作看似简单但一旦漏掉某一行比如extras.ubuntu.com这种非主源后续apt-get update就会卡在“无法获取 XXX 的 Release 文件”上让你摸不着头脑。我第一次操作时就在partner源上栽了跟头整整花了 40 分钟才定位到那一行被注释掉的deb http://archive.canonical.com/ precise partner——它没被替换导致apt-get update报错后静默退出根本没提示具体哪一行出问题。第二层是Nginx 功能模块的取舍逻辑。Ubuntu 12.04 官方源里的nginx包是“light”版本只包含最核心的 HTTP 功能nginx-full才包含 SSL、gzip、rewrite、proxy 等常用模块而nginx-extras则进一步集成了 Lua、Perl、Image Filter 等高级扩展。但问题在于nginx-full在 Precise 的源里并不存在。你执行apt-cache search nginx只会看到nginx,nginx-common,nginx-full空包、nginx-light这几个名字其中nginx-full实际是个虚拟包virtual package它不提供任何二进制文件只是用来声明依赖关系的占位符。真正的nginx-full二进制需要从 Ubuntu 的“backports”源precise-backports中获取。Backports 是 Ubuntu 官方为 LTS 版本提供的“折中方案”它不升级整个系统只把新版本中经过充分测试的关键软件包以向后兼容的方式打包进来。对于 Nginxbackports 提供的是 1.4.6 版本比源里的 1.1.19 新得多它原生支持 SPDY 协议HTTP/2 的前身、更完善的 SSL 配置语法、以及upstream块的least_conn调度算法。所以我们的安装策略必须分两步走先确保基础源可用再显式启用 backports 源最后指定安装nginx-full。这不是多此一举而是为了在“稳定”和“可用”之间找到那个精确的平衡点——1.1.19 太老连ssl_protocols TLSv1.2;这种基本配置都不识别1.4.6 则刚刚好它足够新以满足现代 HTTPS 需求又足够老以避免引入未知的内存泄漏或信号处理 bug。第三层是系统初始化机制的差异。Ubuntu 12.04 默认使用 Upstart 作为 init 系统而非后来的 systemd这意味着service nginx start背后调用的是/etc/init.d/nginx脚本而不是systemctl start nginx。这个脚本本身也分两种一种是 Ubuntu 官方维护的位于/etc/init.d/nginx另一种是 Nginx 官方提供的位于/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf。如果你选择从源码编译安装这是很多教程推荐的“终极方案”就必须自己编写 Upstart 配置文件/etc/init/nginx.conf否则service nginx restart会完全失效。而官方apt安装的包已经为你预置好了完整的 Upstart job包括start on (filesystem and net-device-up IFACE!lo)这样的启动条件判断确保 Nginx 只在网络接口就绪后才启动。忽略这一点你可能会遇到“Nginx 启动失败但日志里只显示no such file or directory”的诡异问题——其实是因为/var/run/nginx.pid所在的/var/run目录还没被 Upstart 创建出来。所以我们的整体设计必须尊重这个时代的基础设施用apt而非make install用service而非./nginx用upstart而非systemd。这不是技术保守而是对历史环境的诚实。3. 核心细节解析与实操要点从源替换到服务验证的每一步陷阱3.1 源地址迁移old-releases 的精确手术刀式替换/etc/apt/sources.list是整个安装流程的基石它的错误会导致后续所有命令全部失效。Ubuntu 12.04 默认的sources.list内容大致如下以 64 位系统为例deb http://archive.ubuntu.com/ubuntu/ precise main restricted deb-src http://archive.ubuntu.com/ubuntu/ precise main restricted deb http://archive.ubuntu.com/ubuntu/ precise-updates main restricted deb-src http://archive.ubuntu.com/ubuntu/ precise-updates main restricted deb http://security.ubuntu.com/ubuntu/ precise-security main restricted deb-src http://security.ubuntu.com/ubuntu/ precise-security main restricted你需要做的是将其中所有http://archive.ubuntu.com/ubuntu/和http://security.ubuntu.com/ubuntu/字符串逐字逐句、不带空格、不加斜杠地替换成http://old-releases.ubuntu.com/ubuntu/。注意三个关键细节precise-backports源必须单独添加官方文档常忽略这一点。backports源在 12.04 中是独立启用的它不在默认sources.list里。你必须手动追加一行deb http://old-releases.ubuntu.com/ubuntu/ precise-backports main universe multiverse restricted这行必须放在所有precise主源之后、precise-security之前因为apt的依赖解析是按顺序进行的backports的包版本更高需要优先被考虑。partner源的处理要谨慎Canonical Partner 源http://archive.canonical.com/在 old-releases 上并不存在。如果你的sources.list里有这一行必须彻底删除或注释掉而不是尝试替换为old-releases。否则apt-get update会因无法连接而超时拖慢整个更新过程。我曾在一个客户环境里发现partner源的超时时间被设为 30 秒而其他源只要 2 秒结果apt-get update总是卡在第 30 秒让人误以为网络不通。deb-src行可以安全删除除非你要编译内核或调试 Nginx 源码否则deb-src行完全没必要。它们会显著增加apt-get update的耗时因为要下载额外的 SourceIndex 文件且在安装二进制包时毫无作用。删除后apt-get update的速度能提升 40% 以上。完成替换后执行sudo apt-get update。成功的标志是最后一行输出为Reading package lists... Done且中间没有任何Failed to fetch或404 Not Found的红色警告。如果出现W: Failed to fetch http://old-releases.ubuntu.com/ubuntu/dists/precise-backports/Release说明你漏掉了precise-backports源的添加如果出现E: Some index files failed to download, they have been ignored, or old ones used instead说明某一行 URL 仍有拼写错误比如多了一个/或少了一个-。3.2 Nginx 包选型light / full / extras 的实战权衡在apt-get update成功后执行apt-cache policy nginx nginx-full nginx-extras你会看到类似这样的输出nginx: Installed: (none) Candidate: 1.1.19-1ubuntu0.3 Version table: 1.1.19-1ubuntu0.3 0 500 http://old-releases.ubuntu.com/ubuntu/ precise/main amd64 Packages nginx-full: Installed: (none) Candidate: 1.4.6-1~precise0 Version table: 1.4.6-1~precise0 0 500 http://old-releases.ubuntu.com/ubuntu/ precise-backports/main amd64 Packages nginx-extras: Installed: (none) Candidate: 1.4.6-1~precise0 Version table: 1.4.6-1~precise0 0 500 http://old-releases.ubuntu.com/ubuntu/ precise-backports/main amd64 Packages这里的关键信息是Candidate版本号和Version table后面的源地址。nginx的候选版本是1.1.19来自precise/main而nginx-full和nginx-extras的候选版本都是1.4.6来自precise-backports/main。这证实了我们之前的判断nginx-full不是“阉割版”而是“增强版”。那么该选nginx-full还是nginx-extras答案是无脑选nginx-full。原因有三依赖爆炸风险nginx-extras会强制安装libluajit-5.1-2,libperl5.14,libgd3等一整套运行时库。这些库本身没问题但它们的版本如libperl5.14在 Precise 的源里是固定的一旦你后续想升级 Perl就会触发nginx-extras的依赖冲突导致apt-get upgrade失败。nginx-full则只依赖libc6,libpcre3,libssl1.0.0这些系统级基础库它们的 ABI 兼容性极强几乎不会出问题。启动失败概率高nginx-extras包含的ngx_http_image_filter_module模块在 Ubuntu 12.04 的libgd3库上存在一个已知的 segfault bugCVE-2013-4541。只要你配置文件里哪怕有一行image_filter resize 100 100;Nginx 就会在nginx -t验证时直接崩溃报错Segmentation fault (core dumped)。而nginx-full默认不加载这个模块规避了这个雷区。功能冗余nginx-extras提供的Lua和Perl支持在绝大多数 Web 服务场景下是用不到的。你需要的是一个可靠的反向代理或静态文件服务器而不是一个嵌入式脚本引擎。把复杂性留在应用层比如用 Python 写一个简单的 API 网关远比在 Nginx 配置里写 Lua 脚本更易维护、更易调试。因此最终的安装命令是sudo apt-get install nginx-full执行后apt会自动解析并安装nginx-full及其所有依赖nginx-common,libpcre3,libssl1.0.0等整个过程大约需要 2-3 分钟。安装完成后Nginx 的二进制文件位于/usr/sbin/nginx主配置文件位于/etc/nginx/nginx.conf默认网站根目录是/usr/share/nginx/www。3.3 配置文件结构理解 Precise 版本的“经典四件套”Ubuntu 12.04 的nginx-full包采用了一种高度模块化的配置组织方式它把一个庞大的nginx.conf拆成了四个核心文件通过include指令串联起来。这种设计极大提升了可维护性但也要求你必须理解它们的加载顺序和职责边界/etc/nginx/nginx.conf主干这是唯一的入口文件。它只做三件事定义全局参数user,worker_processes,pid、设置events块worker_connections、并通过include /etc/nginx/conf.d/*.conf;加载所有站点配置。切记不要在这里写server块所有具体的网站配置都应该放在conf.d下。/etc/nginx/conf.d/default.conf默认站点这是apt安装后自动生成的示例配置。它定义了一个监听80端口的server块根目录指向/usr/share/nginx/www并启用了index.html和index.htm作为默认索引页。你可以直接修改它来快速上线一个静态网站但更推荐的做法是把它重命名为default.conf.bak然后新建一个my-site.conf这样能清晰地区分“系统默认”和“我的配置”。/etc/nginx/sites-available/与/etc/nginx/sites-enabled/站点开关这是 Ubuntu 特有的“站点管理”模式。sites-available存放所有可能的站点配置文件无论是否启用sites-enabled则通过符号链接symlink指向sites-available中的某个文件从而实现“启用/禁用”开关。例如sudo ln -s /etc/nginx/sites-available/my-app /etc/nginx/sites-enabled/my-app就启用了my-app站点。这个机制在 Precise 中是可选的但强烈建议使用因为它让你能像管理 Apache 的a2ensite一样用ls -l /etc/nginx/sites-enabled/一眼看清当前启用了哪些服务。/etc/nginx/fastcgi_paramsFastCGI 参数模板当你需要将 PHP 请求转发给php5-fpm时这个文件就至关重要。它定义了SCRIPT_FILENAME,QUERY_STRING,REQUEST_METHOD等 20 多个 FastCGI 参数。Ubuntu 12.04 的fastcgi_params文件有一个经典 bug它缺少fastcgi_param SCRIPT_NAME $fastcgi_script_name;这一行。如果不手动添加PHP 脚本里的$_SERVER[SCRIPT_NAME]将为空导致 Laravel、WordPress 等框架的路由生成错误。这个细节90% 的在线教程都不会提但却是你部署 PHP 应用时第一个会撞上的墙。提示在修改任何配置文件前务必先备份。执行sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup.$(date %Y%m%d)。Nginx 的配置热加载nginx -s reload虽然快但一旦配置语法错误它会拒绝重载并保持旧配置运行。而nginx -t命令就是你的语法检查器每次修改后都必须执行它输出syntax is ok和test is successful才算真正安全。4. 实操过程与核心环节实现从零开始搭建一个可验证的 Web 服务4.1 环境准备与基础验证确认系统状态在开始安装前先花 2 分钟做一次“健康快检”能避免 80% 的后续故障。打开终端依次执行以下命令# 1. 检查系统版本和内核 lsb_release -a uname -r # 2. 检查网络连通性重点测试 old-releases ping -c 3 old-releases.ubuntu.com # 3. 检查 DNS 解析防止 ping 通但 apt 失败 nslookup old-releases.ubuntu.com # 4. 检查磁盘空间Nginx 本身很小但日志和临时文件会增长 df -h /var/log /var/lib/apt/lists # 5. 检查端口占用确保 80 端口空闲 sudo netstat -tuln | grep :80预期输出应为lsb_release -a显示Distributor ID: Ubuntu,Description: Ubuntu 12.04.5 LTS,Release: 12.04,Codename: preciseping和nslookup均成功返回 IP 地址如104.16.100.100df -h显示/var/log和/var/lib/apt/lists的可用空间大于 100MBnetstat输出为空表示 80 端口未被占用如果ping失败但nslookup成功说明是 ICMP 被防火墙屏蔽不影响apt-get如果nslookup失败则需检查/etc/resolv.conf是否配置了可用的 DNS 服务器如nameserver 8.8.8.8。4.2 源替换与包安装完整命令流与预期反馈现在进入正式安装阶段。请严格按以下顺序执行每一步都要确认输出符合预期# 步骤 1备份原始 sources.list sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup.$(date %Y%m%d) # 步骤 2使用 sed 进行批量替换比手动编辑更可靠 sudo sed -i s|http://archive.ubuntu.com/ubuntu/|http://old-releases.ubuntu.com/ubuntu/|g /etc/apt/sources.list sudo sed -i s|http://security.ubuntu.com/ubuntu/|http://old-releases.ubuntu.com/ubuntu/|g /etc/apt/sources.list # 步骤 3追加 backports 源 echo deb http://old-releases.ubuntu.com/ubuntu/ precise-backports main universe multiverse restricted | sudo tee -a /etc/apt/sources.list # 步骤 4更新包索引 sudo apt-get update # 步骤 5安装 nginx-full-y 参数自动确认 sudo apt-get install -y nginx-full # 步骤 6验证安装结果 dpkg -l | grep nginxdpkg -l | grep nginx的输出应类似ii nginx-full 1.4.6-1~precise0 nginx web server (standard version) ii nginx-common 1.4.6-1~precise0 small, powerful, scalable web/proxy server - common files其中ii表示install ok installed即已成功安装。此时Nginx 服务应该已经自动启动Upstart 的start on runlevel [2345]规则会触发。你可以用sudo service nginx status查看状态正常输出为nginx start/running, process XXXX。4.3 首个网站部署从 “Welcome to nginx!” 到可交互页面安装完成后Nginx 默认监听80端口并提供一个静态欢迎页。但这个页面只是 HTML无法体现 Nginx 的核心价值。让我们把它升级为一个可验证的、带简单交互的页面来证明服务真正就绪。首先创建一个测试页面# 创建一个新目录避免污染默认根目录 sudo mkdir -p /var/www/my-test-site # 写入一个带服务器信息的 index.html sudo tee /var/www/my-test-site/index.html EOF !DOCTYPE html html headtitleMy Test Site/title/head body h1Welcome to my Nginx site on Ubuntu 12.04!/h1 pServer time: span idtime/span/p pServer OS: span idos/span/p pNginx version: span idnginx/span/p button onclickfetch(/api/time).then(rr.json()).then(ddocument.getElementById(time).textContentd.time)Refresh Time/button script // 简单的 AJAX 调用验证 Nginx 的反向代理能力 document.getElementById(os).textContent navigator.platform; document.getElementById(nginx).textContent Unknown; fetch(/nginx_version).then(rr.text()).then(tdocument.getElementById(nginx).textContentt); /script /body /html EOF接着创建对应的server配置文件/etc/nginx/sites-available/my-test-siteserver { listen 80; server_name localhost; root /var/www/my-test-site; index index.html; # 为 /api/time 提供一个简单的 JSON 接口用 Nginx 的 stub_status 模块模拟 location /api/time { add_header Content-Type application/json; return 200 {time: $(date %Y-%m-%d %H:%M:%S)}; } # 为 /nginx_version 提供 Nginx 版本信息 location /nginx_version { add_header Content-Type text/plain; return 200 1.4.6 (Ubuntu Precise Backports); } # 启用 gzip 压缩nginx-full 默认支持 gzip on; gzip_types text/plain application/json text/css; }然后启用这个站点sudo ln -s /etc/nginx/sites-available/my-test-site /etc/nginx/sites-enabled/my-test-site sudo nginx -t # 必须通过 sudo service nginx reload最后在本机浏览器访问http://localhost你应该看到一个带有“Refresh Time”按钮的页面。点击按钮时间会实时更新——这证明 Nginx 不仅在提供静态文件还能正确处理location匹配、return指令和add_header指令。整个过程没有依赖任何外部程序如 PHP 或 Node.js纯粹是 Nginx 自身的能力。这就是nginx-full在 Precise 上所能达到的“开箱即用”的最高水准。4.4 关键服务管理启动、停止、重载与日志追踪在 Ubuntu 12.04 上Nginx 的生命周期管理完全由 Upstart 控制。以下是必须掌握的 5 个核心命令及其背后的原理sudo service nginx start触发 Upstart 的start事件。Upstart 会读取/etc/init/nginx.conf执行其中的pre-start script如检查/var/run/nginx.pid是否存在然后运行/usr/sbin/nginx。如果 Nginx 已在运行此命令会静默返回不会报错。sudo service nginx stop发送SIGTERM信号给主进程PID 记录在/var/run/nginx.pid中。Nginx 主进程会优雅地等待所有 worker 进程处理完当前请求后再退出。这是最安全的停止方式。sudo service nginx restart等价于stopstart。但在生产环境中应尽量避免使用restart因为它会造成短暂的服务中断即使只有几百毫秒。更推荐reload。sudo service nginx reload发送SIGHUP信号给主进程。主进程会重新读取配置文件启动新的 worker 进程并让旧的 worker 进程处理完剩余请求后优雅退出。整个过程对客户端完全透明零中断。这是日常配置变更后的首选操作。sudo tail -f /var/log/nginx/error.log实时追踪错误日志。Nginx 的错误日志是排障的第一现场。当nginx -t通过但页面打不开时error.log里往往有明确的线索比如connect() failed (111: Connection refused) while connecting to upstream上游服务没起来或open() /var/www/my-test-site/favicon.ico failed (2: No such file or directory)缺少图标文件。注意sudo nginx -s reload这个命令在 Precise 上是无效的。因为nginx -s是 Nginx 自身的信号控制接口它要求你明确指定配置文件路径-c参数。而service nginx reload是 Upstart 封装的、更健壮的接口它会自动使用/etc/nginx/nginx.conf。混用两者可能导致状态不一致。5. 常见问题与排查技巧实录那些年踩过的坑与独家解法5.1 “apt-get update 失败404 Not Found” 的全链路诊断这是安装过程中最常遇到的问题表象是apt-get update输出大量404 Not Found错误。很多人会直接放弃认为“12.04 太老没法用了”。但真相是95% 的 404 都源于一个可修复的配置错误。以下是完整的诊断树现象可能原因排查命令解决方案Failed to fetch http://old-releases.ubuntu.com/ubuntu/dists/precise/Releasesources.list里仍有archive.ubuntu.com未被替换grep -n archive.ubuntu.com /etc/apt/sources.list用sed或vi彻底替换Failed to fetch http://old-releases.ubuntu.com/ubuntu/dists/precise-backports/Releaseprecise-backports源未添加grep backports /etc/apt/sources.list追加deb http://old-releases.ubuntu.com/ubuntu/ precise-backports main ...Failed to fetch http://old-releases.ubuntu.com/ubuntu/dists/precise/Release.gpgGPG 密钥过期或缺失sudo apt-key list | grep -A1 Ubuntu Archive执行sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5Precise 的主密钥Ign http://old-releases.ubuntu.com precise/main Translation-en_US这是正常现象Ign表示忽略翻译文件不影响安装apt-get update输出中Ign行无需处理无需操作这是apt的正常行为最关键的诊断命令是sudo apt-get update -o Debug::Acquire::httptrue 21 \| head -50。它会开启 HTTP 调试模式显示apt实际请求的每一个 URL。如果看到GET http://archive.ubuntu.com/ubuntu/dists/precise/Release那就坐实了源未替换干净。5.2 “nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)” 的根源分析这个错误意味着 80 端口已被其他进程占用。在 Ubuntu 12.04 上最常见的“冒名顶替者”是apache2。但ps aux \| grep apache可能找不到它因为apache2可能是以www-data用户身份静默运行的。更可靠的排查方法是# 查看所有监听 80 端口的进程需要 root 权限 sudo lsof -i :80 # 或者 sudo netstat -tulnp \| grep :80 # 如果看到 apache2彻底卸载它避免残留 sudo apt-get purge apache2 apache2-utils apache2.2-bin apache2-common sudo apt-get autoremove另一个隐蔽的占用者是lighttpd或hiawatha这类轻量 Web 服务器它们常被某些旧版 CMS 自动安装。lsof -i :80的输出会明确显示进程名和 PIDsudo kill -9 PID即可释放端口。5.3 “502 Bad Gateway” 的三层穿透式排查当你把 Nginx 配置为反向代理proxy_pass时“502 Bad Gateway” 是最令人抓狂的错误。它只说明“上游服务没响应”但不告诉你为什么。我们必须像剥洋葱一样一层层深入第一层Nginx 自身是否能连通上游# 用 curl 模拟 Nginx 的请求使用相同的 Host 头 curl -H Host: your-upstream-domain.com http://127.0.0.1:8080 # 如果返回 502 或超时说明上游服务根本没起来或端口不对第二层上游服务是否真的在监听# 检查上游服务如 Node.js是否在监听 8080 sudo netstat -tuln \| grep :8080 # 如果没有输出说明上游服务没启动或绑定到了 127.0.0.1 而不是 0.0.0.0第三层Nginx 的 proxy_timeout 设置是否过短在location块中添加proxy_connect_timeout 60; proxy_send_timeout 60; proxy_read_timeout 60;Ubuntu 12.04 的nginx-full默认proxy_read_timeout是 60 秒但如果上游服务启动很慢比如 Java 应用这个值可能不够。将其调大到 300 秒能有效避免“上游还没准备好Nginx 就已放弃”的情况。5.4 “Nginx 启动后立即退出/var/log/nginx/error.log 为空”的终极解法这是一个经典的“幽灵故障”。service nginx start显示成功但ps aux \| grep nginx看不到进程error.log也空空如也。根本原因在于Nginx 的主进程在启动时会尝试创建/var/run/nginx.pid文件而/var/run是一个 tmpfs内存文件系统它在每次重启后都会清空。如果 Upstart 的pre-start script没有提前创建/var/run/nginx.pid的父目录/var/run/nginxNginx 就会因Permission denied而静默退出。解法极其简单sudo mkdir -p /var/run/nginx sudo chown root:root /var/run/nginx sudo chmod 0755 /var/run/nginx然后再次sudo service nginx start。这个目录创建步骤在 Ubuntu 12.04 的nginx-common包中本应由postinst脚本自动完成但由于 old-releases 的包可能有微小差异手动补上是最稳妥的。6. 进阶思考从 Precise 到现代 Nginx 的演进启示Ubuntu 12.04 上的 Nginx 安装表面上看是一次技术考古实则是一堂关于“软件生命周期”的实践课。它教会我们