★ FEATURED ARTICLE 简介面向服务器运维与Linux系统管理人员的nginx离线部署资源包针对无外网或网络受限的数据中心环境提供从编译环境到Web服务器的一站式安装材料。压缩包共4个文件以gz压缩包为主体分别承载nginx源码、gcc编译套件及nginx所需的rpm依赖集合另附一份html格式的安装说明文档整体约62.15MB便于拷贝至目标服务器后按说明逐步部署。资源兼顾gcc编译环境搭建与nginx依赖补齐两个环节可帮助读者在断网条件下完成编译工具准备、依赖安装与nginx服务配置减少因版本不匹配或依赖缺失导致的反复排查。目前已有1683人学习下载适合需要在内网服务器上快速落地nginx、并希望保留完整离线安装链路的运维人员参考使用。1. 内网机器上装 nginx为什么我宁愿背一个 rpm 包集合进去上周又被叫去处理一台内网机器系统是最小化安装的 CentOS 7连gcc都没有yum install nginx直接卡在源不可达上。这种场景下能救命的不是一条命令而是一个提前备好的离线包集合——把 gcc 编译链和 nginx 依赖的 rpm 一次性带进去本地rpm -ivh或搭个本地源就能装完。这份资源就是干这个的它把 nginx 在 Linux 上离线安装所需的 gcc、pcre、zlib、openssl 等依赖 rpm 打包在一起适合没有外网、源不可用、又必须把 nginx 跑起来的环境。对做 Java 后端部署的人来说nginx 往往是前置网关装不上它后面的反向代理、静态资源、灰度分流全都无从谈起。下面按我实际拆包、装机的顺序讲清楚怎么用、参数怎么设、哪里会翻车。2. 先搞清楚包里有什么依赖关系与选型逻辑2.1 nginx 编译期依赖到底缺哪几个nginx 本身源码编译并不复杂真正让人卡住的是它依赖的几个库。默认./configure会检查 pcre正则用于 location 匹配和 rewrite、zlibgzip 压缩、opensslHTTPS。如果只是跑 HTTP 静态站理论上可以--without-http_rewrite_module --without-http_gzip_module绕开 pcre 和 zlib但生产环境基本不会这么干。所以离线包集合里通常包含这几类 rpm依赖类别典型包名作用是否可省编译工具链gcc、gcc-c、make、glibc-devel编译 nginx 源码用预编译 rpm 装 nginx 时可省正则库pcre、pcre-devellocation/rewrite 正则不建议省压缩库zlib、zlib-develgzip 模块不建议省加密库openssl、openssl-develHTTPS/SSL 模块不上 HTTPS 可省其他perl、libtool 等部分 configure 脚本需要视情况这里有个选型判断如果你拿到的 nginx 是官方预编译的 rpm那 gcc 这一整套其实用不上只需要运行时库但如果是源码 tar.gz就必须有 gcc 和-devel包。这份资源同时带了 gcc 和 nginx 依赖说明它面向的是「源码编译安装」这条路径这也是内网环境最可控的方式——不依赖任何外部源编译出来的二进制和本机 glibc 完全匹配。2.2 为什么不用 yum localinstall 一把梭很多人第一反应是yum localinstall *.rpm理论上 yum 会自动解析本地 rpm 之间的依赖。但内网机器上经常出现两个问题一是 yum 的 repo 配置还指向不可达的源解析依赖时会先去联网超时装到一半报错二是 rpm 包集合里如果缺了某个间接依赖比如pcre-devel依赖libstdc-develyum 会直接失败而不是跳过。我的习惯是先rpm -ivh --test做一次干跑把所有缺的依赖列出来再决定是补包还是用--nodeps谨慎跳过。--test不会真正安装只做依赖检查这是离线装机最省时间的一步。# 进入 rpm 包所在目录先做依赖干跑不实际安装 cd /opt/nginx-offline/rpms rpm -ivh --test *.rpm 21 | tee /tmp/rpm-test.log # 只看失败和缺失依赖的行快速定位缺哪个包 grep -Ei failed|requires|conflict /tmp/rpm-test.log这段命令的关键在--test参数它让 rpm 完整走一遍依赖解析和文件冲突检查但不写盘。21 | tee是为了把 stderr 也留下来因为 rpm 的依赖报错大多走 stderr。grep那行是过滤噪音正常已满足的依赖不会出现在结果里只有Failed dependencies和conflicts才需要关注。如果干跑全绿再执行真正的安装如果有缺失先看缺的是不是集合里已有但顺序不对的包——rpm 对安装顺序敏感-devel包通常要在基础库之后装。2.3 依赖安装顺序先底层库再工具链最后 nginxrpm 不像 apt 那样自动排序手动rpm -ivh时顺序错了会报「依赖的包尚未安装」。我一般按「基础运行库 → 开发库 → 编译工具 → nginx」四层来装。基础运行库指 glibc、zlib、openssl 这类开发库是带-devel后缀的编译工具是 gcc、make最后才是 nginx 本体或源码编译。如果集合里的包名带版本号用通配符批量装时要注意 shell 展开顺序稳妥做法是显式列出。# 第一层基础运行库按实际包名调整版本号 rpm -ivh zlib-1.2.7-18.el7.x86_64.rpm \ openssl-libs-1.0.2k-19.el7.x86_64.rpm \ pcre-8.32-17.el7.x86_64.rpm # 第二层开发库 rpm -ivh zlib-devel-1.2.7-18.el7.x86_64.rpm \ openssl-devel-1.0.2k-19.el7.x86_64.rpm \ pcre-devel-8.32-17.el7.x86_64.rpm # 第三层编译工具链 rpm -ivh gcc-4.8.5-44.el7.x86_64.rpm \ gcc-c-4.8.5-44.el7.x86_64.rpm \ make-3.82-24.el7.x86_64.rpm \ glibc-devel-2.17-317.el7.x86_64.rpm # 第四层验证工具链可用 gcc --version make --version每层装完都建议跑一次rpm -qa | grep 包名确认落地尤其是-devel包装没装上看ls /usr/include/pcre.h这类头文件是否存在更直接。第三层装完必须验证gcc --version因为有些最小化系统里 gcc 装了但cc软链没建configure 会报C compiler cannot create executables这时候补一个ln -s /usr/bin/gcc /usr/bin/cc就行。这个坑我在三台不同机器上遇到过两次属于典型的环境差异。3. 源码编译 nginxconfigure 参数怎么定、编译怎么排错3.1 configure 参数按业务模块裁剪别照抄全量依赖装好后解压 nginx 源码进目录跑./configure。参数不是越多越好我一般按「业务需要什么模块就开什么」来定。反向代理场景必开http_ssl_module、http_realip_module拿真实客户端 IP、http_stub_status_module监控如果做 Java 后端网关http_proxy_module是默认带的不用显式加。--prefix决定安装路径我习惯放/usr/local/nginx和系统包管理器隔离升级时直接换目录。# 解压源码并进入目录 tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 # 按业务裁剪的 configure 参数 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-pcre \ --with-zlib/usr \ --with-openssl/usr # 编译并安装-j 按 CPU 核数走 make -j$(nproc) make install参数说明--with-pcre让 nginx 用系统 pcre不指定路径时 configure 会自己找/usr/include--with-zlib和--with-openssl指向/usr是因为 rpm 装的库头文件在/usr/include、库文件在/usr/lib64如果 configure 报找不到改成--with-zlib/usr/lib64试。make -j$(nproc)用满核数编译单核机器上编译 nginx 大概两三分钟多核几十秒。make install只做文件拷贝不覆盖已有配置所以重复执行相对安全但会覆盖二进制。3.2 编译报错的三个高频位置configure 阶段最常见的报错是the HTTP rewrite module requires the PCRE library说明 pcre-devel 没装或头文件路径不对先ls /usr/include/pcre.h确认。第二个是SSL modules require the OpenSSL library同理查openssl-devel。第三个出现在 make 阶段报cc1: error: unrecognized command line option通常是 gcc 版本太老nginx 新版本要求 gcc 4.8 以上CentOS 7 自带的 4.8.5 刚好够但如果系统更老就得先升级 gcc——这也是离线包集合里带 gcc 的原因之一。# configure 失败后看 config.log 末尾的真实原因 tail -n 40 objs/autoconf.err 2/dev/null || tail -n 40 config.log # 确认头文件和库文件是否就位 ls -l /usr/include/pcre.h /usr/include/openssl/ssl.h ls -l /usr/lib64/libpcre.so /usr/lib64/libssl.soconfig.log是 configure 的黑匣子报错信息往往只给一句结论真实原因在日志末尾的checking for ...段落里。我一般直接tail看最后几十行比从头翻快。头文件和库文件两行ls是快速自检头文件在/usr/include、库在/usr/lib64是 64 位系统的标准布局如果库在/usr/lib而系统是 64 位configure 可能找不到需要加--with-ld-opt-L/usr/lib。3.3 装完先别急着改配置跑通默认页再说make install完成后/usr/local/nginx/sbin/nginx就是二进制。第一次启动前先nginx -t检查配置语法再nginx启动然后curl 127.0.0.1看是否返回默认欢迎页。这一步是分水岭能返回页面说明二进制、依赖、配置三者都对后面改配置才有意义。如果nginx -t报unknown directive多半是 configure 时没开对应模块比如配了ssl_certificate但没--with-http_ssl_module。# 语法检查 → 启动 → 本机验证 /usr/local/nginx/sbin/nginx -t /usr/local/nginx/sbin/nginx curl -I http://127.0.0.1/ # 查看进程和监听端口确认真的起来了 ps -ef | grep nginx | grep -v grep ss -lntp | grep nginxnginx -t会输出配置文件路径和syntax is ok/test is successful两行缺一行都不算过。curl -I只看响应头比curl拉全文快返回200且Server: nginx就对了。ss -lntp确认 80 端口在监听如果被别的进程占了nginx启动会报bind() to 0.0.0.0:80 failed这时候要么停掉占用进程要么改listen端口。这套验证顺序我每次都走能省掉后面「配置改了没生效」的反复排查。4. 避坑与排查离线装 nginx 最容易翻车的五个点4.1 现象rpm 装到一半报file /usr/lib64/xxx from install conflicts原因目标机器上已有同库的更高或更低版本rpm 不允许文件覆盖。解决先rpm -qa | grep 包名看已装版本如果已装版本满足 nginx 编译要求直接跳过这个包如果版本太低必须升级用rpm -Uvh而不是-ivh-U会做升级替换。千万别上来就--force那会把系统库搞成半新半旧的状态后面 yum 全乱。4.2 现象gcc --version正常但 configure 报C compiler cannot create executables原因gcc 装了但缺glibc-devel或者cc软链缺失编译器无法链接出可执行文件。解决先ls /usr/bin/cc没有就ln -s /usr/bin/gcc /usr/bin/cc再确认glibc-devel已装rpm -q glibc-devel有输出即可。这个报错信息很误导看起来像 gcc 坏了实际是链接阶段缺头文件。4.3 现象make阶段报fatal error: pcre.h: No such file or directory原因pcre-devel没装或者装的是 32 位包而系统是 64 位。解决rpm -q pcre-devel确认rpm -qi pcre-devel | grep Arch看架构是不是x86_64。离线包集合里如果混了 i686 的包装上去头文件在/usr/include但库在/usr/libconfigure 找得到头找不到库报错会更晚更隐蔽。4.4 现象nginx 启动报error while loading shared libraries: libpcre.so.1原因编译时链接了 pcre但运行时动态库路径没被 ld 识别常见于把库装到了非标准路径。解决ldd /usr/local/nginx/sbin/nginx | grep not found找出缺的库然后echo /usr/local/lib /etc/ld.so.conf.d/nginx.conf ldconfig刷新缓存。如果是 rpm 装的 pcre库在/usr/lib64一般不会缺出现这个报错多半是源码编译 pcre 装到了/usr/local/lib。4.5 现象nginx -t通过curl却返回502 Bad Gateway原因这不是 nginx 本身的问题是 upstream比如后端 Java 服务没起来或端口不对。解决先curl直连后端端口确认服务活着再查 nginx 配置里proxy_pass的地址和端口。离线环境里常见的是后端服务绑了127.0.0.1而 nginx 在另一台机器或者防火墙没放行。error.log里会有connect() failed (111: Connection refused)看日志比猜快。5. 进阶把离线包做成可复用的本地源与版本锁定单机装完只是第一步真正省事的是把这份 rpm 集合做成内网可复用的本地 yum 源以后同网段机器直接yum install走内网不用再一台台rpm -ivh。做法是装createrepo如果集合里没有得先补这个包在 rpm 目录跑一次生成元数据然后写一个 repo 文件指向file://路径。# 在 rpm 集合目录生成 repodata cd /opt/nginx-offline/rpms createrepo . # 写本地源配置 cat /etc/yum.repos.d/nginx-offline.repo EOF [nginx-offline] namenginx offline packages baseurlfile:///opt/nginx-offline/rpms enabled1 gpgcheck0 EOF # 清缓存并验证源可见 yum clean all yum repolistcreaterepo .会在当前目录生成repodata/子目录里面是包索引。baseurl用file://加绝对路径三个斜杠不能少file:///表示根路径。gpgcheck0是因为离线包通常没签名内网自用可以关但如果对完整性有要求应该给包做签名再开校验。yum repolist能看到nginx-offline且包数量对得上说明源可用之后yum install nginx就会优先从这个源解析。版本锁定是另一个容易被忽略的点。离线包集合里的 rpm 版本是固定的如果内网机器之前装过更新版本的库yum install可能因为依赖版本冲突失败。我的习惯是在 repo 文件里加priority1需要yum-plugin-priorities让本地源优先级最高同时在装机前用yum versionlock把关键包锁住避免后续误升级破坏编译环境。这套组合拳下来同一批机器重复部署的失败率能压到很低。最后说个验证习惯每次离线装完我都会跑一遍nginx -V把编译参数完整记下来存到部署文档里。因为半年后回来升级没人记得当时开了哪些模块nginx -V的输出就是唯一的后悔药。从那以后我每次交付离线环境都强制把rpm -qa的完整清单和nginx -V输出一起归档下次换机器直接照着复现不用再从头试错。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
