简介面向网络受限环境下的Linux服务器运维人员这份离线安装包将gcc编译环境和Nginx服务所需的rpm依赖集合统一打包并附有清晰安装指引可在无外网的数据中心、内网隔离区或临时环境中快速完成部署。包体共4个文件3个gz压缩包分别对应gcc编译工具链、Nginx运行时依赖与Nginx源码另含1个html文档按顺序说明依赖安装、配置要点和启动验证整体约62.15MB结构简洁、便于分发。目前已有1682人学习下载特别适合需要为Java后端搭建反向代理或静态文件服务的场景无论是初级运维照着操作还是老手批量部署都能省去逐一下载缺失依赖的烦恼。借助该资源还能有效规避版本不兼容导致的安装失败在无网条件下快速获得高性能Web服务能力。1. nginx离线安装为什么绕不开这套rpm包集合在内网服务器上部署nginx最磨人的不是nginx本身而是它背后的编译依赖。很多环境连外网都出不去yum install直接报错这时候如果手里没有一套完整的离线rpm包整个部署就会卡死在第一步。本文说的就是这件事把gcc、make、pcre、zlib、openssl这些nginx源码编译必需的依赖提前收集成rpm集合在目标机器上一条命令装齐然后顺利configure、make、install跑通一个能开机自启、能代理静态页面的nginx。这套离线方案适合三类人刚接手内网系统的运维、需要批量初始化多台服务器的实施工程师以及被安全审计卡住、必须在物理隔离环境里完成web服务部署的开发。接下来的每一章都按实际落地顺序推进中间会穿插我在不同发行版上反复踩过的坑包括缺库、版本冲突、防火墙和SELinux的干扰。读完你应该能自己做出一个离线rpm仓库并且对nginx的编译选项有足够清晰的把握。2. 离线依赖盘点nginx编译到底需要哪些rpm2.1 依赖分层的逻辑先编译链再功能库nginx源码安装需要编译器这是第一层依赖。gcc负责把C代码编成目标文件gcc-c负责处理少量使用C语法的模块make则驱动整个构建过程。没有这三样configure脚本根本跑不起来。第二层是功能库nginx的URL重写模块依赖pcregzip模块依赖zlibHTTPS服务依赖openssl。它们分别对应pcre-devel、zlib-devel和openssl-devel三个开发包。注意这里的devel后缀不能省因为nginx编译时需要的是头文件而不只是运行时库。第二层依赖往往是初学者最容易翻车的地方。有人只装了pcre没装pcre-develconfigure阶段直接报“the HTTP rewrite module requires the PCRE library”。这不是缺库是缺头文件。rpm包集合里必须同时包含运行库和开发库缺哪个都不行。我一般会先在一台能联网的同版本系统上用yum把依赖拉下来再搬到内网机器上装这样版本和依赖关系都是系统自己解析好的不会出现手动rpm -ivh时顺序混乱的问题。2.2 基础rpm集合清单最小化但够用在CentOS 7或相似版本的系统上我常用的基础rpm集合包括以下这些包gcc、gcc-c、make、pcre、pcre-devel、zlib、zlib-devel、openssl、openssl-devel再加上kernel-headers和glibc-headers这类编译时会被间接依赖的基础包。实际操作中你不需要手敲这一长串包名而是用yumdownloader带着依赖解析去拉详见下一章。这里先把清单列出来方便你在收集完成后逐一核对。文件清单形式包名用途是否含develgccC语言编译否gcc-cC语言编译否make构建工具否pcre / pcre-devel正则表达式与rewrite模块是zlib / zlib-develgzip压缩模块是openssl / openssl-develHTTPS与SSL模块是glibc-headers / kernel-headers系统底层头文件是2.3 版本匹配的常用判断原则离线安装最怕版本号对不上。nginx对pcre和openssl的版本并不挑到极端严格的程度但要注意操作系统本身的openssl版本如果过旧某些nginx模块可能在编译期能过运行期遇到特定TLS版本才出问题。我的判断原则是优先与目标系统自带的系统库版本保持一致而不是追新。因为内网系统往往还跑着其他业务贸然替换系统级别的openssl或zlib可能引发其他程序连锁异常。nginx可以通过静态编译的方式把部分库编进二进制里但这会增加维护成本不推荐默认这么做。提示如果你面对的是CentOS 6这类老系统建议先确认系统自带gcc版本是否过旧。过旧时要么换新系统要么准备更高版本的devtoolset否则nginx某些新模块会干脆不支持。老系统上的离线部署时常会败在编译器版本上这不是玄学是平铺直叙的客观限制。3. 把依赖打成离线包本地yum仓库的构建与核对3.1 如何用yumdownloader一次性拉全依赖在能联网的一台机器上用yumdownloader命令是最省事的收集方式。这个工具来自yum-utils如果没有就先用yum install -y yum-utils装好。它的核心能力是解析依赖关系把指定包和它们依赖的包一起下载到本地目录。注意要加上--resolve参数否则只下载指定的几个rpm不会处理它们的依赖链。# 创建保存rpm的目录 mkdir -p /opt/nginx-offline-rpms cd /opt/nginx-offline-rpms # 用yumdownloader拉取nginx编译所需依赖及全部依赖链 yumdownloader --resolve --destdir/opt/nginx-offline-rpms \ gcc gcc-c make \ pcre pcre-devel zlib zlib-devel \ openssl openssl-devel参数说明--resolve让yum自动解析每个包的所有依赖并一并下载--destdir指定输出目录。执行后你会看到类似“examining xxx: gcc-4.8.5-44.el7.x86_64.rpm”的输出这就是yum在逐个解析依赖链。下载完成后建议检查一下目录里的rpm数量通常会在60到80个之间因为gcc和openssl本身还会带出大量底层依赖。3.2 创建本地yum仓库createrepo的关键步骤rpm包收集完成后裸用rpm -ivh逐个安装会非常痛苦几十个包存在相互依赖必须按顺序安装。更理性的做法是建一个本地yum仓库让yum自动解析依赖顺序。createrepo就是用来生成仓库元数据的工具。# 安装createrepo工具 yum install -y createrepo # 在rpm目录下生成仓库元数据 createrepo /opt/nginx-offline-rpms # 验证仓库元数据是否生成成功 ls -l /opt/nginx-offline-rpms/repodata/createrepo执行完毕后会在目录下生成repodata文件夹里面是仓库的索引文件。生成的仓库可以拷贝到U盘或直接拷贝到目标机器放任意路径都行。然后在内网机器上写一个指向该目录的repo文件yum install就能像联网环境一样自动解析依赖顺序了。这个技巧的价值在于你不需要关心这几十个rpm谁先谁后yum全包了。3.3 内网机器的repo配置与安装验证# 在目标机器上创建repo文件 vi /etc/yum.repos.d/nginx-local.repo # 内容如下 [nginx-local] namenginx offline rpm repo baseurlfile:///opt/nginx-offline-rpms enabled1 gpgcheck0gpgcheck0必须设置因为离线收集的rpm包多半没有对应的官方签名信息。设置完成后先执行yum clean all清空缓存再试装一遍看依赖解析是否顺畅。# 清空yum缓存 yum clean all # 测试依赖解析与安装 yum install -y gcc gcc-c make pcre-devel zlib-devel openssl-devel如果这条命令没有任何报错说明本地仓库构建成功依赖链完整。这时再用rpm -qa逐一核对版本确认与目标系统匹配。我一般在确认安装成功后会把这个目录和repo文件复制一份留档下次初始化新机器直接复用能省不少时间。需要说明的是不同系统的yum版本对repo配置的写法略有差异比如部分新发行版要求repo文件中显式声明metalink或mirrorlist为空否则会尝试访问外网导致超时。后续内网机器越来越多时也可以把baseurl换成局域网内的http地址让其他机器通过内网镜像直接安装这比反复拷贝U盘要顺得多。注意用本地方案时不要只拷rpm目录而忘了repo文件否则目标机器不会自动识别这个仓库。repo文件本身就是离线仓库能用的关键很多新手在这里卡住反复手装rpm然后被依赖坑到怀疑人生。4. 执行安装从configure到启动的完整参数链4.1 configure参数的取舍原理依赖装齐之后真正编译nginx前要决定启用哪些模块。这里不是简单跑个默认configure就完事而是要想清楚这台nginx将来要承担什么角色。如果核心是静态文件与反向代理我建议至少带上http_ssl_module、http_stub_status_module和stream模块其中stream模块负责TCP/UDP四层转发nginx从1.9.0起加入很多人在做负载均衡时才想起来缺了这个模块只能回头重新编译白白折腾一遍。# 解压nginx源码包 tar -zxvf nginx-1.24.0.tar.gz cd nginx-1.24.0 # 编译前配置按需启用模块 ./configure \ --prefix/usr/local/nginx \ --sbin-path/usr/local/nginx/sbin/nginx \ --conf-path/usr/local/nginx/conf/nginx.conf \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream \ --with-threads参数说明--prefix决定nginx安装根目录后续所有路径都以它为基础--with-http_ssl_module开启HTTPS支持需要openssl-devel已经安装成功--with-stream启用四层转发能力做代理时常用--with-threads用线程池处理多核环境下的并发请求对静态文件服务有明显提升。configure脚本执行后看到“Configuration summary”部分列出的module列表基本就能确认哪些模块成功编译进去了。4.2 make与make install的全过程configure通过后剩下的两步就是make和make install。这里我想强调的是make过程的报错信息是判断依赖是否真正安装成功的最后一环。如果你在make阶段看到“pcre.h: No such file or directory”那就是pcre-devel没装上如果看到“openssl/ssl.h: No such file”那就是openssl-devel缺失。这些报错的排查方式很直接缺哪个头文件就补哪个devel包补完重新configure再make。# 编译nginx源码 make -j4 # 安装到指定目录 make install # 检查nginx二进制是否生成 ls -l /usr/local/nginx/sbin/nginx-j4表示用4个线程并行编译机器核数少可以改成-j2或直接make。make install将编译好的文件安装到prefix指定的目录。执行完ls命令看到nginx可执行文件说明编译链整体是通的。这时候别急着启动先确认一下版本号和编译参数是否与预期一致。4.3 启动与开机自启的完整配置第一次启动nginx建议用-t先测试配置文件语法这是最廉价的事故预防手段。配置测试通过后启动nginx再用curl做本地验证。开机自启我习惯写一个systemd服务文件因为内网服务器重启后nginx必须自动拉起这是生产环境的刚需。# 测试配置文件语法 /usr/local/nginx/sbin/nginx -t # 启动nginx /usr/local/nginx/sbin/nginx # 查看nginx进程状态 ps -ef | grep nginx # 本地请求验证服务是否响应 curl http://127.0.0.1/# 创建systemd服务文件 vi /etc/systemd/system/nginx.service # 内容如下 [Unit] Descriptionnginx - high performance web server Afternetwork-online.target remote-fs.target nss-lookup.target Wantsnetwork-online.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid 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# 重新加载systemd配置并启用开机自启 systemctl daemon-reload systemctl enable nginx.service systemctl start nginx.service参数说明Typeforking表示nginx主进程会fork出worker进程systemd需要根据PIDFile跟踪主进程状态ExecStop用nginx -s quit做优雅退出比暴力kill更能保证请求不中断。启用成功后用systemctl status nginx命令能看到active (running)状态这样即使内网机器意外重启nginx也会自己找回来。5. 离线安装依赖与编译的常见问题排查4条血泪经验5.1 系统自带openssl被替换导致yum故障现象我在某台机器上为了装新版openssl直接编译安装了到/usr/local/openssl然后把系统openssl的软链接替换了。结果第二天执行yum报错无法解析https源系统里一堆依赖openssl的软件也开始报错。原因系统yum和curl依赖的是系统自带的openssl库路径手动替换成新版本后库版本或ABI不兼容导致原有程序加载失败。解决最终通过恢复系统自带openssl并重装受影响包才恢复。现在我的习惯是nginx编译时通过--with-openssl指向额外下载的源码目录不碰系统openssl。这样nginx有了新版TLS特性系统库保持原样两边互不干扰。5.2 configure报错CRITICAL: pcre not found现象configure阶段报“the HTTP rewrite module requires the PCRE library”但rpm -qa已经看到pcre已安装。原因只装了pcre主包没装pcre-devel头文件缺失。编译nginx需要的是开发头文件pcre.h而运行时才需要libpcre.so主包不带头文件。解决执行yum install -y pcre-devel重新configure。这个案例提醒我收集rpm集合时需要同时拉取主包和devel包缺一不可versus这个问题的现象虽然简单但在离线环境下因为没有网络可以随手补包常常会让整个部署停摆。5.3 make阶段找不到zlib.h现象make执行到一半报zlib.h找不到编译中断。原因zlib-devel没有安装或者安装了但configure时使用了--with-zlib指定路径而该路径并不存在。有时候是路径写错了有时候是根本没有下载zlib源码包。解决确认zlib-devel已安装后重新执行configure再make。如果依然报错检查configure参数里是否残留了旧的--with-zlib目录配置。这里要格外注意configure的缓存修改参数后必须删掉auto目录下生成的缓存文件再重新configure否则旧配置会持续干扰。5.4 SELinux阻止nginx绑定80端口现象nginx -t正常启动也提示success但外部访问始终连不上curl报connection refused。原因SELinux的httpd_can_network_connect策略没有开启nginx作为非标准web进程尝试绑定端口或进行网络转发时被拦截。解决执行setsebool -P httpd_can_network_connect 1开放网络连接权限如果nginx使用自定义端口比如8080还需要用semanage port -a -t http_port_t -p tcp 8080把端口加入SELinux放行列表。这条问题在rpm安装的场景里反而不常遇到因为rpm包装的nginx会自动打上正确的SELinux标签而源码编译安装的二进制文件则会被SELinux当成未知程序处理所以如果你用离线编译方案部署nginx这一步务必提前确认。6. 验证安装结果与扩展模块的思路nginx安装完成后用一条命令验证模块和版本信息是最快的自检手段。这条命令值得养成习惯# 查看nginx版本及编译参数 /usr/local/nginx/sbin/nginx -V-V输出里能看到configure arguments一长串内容我每次都会读一遍确认自己想要的模块都在里面。这时再用curl访问测试页面正常情况下能看到“Welcome to nginx”。如果返回403优先检查nginx运行用户对网页目录的权限这比反复重启nginx要高效得多。编译参数之外的扩展方向我通常建议先从stub_status模块开始。它提供一个内置的页面展示当前活跃连接数、请求总数等指标。在server配置里加一段location指向nginx_status即可location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; }这样配置后通过http://127.0.0.1/nginx_status就能看到Active connections、server accepts handled requests等实时数据。这是对编译模块功能的验证也是最简单的Nginx监控手段配合zabbix或prometheus的采集器可以快速画出一张基础请求量趋势图。我最后想分享的习惯是每做完一次离线部署把configure参数、安装用的rpm清单、repo配置文件都归档到一个固定目录旁边写一个readme说明系统版本和安装日期。这样半年后要扩容新机器或升级nginx时不需要重新回忆当时用了什么模块直接翻归档文件就能照着复现一遍。内网环境里时间成本往往是最贵的归档能省下大量翻工的量。希望帮到你这套离线rpm方案在你手里能跑得比我这还顺。本文还有配套的精品资源点击获取
