Nginx三种安装方式怎么选：包管理器、源码编译与容器部署

1. 先把选型这件事聊透三种装法各自站在什么位置我见过太多次这样的场景一台新机器需求是装个 Nginx 做个入口转发结果有人敲了一行apt install nginx就交付了三天后业务方要上 HTTP/2、要加一个官方源里没有的第三方模块比如某些鉴权、限流插件才发现手上一堆现成配置全得推倒重来。Nginx 的三种安装方式从来不是哪个更快敲完的问题而是这台机器未来两年会长成什么样的问题。包管理器安装、源码编译安装、容器镜像部署这三条路在二进制来源、模块裁剪、升级路径、故障排查方式上完全是三套逻辑选错了不是不能救但代价通常是把配置魔改到没人愿意维护。这篇内容想做的事很明确把三种装法的底层差异、完整操作链路、参数含义和真实踩坑点一次讲清让正在挑方案的人能当场做决策也让已经装完但心里没底的人能对照着检查一遍。读者画像大概分三类刚接手运维岗、需要在一台新机器上把服务跑起来的同学做后端开发、要在本地或者测试环境里自建一套环境验证联调的人以及手里已经有线上实例、但不确定当前这套装法是不是债的人。三类人关心的重点不同我会在每一节里把给谁看、要注意什么标出来。先说结论方向免得你看到一半才发现跑偏要稳、要快、要跟系统包管理一起升级走包管理器要把模块、编译参数、安装路径全部攥在自己手里或者需要打补丁、加第三方模块走源码编译要做环境一致性、要频繁重建、要把应用和运行时打包成一个可复制的单元走容器镜像。这三条不是互斥的同一家公司不同机器用不同装法很常见麻烦的是同一台机器上两种装法混用——这个后面单独开一节讲。1.1 从一次装完了但模块没有的故障说起我印象比较深的一次是一台跑着静态资源的机器需要开启状态页做监控采集。手快的同事直接用了系统仓库的包nginx -t一切正常配置也写进去了结果 reload 之后状态页始终 404日志里也没有报错。折腾了半小时才用nginx -V把编译参数打出来发现这个发行版打包时压根没把http_stub_status_module编进去。注意这个模块在 Nginx 里属于默认不编译的那一类想要就得在./configure时显式加--with-http_stub_status_module。系统仓库的维护者有自己的一套取舍标准他们会关掉一批非核心模块来减小包体积、降低安全面你没得选。这件事的关键不在于哪个模块而在于它揭示了一个事实包管理器安装拿到的是一个别人替你做完了取舍的成品你只是使用者源码编译拿到的是一份可以自己决定取舍的配方你是决策者。容器镜像则是第三种形态——它把配方 成品 运行时环境整体封成了一个不可变的层你换版本的方式不是升级而是换一个标签重新拉起。再补一个更常见的坑某些发行版的默认仓库版本相当保守可能还停留在 1.18 或者 1.20 这种老版本。如果你的业务需要用到较新的http_v3_moduleHTTP/3 相关或者需要stream模块里某些后期才加的指令老版本上根本无从谈起。这时候要么换官方预编译仓库要么老老实实编译——这就是选型时必须提前确认的事而不是等业务提需求时才反应。1.2 三条路的本质差异用一句话各说一遍包管理器安装本质是把 Nginx 当成系统的一个普通软件包来管理。它的优势不在安装那一刻而在后续apt upgrade或者yum update会跟着系统一起把安全补丁带上配置文件按发行版约定放在/etc/nginx/下日志交给系统的 logrotate 管systemd 单元是现成的。代价是版本受仓库限制、模块受打包策略限制、安装路径不能自定义。源码编译安装本质是你自己扮演了打包者的角色。./configure那一步决定了二进制里有什么、没有什么、装在哪儿、用哪个 OpenSSL、要不要链静态库。它的优势是极致的可控性——第三方的模块、自己打的补丁、特殊的内核特性适配全都能塞进去。代价是所有后续维护都是你的责任升级要重新编译依赖要自己盯systemd 单元要自己写出问题时没有现成的文档可查。容器镜像部署本质是把 Nginx 从装在机器上的软件变成跑在机器上的进程单元。配置、日志、证书全部通过挂载点从宿主机注入镜像本身保持无状态。它的优势是可复制性——同一份镜像 同一份配置在开发机、测试机、生产机上跑出来的行为是一致的。代价是多了一层网络和文件系统的抽象调试链路变长而且容器里的 Nginx和宿主机上的 Nginx在日志、权限、文件句柄这些问题上的表现不完全一样。1.3 一张对照表把选型钉死光靠文字描述容易记混我习惯直接摆一张表对着自己的场景勾选。维度包管理器安装源码编译安装容器镜像部署上手速度最快一条命令中等需装依赖跑编译快前提是环境已有容器运行时版本可控性受仓库限制完全自主想用哪个版本用哪个由镜像标签决定切标签即可模块可控性受打包策略限制完全自主任意增删官方镜像已含常用模块扩展需自建镜像升级方式包管理器统一升级重新编译 替换二进制拉新镜像 重建容器配置位置/etc/nginx/由--prefix决定宿主机挂载到容器内路径故障排查路径固定日志约定清晰路径自定义需自己记录多一层容器边界需看容器日志适合场景通用 Web 服务、长期稳定运行定制化需求强、要打补丁、要特定模块环境一致性要求高、频繁重建、多环境同步表格只是起点真正决定的是那几个硬约束。比如你的合规要求必须在特定操作系统版本上跑、并且不能引入额外的运行时那容器路线直接出局比如你的业务需要一个只有第三方提供的限流模块那包管理器路线直接出局比如你需要把同一套配置在十几台机器上保持一致而且频繁重建那源码编译的维护成本会让你崩溃。提示不要在还没确认未来半年会不会加模块、会不会换版本之前就定方案。这三个问题里只要有一个答案是会包管理器路线基本可以排除。2. 包管理器路线落地最快也最容易攒下版本债这条路线是绝大多数人的第一选择也确实是三条路里最省事的。但省事和省心是两回事我见过太多机器装完之后就再没人管过三四年过去仓库里的版本停留在某个早已停止维护的分支上等到某天需要升级时才发现配置语法、模块、依赖全都对不上。这一节我把完整链路和这条路上最常见的几个坑拆开讲。2.1 仓库里的那个包究竟是从哪儿来的很多人以为apt install nginx和yum install nginx拿的是同一份东西实际上这两个命令背后对应的是两套完全不同的打包体系用的编译参数、模块清单、默认路径、甚至默认配置模板都不一样。同一个版本号在不同发行版上nginx -V打出来的参数可能差出一大截。这里面有个容易忽略的分层发行版官方仓库和软件官方提供的预编译仓库是两回事。前者由发行版的打包团队维护优先保证与系统其他组件的兼容性和稳定性所以版本偏保守、模块偏精简后者由软件方自己维护版本更新更快、模块更全但需要你手动把仓库地址和签名密钥加进系统的源列表里。我在实际选型时的判断标准是这样的如果这台机器跑的是纯静态资源、或者简单的请求转发对版本和模块没有任何额外要求用发行版仓库就够了省下配置源的功夫如果明确需要较新版本、或者需要某些在发行版包里被裁掉的模块那就值得多花十分钟去配官方预编译仓库因为它的参数更接近完整版。配官方源这件事本身不难但有两个细节经常被漏掉一是签名密钥的导入不加密钥的话包管理器会拒绝安装并报签名验证失败二是源地址要匹配当前系统的版本代号直接照抄别人的配置很容易对着一个不存在的路径反复报 404。这两步做完之后apt update或者yum makecache刷新一下缓存再装就是官方包了。2.2 完整操作链路与验证一步一步来下面这套流程我基本每台机器都照跑一遍顺序不要乱。第一步先看系统里有没有已经装过的版本避免重复装或者装重。用nginx -v看是否已存在用dpkg -l | grep nginx或者rpm -qa | grep nginx看包管理器里有没有记录。如果已经装了先决定是升级还是卸载重装不要直接盖上去。第二步确认端口占用。80 和 443 是最常见的冲突源用ss -lntp | grep -E :80|:443看一眼如果有别的进程占着先处理掉再装否则装完启动直接失败报错信息还很隐晦。第三步安装。以 Debian 系为例apt update apt install -y nginxRHEL 系则是yum install -y nginx如果需要官方预编译仓库就在这之前把源配好装的时候包管理器会自动挑版本更高的那个。第四步验证三件事缺一不可。一是版本nginx -v确认装的是你预期的版本。二是编译参数nginx -V注意是大写把输出完整看一遍重点确认有没有你需要的模块。这条命令的输出里会列出所有--with-开头的参数缺失的模块在这里一目了然。三是配置语法nginx -t确认配置文件能被正确解析。第五步把服务托管起来。现在的发行版基本都是 systemdsystemctl enable --now nginx一条命令同时完成开机自启和立即启动。启动后systemctl status nginx看状态再从本机curl -I http://127.0.0.1验证响应头里有没有正常的Server字段。第六步做一次 reload 演练。改一个无关紧要的配置比如加一行注释执行nginx -s reload或者systemctl reload nginx观察是否平滑生效、工作进程是否被替换。这一步很多人跳过等到线上真要改配置时才发现 reload 失败那时候慌乱程度完全不一样。# 常用验证命令合集 nginx -v # 版本号 nginx -V # 版本 编译参数重点看模块 nginx -t # 配置语法检查 ss -lntp | grep -E :80|:443 # 端口占用 systemctl status nginx # 服务状态2.3 这条路线上的典型坑与处理方式坑一配置文件被拆得七零八落找不到真正的入口。发行版的包通常会把配置拆成nginx.conf主文件加conf.d/、sites-available/、sites-enabled/几个目录还会用include指令串起来。新手改了半天不生效往往是因为改的是sites-available里的模板而真正被加载的是sites-enabled里的软链接。判断方法很直接在主配置文件里搜include把加载链路理一遍被加载的才是活的。坑二默认站点把请求截走了。装完之后访问域名出来的是一张默认欢迎页而不是你的应用十有八九是默认站点还在生效并且优先级更高。处理办法要么删掉默认站点的软链接要么把自己的站点配置里的server_name写准。我倾向于保留默认站点但从sites-enabled里摘掉链接这样以后排查还能拿它当参照。坑三升级时被自动改动配置。某些发行版在升级包的时候会提示配置文件有变更问你要不要覆盖。这个交互在批量脚本里非常危险一旦被非交互模式自动覆盖你精心调过的配置就没了。我一般会在升级前先把整个配置目录备份一份并且在包管理器配置里明确指定配置文件保留策略让它在冲突时保留本地版本。坑四日志权限导致工作进程写不进去。有些环境做过安全加固日志目录权限被收紧主进程能起来但工作进程写日志时报权限不足请求直接 500。这类问题在nginx -t阶段是查不出来的只能看错误日志定位。我的习惯是装完之后立刻手动往日志文件写一行确认可写。注意包管理器路线的最大风险不是装错而是装完之后长期不管。如果你选了这条路务必把定期确认仓库里的版本是否还在维护期写进巡检清单别等到出问题才发现版本早就没人管了。3. 源码编译路线把每个开关都握在自己手里只要出现过一次我需要一个仓库里没有的模块你迟早会走到这条路上来。源码编译听起来吓人实际做一遍也就那么回事真正难的不是敲命令而是搞清楚./configure后面那一长串参数各自意味着什么、哪些必须加、哪些加了会带来长期维护负担。这一节我按为什么—准备—参数—落地—代价的顺序完整走一遍。3.1 什么情况下非编译不可先说清楚判断标准免得有人为了显得专业而去编译最后被维护成本反噬。下面这几种情况我认为编译是合理甚至必要的需要第三方模块。官方源码里不带某些社区维护的扩展模块比如特定的鉴权、限流、灰度分流实现这些只能通过--add-module在编译时静态链进去。这类模块没法靠装包解决是编译路线最硬的理由。需要自己打补丁。有时候上游某个行为不符合你的场景或者你想改掉某个默认值打补丁只能从源码层面做。需要精确控制依赖版本。比如你要链一个特定版本的加密库或者要求静态链接以避免运行时的库版本冲突包管理器给不了这个自由度。需要极简的二进制。有些场景对攻击面敏感希望只编入实际用到的模块把其余全部关掉。包管理器给的是一份通用够用的集合编译能给出刚好够用的集合。反过来如果以上都不成立只是想用新版本那我建议优先考虑官方预编译仓库因为它的参数已经比较完整维护成本也低得多。3.2 编译前的依赖清单缺一个都编不过编译失败百分之九十卡在依赖上而且报错信息往往指向的是某个头文件找不到不会直接告诉你缺了哪个包。我一般按功能分组来准备这样排查时也方便。基础编译工具链是必需的包括编译器、make、以及处理源码包的辅助工具。正则表达式支持需要对应的开发库Nginx 的路由匹配、server_name匹配、rewrite规则都依赖它。压缩支持需要 zlib 的开发包用于 gzip 相关功能。如果要启用加密相关功能现在是标配了需要加密库的开发包。这套东西在 Debian 系和 RHEL 系下的包名不同我列个对照照着装就行# Debian / Ubuntu 系 apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev # RHEL / CentOS 系 yum install -y gcc make pcre-devel zlib-devel openssl-devel有一个细节值得单独说较新版本的 Nginx 已经支持 PCRE2而一些老系统上装的是 PCRE1 的开发包。如果你的系统两套都有编译时可能会挑错导致某些正则语法行为不一致。我一般会显式指定用哪一套避免同一份配置在两台机器上匹配结果不同这种极其难查的问题。还有个容易被忽略的点编译机和生产机的系统版本最好一致。如果编译机是新系统、生产机是老系统编译出来的二进制可能依赖了生产机上不存在的库版本启动时直接报共享库找不到。要么保证环境一致要么考虑静态链接关键库。3.3 configure 参数逐个拆解别照抄网上的编译教程最常见的问题是给一串巨长的参数让你照抄但从来不解释每个参数的作用。照抄的后果是你既不知道自己开了什么也不知道自己关了什么出问题时无从下手。我挑几个关键的讲透。安装路径用--prefix指定。这个值决定了二进制、配置、日志、临时文件的默认位置。我通常用/usr/local/nginx好处是跟系统包管理器的路径彻底分开不会互相覆盖。这个路径一旦定下来就不要改因为后续所有脚本、systemd 单元、日志采集配置都要引用它改了等于全部重来。运行用户用--user和--group指定。这个必须显式给否则默认用的是nobody在很多加固过的系统上这个用户没有 shell、权限也受限工作进程会各种失败。我习惯单独建一个专用账户只给它必要目录的读权限不给登录能力。功能模块这一块是重点。--with-http_ssl_module用于启用加密传输现在属于必选项。--with-http_v2_module用于启用 HTTP/2如果你的入口层要承载现代浏览器流量这个也建议加上。--with-http_realip_module用于在多层转发场景下从请求头里还原真实客户端地址——这一条在入口层后面还有一层转发时是刚需不加的话所有访问日志里的客户端 IP 都是上一层的地址排查问题时完全没法用。--with-http_stub_status_module用于开启状态页给监控采集用。--with-http_gzip_static_module用于直接返回预压缩好的静态文件省掉实时压缩的 CPU 开销。--with-stream用于四层转发需要做 TCP/UDP 层入口时必须有。第三方模块用--add-module指定源码目录可以加多个。这里有个硬性约束第三方模块的源码必须与当前 Nginx 版本兼容跨大版本经常编译不过报的错还都是 C 语言层面的很难看出是版本不匹配。我的做法是在文档里把Nginx 版本 每个模块版本这一组关系记下来升级时同步核对。下面是一份我常用的参数集合注释写清了每个的用途./configure \ --prefix/usr/local/nginx \ --usernginx \ --groupnginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream \ --with-pcre参数跑完之后./configure的输出末尾会有一大段汇总把哪些模块会被编进去、哪些不会列得清清楚楚。这一段一定要看完它是你确认配置是否正确的最后一道关。我见过有人跑完直接make结果发现某个--with-参数拼错了少了http_前缀之类configure 并不报错只是静默忽略最后编出来的东西缺模块。3.4 编译、安装与被 systemd 接管./configure通过之后就是make。这里加个-j参数能明显提速值是 CPU 核心数用$(nproc)自动取就行make -j$(nproc) make installmake install会按--prefix把文件铺到位。装完之后先别急着起服务做三件事。第一手动跑一次配置检查/usr/local/nginx/sbin/nginx -t。如果报找不到配置文件或者路径不对说明--prefix跟你想的不一致回到上一步核对。第二确认二进制里真的有你想要的模块/usr/local/nginx/sbin/nginx -V把输出跟./configure时的汇总对一遍。第三把服务交给 systemd 管起来。自己编译的版本系统里没有现成的单元文件需要手写一个。这一步很多人图省事直接用nginx命令起结果机器重启后服务没了或者日志被重定向到了奇怪的地方。单元文件大致长这样[Unit] Descriptionnginx web service Afternetwork.target remote-fs.target nss-lookup.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf ExecStart/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target几个细节值得注意。Typeforking配合PIDFile是因为 Nginx 默认以守护进程方式运行主进程会 fork 后退出systemd 需要靠 PID 文件来跟踪真正的主进程。ExecStartPre里放一次配置检查好处是配置文件写错时 systemd 直接拒绝启动不会出现服务显示 active 但实际没在正常干活这种迷惑状态。ExecStop用-s quit而不是-s stop是因为前者是优雅退出会等正在处理的请求完成后者是快速退出可能中断在途请求。单元文件写好放进去之后执行systemctl daemon-reload让 systemd 重新读取再systemctl enable --now nginx。之后所有的启停、重载都走 systemctl不要再用裸的nginx命令两套控制方式混着来很容易出现状态不一致。3.5 编译路线的隐性成本得提前算进去编译安装的坑不在装的时候在装完之后。我把最常见的几类列出来你在决定走这条路之前先掂量一下。升级不再是一条命令。包管理器升级是apt upgrade就完事编译安装的升级是下载新源码、重新跑一遍带全部参数的 configure、make、停服务、替换二进制、起服务。参数一旦丢了新编出来的东西就缺模块而且你很可能要到业务报错时才发现。我的做法是把完整的 configure 命令写进一个脚本存到仓库里升级时直接跑脚本不靠记忆。安全补丁要自己盯。加密库出问题时包管理器路线是等发行版发补丁包编译路线是你得自己重新编。如果编译时链的是系统里的动态库那系统升级库之后重启服务也能生效如果是静态链接就必须重新编译。这个区别在应急响应时非常关键选静态链接的人一定要清楚自己承担了什么。日志轮转要自己配。系统包自带 logrotate 配置自己编译的版本没有。日志不轮转跑几个月磁盘就满了而且这种故障往往是半夜发生。我一般是照着系统包的配置抄一份改掉路径放到 logrotate 的目录里。排查问题时没有现成文档。网上搜到的绝大多数 Nginx 问题解答默认你用的是包管理器安装的路径和布局。你用的是自定义路径照着别人的命令敲会全部落空。所以走这条路的人最好自己维护一份这台机器的 Nginx 装在哪、配置在哪、日志在哪、怎么重启的备忘写在新人也能看到的地方。4. 容器镜像路线把运行时和配置彻底拆开容器化部署 Nginx 这几年已经成了很自然的选择尤其是团队已经在用容器编排管理其他服务的时候。它解决的问题很实在环境一致性、版本切换成本、配置与镜像的解耦。但它也引入了新的问题而且这些问题在传统部署里根本不会遇到。这一节讲清楚这条路的正确姿势和几个高频坑。4.1 容器跑 Nginx解决的到底是什么问题先说它真正解决的问题别被容器化这个词带偏。最核心的价值是可复制性同一份镜像标签在任何一台装了容器运行时的机器上跑起来二进制、模块、默认配置、依赖库完全一致。这直接消灭了我本地是好的测试环境没问题生产上跑不起来这类扯皮。第二个价值是版本切换成本极低。想从当前稳定版换到另一个版本改一下标签、重新拉起容器就行不需要卸载、不需要编译、不需要担心残留文件。回滚同理把标签改回去重新拉起。这个特性在灰度验证和快速回滚场景下非常好用。第三个价值是配置与运行时的分离。镜像里只放二进制和默认配置真正的业务配置通过挂载从宿主机注入。这样做的好处是配置可以独立版本管理、独立评审、独立回滚不必为了改一行配置去重建镜像。但要说清楚它没解决的问题它不解决配置写错的问题也不解决证书过期的问题更不解决上游服务挂了的问题。容器只是一个更干净的运行环境业务逻辑上的坑一个都不会少。4.2 挂载点、配置注入与日志落盘的正确姿势容器里的 Nginx 有几个关键路径必须搞清楚否则你会遇到配置改了不生效日志找不到这类问题。官方镜像的约定大致是主配置在/etc/nginx/nginx.conf站点配置在/etc/nginx/conf.d/下静态资源根目录在/usr/share/nginx/html日志在/var/log/nginx/。一个能直接用的启动命令长这样docker run -d \ --name nginx-entry \ -p 80:80 \ -p 443:443 \ -v /data/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /data/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /data/nginx/html:/usr/share/nginx/html:ro \ -v /data/nginx/logs:/var/log/nginx \ -v /data/nginx/certs:/etc/nginx/certs:ro \ --restart unless-stopped \ nginx:stable这里面每个挂载都有讲究我逐个说。主配置文件和conf.d目录用:ro只读挂载。只读的意义在于防止容器内的进程意外改写配置——虽然 Nginx 本身不会改但万一镜像里带了什么脚本只读能兜住。更重要的是只读挂载让配置的唯一真相来源在宿主机这件事变得明确不会出现容器里改了、宿主机上没改、下次重建就丢了的尴尬。静态资源目录也建议只读。如果业务确实需要往这个目录写文件比如上传那应该单独挂一个可写目录而不是把整个根目录放开。日志目录必须可写而且要挂出来。这是最容易踩的坑不挂日志目录的话日志写在容器内部容器一删日志就没了出问题时想查都查不到。挂出来之后宿主机上的日志采集工具可以正常采集。但要注意权限问题——容器内的工作进程以某个非 root 用户运行如果宿主机上的挂载目录属主不对工作进程写不进去表现是请求正常但日志是空的。这个现象特别迷惑人因为服务看起来是好的。证书目录只读挂载。证书更新时宿主机上换掉文件容器内执行一次重载即可不需要重建容器。--restart unless-stopped这个策略值得单独提一句。它保证容器在异常退出时自动拉起同时在你手动停止之后不会被自动拉起。如果是纯粹的无状态入口服务这个策略基本是标配。4.3 一个真实可用的转发配置示例光有启动命令不够配置本身也得对。下面这份是我常用的一个入口配置骨架包含了转发、真实地址还原、超时控制这几个关键项upstream app_backend { server 10.0.0.11:8080 max_fails3 fail_timeout10s; server 10.0.0.12:8080 max_fails3 fail_timeout10s; keepalive 32; keepalive_timeout 60s; } server { listen 80; server_name example.internal; access_log /var/log/nginx/app_access.log; error_log /var/log/nginx/app_error.log warn; location / { proxy_pass http://app_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; } }几个点值得解释一下为什么这么写。upstream里配了max_fails和fail_timeout是为了让后端某台机器挂掉时能快速剔除而不是每个请求都往上面撞一次。keepalive 32配合proxy_http_version 1.1和proxy_set_header Connection 是为了让 Nginx 与后端之间复用长连接——不加这几行Nginx 到后端默认是短连接高并发下会产生大量握手开销这个优化在 QPS 上来之后差别非常明显。X-Real-IP和X-Forwarded-For这两个头是给后端应用识别真实客户端地址用的。注意容器场景下有个特殊性如果容器网络是桥接模式$remote_addr拿到的是上一跳的地址可能是容器的网关地址而不是客户端地址。所以入口层收到请求的位置必须把这些头写进去后端才能还原。这也解释了为什么编译时--with-http_realip_module那么重要——它在多层转发的场景下用于从这些头里取真实地址。超时的三个值不要照抄。proxy_connect_timeout是建立连接的超时一般给短一点5 秒足够proxy_send_timeout和proxy_read_timeout是收发数据的超时要根据后端接口的实际耗时来定。如果后端有慢接口比如导出报表要跑一分钟这里给 30 秒会直接把请求掐断用户看到的是 504。我的做法是先按业务最长耗时上浮一定比例再根据监控里的实际分布逐步收紧。4.4 容器路线上最容易忽略的三件事第一件文件句柄限制。容器的默认句柄上限可能比宿主机低高并发下会报打开文件过多。这个错误在应用日志里体现为 502 或者直接连接被拒很容易误判成后端挂了。处理办法是在启动时显式声明句柄上限或者在编排配置里调整。查当前限制的方法是在容器内看进程的 limits 文件。第二件容器内的时间与日志时间戳。如果容器时区没设对日志时间戳会跟宿主机差几个小时跨时区排查问题时能把人绕晕。我一般会在挂载配置时同时挂一份时区文件或者在编排里指定时区环境变量保证日志时间一致。第三件配置改了要重载不是重启。很多人改完挂载的配置后直接docker restart这会中断所有正在处理的连接。正确做法是先做配置检查再重载docker exec nginx-entry nginx -t docker exec nginx-entry nginx -s reload先-t再 reload这个顺序不能反。如果配置有语法错误直接 reload 会导致重载失败而某些情况下失败后旧的工作进程已经被替换服务会进入一个很尴尬的中间状态。先检查通过了再重载是最稳的做法。提示重建容器之前一定要确认配置文件的挂载路径没有写错。路径写错的后果很微妙——容器照样能启动但用的是镜像里的默认配置你会看到一个欢迎页然后怀疑人生。5. 三种方式撞在同一台机器上怎么收拾前面三节是分开讲的现实中更常见的情况是一台机器上先是apt install装了一个后来为了某个模块又编译装了一个再后来容器编排上了又跑了一个容器。三种装法共存本身不违法问题在于它们会互相干扰而且干扰方式往往很隐蔽。5.1 装重了会怎样端口、二进制与进程的三重混乱最先撞上的是端口。三个 Nginx 都想监听 80只有第一个能成功后两个启动报地址已被占用。这个还算好查看报错就能定位。更麻烦的是二进制优先级。你在命令行敲nginx到底执行的是哪一个这取决于 PATH 环境变量的顺序。系统包通常装在/usr/sbin/nginx自己编译的通常在/usr/local/nginx/sbin/nginx。如果 PATH 里/usr/local相关的目录排在前面你敲nginx跑的是编译版否则跑的是系统包版。这意味着你可能对着 A 的配置文件改了半天实际生效的是 B。这类问题极难排查因为每条命令看起来都执行成功了。进程层面也会混乱。systemd 里可能有两个不同名字的服务单元分别指向两套二进制ps aux | grep nginx一看有好几组主进程systemctl status显示的是 A 的状态你实际访问的是 B。我有一次排查一个配置不生效的问题最后发现是机器上同时跑着系统包版和容器版容器的端口映射把流量全接走了宿主机上的那个根本没参与。判断当前到底在跑哪个最可靠的办法不是看命令而是看进程和监听端口# 看谁在监听目标端口进程路径是什么 ss -lntp | grep -E :80|:443 # 看所有 nginx 进程的完整启动命令 ps -eo pid,ppid,user,args | grep [n]ginx # 看 systemd 里注册了哪些相关单元 systemctl list-units --typeservice | grep -i nginx # 容器里跑了哪些 docker ps --format table {{.Names}}\t{{.Image}}\t{{.Ports}}这四条命令跑一遍机器上的 Nginx 版图就清楚了。我建议任何接手别人机器的人第一件事就是跑这四条先搞清楚现状再动手。5.2 三种方式各自的干净卸载方式卸载这件事最怕的是删了个半吊子配置文件、日志、用户、服务单元留一堆下次装的时候互相干扰。包管理器装的用包管理器卸。apt remove nginx会保留配置文件apt purge nginx连同配置一起删。我一般先用remove卸载二进制确认没有遗漏之后再决定要不要purge配置文件——有时候配置文件里还有一些值得保留的自定义规则先备份再说。RHEL 系用yum remove nginx配置文件默认会保留。源码编译装的包管理器不认识它得手动删。步骤是先停服务、禁用 systemd 单元、删单元文件、systemctl daemon-reload然后删--prefix指定的整个目录。删之前确认一下这个目录里有没有你后来放进去的证书、脚本之类的东西。另外记得把当初为它创建的运行用户也清理掉不然系统里会留一个没人用的账户。容器装的docker rm -f删容器docker rmi删镜像。注意挂载到宿主机的目录不会被删这是好事——配置和日志还在。但如果这个目录不再需要也要一并清理否则下次部署时旧配置可能会造成干扰。不管哪种方式卸载完都建议做一次验证端口是否已释放、进程是否已退出、nginx -v是否还找得到命令。这三条都过了才算卸干净。5.3 版本治理把装了什么变成可查的记录我这些年最大的体会是技术方案的维护成本绝大部分不在第一次装对而在半年后还记得当初怎么装的。所以不管选哪条路我都会要求在机器上留一份可查的记录——不是文档系统里的那种而是就在机器上跟着机器走。记录的内容就几项用的哪种装法、版本号、nginx -V的完整输出、配置文件路径、日志路径、启停命令、升级步骤。这份东西贴在一个固定的位置比如/etc/nginx/INSTALL_NOTES或者项目仓库的运维目录里。nginx -V的完整输出尤其重要因为它是唯一能证明这台机器的二进制里到底有什么的证据。将来任何一次升级都要拿新的输出跟这份旧的对比确认模块没有减少。我见过一次升级事故就是新编的二进制少了一个模块配置里引用了这个模块的指令nginx -t直接失败服务起不来而当时没人记得旧版本是怎么编的。升级路径也要提前想清楚。包管理器路线相对简单走系统升级即可但要留意配置文件冲突。编译路线需要准备完整的 configure 参数和模块版本对照表升级前先在测试机上完整跑一遍。容器路线最轻改标签重新拉起但要注意配置是否需要跟着调整——跨大版本的配置语法变更容器路线一样会撞上。最后提一个经常被忽略的点不管用哪种装法升级前都先做一次配置备份和回滚演练。备份不只是复制配置文件还包括证书、你自定义的模块、以及当前运行的二进制。回滚演练的意思是你真的把备份恢复回去过一次确认它是可用的。没演练过的备份和没有备份区别不大。我个人的习惯是在每台机器的配置目录旁边放一个backup子目录每次改动前把整个配置目录打一个带时间戳的包。磁盘开销可以忽略但某次误删了一个 server 块之后这个习惯救了我整整一个下午。