简介面向无外网或网络受限环境下的 Linux 服务器运维人员这份资源提供了一套完整的 nginx 离线部署方案重点解决编译环境缺失与依赖包难以获取的问题。压缩包共 4 个文件以 gz 源码与依赖归档为主辅以一份 html 安装说明整体约 62.15MB便于一次性拷贝到目标机器后按说明逐步落地。内容围绕 gcc 编译套件与 nginx 依赖 rpm 集合展开覆盖从编译环境准备到 nginx 安装所需的主要依赖适合需要在内网数据中心、隔离机房中快速搭建 Web 与反向代理服务的初中级运维人员参考。已有 1683 人学习下载说明该离线组合在实际运维场景中具有一定通用性。读者可据此减少逐台联网找包的时间理清依赖安装顺序并借助说明文档完成配置与启动提升受限网络下的部署效率。1. 内网机器装 nginx为什么我每次都先翻依赖包清单上周又碰到一台不能连外网的机器要装 nginx 做静态资源服务。系统是最小化安装的 CentOS 7gcc没有pcre-devel、zlib-devel、openssl-devel一个都没有直接./configure就是一路报错。这种场景在运维里太常见了生产环境隔离、机房只开内网、客户现场不给外网权限nginx 又偏偏是绕不开的那一层。装不好会怎样最典型的就是编译到一半卡在checking for C compiler ... not found或者编译过了启动时报error while loading shared libraries服务起不来还查不出原因。这篇笔记就是给卡在这一步的开发者看的从 gcc 到 nginx 依赖 rpm 集合一步步把离线环境搭起来新手能照着走通熟手能看到版本取舍和踩坑点。2. 装前把环境盘清楚系统版本、gcc 与依赖 rpm 的对应关系离线安装 nginx 最容易翻车的地方不是 nginx 本身而是依赖链没盘清。nginx 源码编译依赖四类东西C 编译器gcc 及其依赖、PCRE正则用于location匹配、zlibgzip 压缩、OpenSSLHTTPS 支持。这四类在联网机器上一条yum install就解决了离线环境必须提前把 rpm 包凑齐而且要和目标机器的系统版本、架构严格对应。2.1 先确认目标机器的系统与架构动手之前先在目标机器上跑三条命令把底数摸清。系统大版本决定 rpm 包从哪个源取架构决定包名后缀glibc 版本决定 gcc 能不能装。# 查看系统版本确认是 CentOS 7 还是 8、Rocky 还是 Alma cat /etc/os-release # 查看架构x86_64 还是 aarch64包名后缀完全不同 uname -m # 查看 glibc 版本gcc 的 rpm 对 glibc 有最低要求 ldd --version | head -n 1/etc/os-release里的VERSION_ID是关键CentOS 7 是7CentOS 8 / Rocky 8 是8两代系统的 rpm 包不能混用。uname -m输出x86_64就取x86_64.rpm输出aarch64就得找aarch64的包拿错了装上去会报package is intended for a different architecture。ldd --version看 glibcCentOS 7 一般是 2.17CentOS 8 是 2.28gcc 的 rpm 如果要求更高版本的 glibc装的时候会直接冲突。我一般会在联网的同版本机器上先做一次对照把目标机器和联网机器的os-release、uname -m输出并排比一下确认完全一致再开始凑包。这一步多花两分钟能省掉后面半小时的依赖报错。2.2 gcc 及编译工具链的 rpm 清单最小化安装的系统连make都没有gcc 也不是单个包而是一串。下面这张表是我在 CentOS 7 x86_64 上实际凑过的一套缺一个都可能编译中断。包名作用是否必需gccC 编译器主包必需gcc-cC 编译器部分依赖会用到建议装glibc-develC 库头文件必需glibc-headersC 库头文件必需kernel-headers内核头文件必需libmpcgcc 依赖的数学库必需mpfrgcc 依赖的浮点库必需cpp预处理器必需make构建工具必需autoconf / automake部分源码包需要按需这些包之间有依赖顺序直接rpm -ivh *.rpm一把梭经常报Failed dependencies。常见做法是先rpm -ivh装底层库glibc、libmpc、mpfr再装 gcc 主包最后装 make。如果嫌手动排序麻烦可以用yum localinstall *.rpm让 yum 自己算依赖顺序前提是本地源配好了。2.3 nginx 三大依赖pcre、zlib、openssl 的版本取舍nginx 源码编译时./configure会去探测这三个库探测不到就报错。离线环境有两种做法装 devel 的 rpm 包或者把源码包一起带过去手动编译。前者省事后者灵活我一般优先用 rpm。pcrenginx 的rewrite、location ~正则全靠它。CentOS 7 自带的是 pcre 8.x装pcre和pcre-devel两个包。注意 nginx 1.22 之后对 pcre2 的支持更完整如果目标系统是 CentOS 8 及以上优先用pcre2和pcre2-devel。zlibgzip 压缩模块依赖装zlib和zlib-devel。这个包一般系统自带但最小化安装可能没有 devel。openssl要开 HTTPS 就必须有openssl和openssl-devel。这里有个版本坑nginx 对 openssl 1.1.1 和 3.x 的支持在不同版本间有差异CentOS 7 自带 1.0.2够用但偏老如果要上 TLS 1.3得自己带 openssl 1.1.1 以上源码编译配置时用--with-openssl指定路径。提示pcre、zlib、openssl 的 devel 包版本要和运行库版本一致混装不同小版本容易出现头文件和库文件对不上的情况编译能过但运行时报符号找不到。3. 离线包怎么凑、怎么传、怎么装从联网机到目标机的完整链路环境盘清之后核心工作就是「凑包」和「传包」。这一步的难点不在技术在细心包要凑全、版本要对、传输过程不能损坏。我见过太多次因为少一个kernel-headers或者传包时断点续传出错导致编译到一半失败回头重来。3.1 在联网机器上用 yumdownloader 凑齐 rpm最稳的凑包方式是在一台和目标机器同版本、同架构的联网机器上用yumdownloader把包和依赖一起下载下来。yumdownloader属于yum-utils先装上。# 安装 yum-utils拿到 yumdownloader 和 repotrack yum install -y yum-utils # 建一个目录专门放包 mkdir -p /tmp/nginx-offline/packages cd /tmp/nginx-offline/packages # 下载 gcc 及其全部依赖--resolve 会把依赖树一起拉下来 yumdownloader --resolve --destdir/tmp/nginx-offline/packages gcc gcc-c make # 下载 nginx 三大依赖的 devel 包 yumdownloader --resolve --destdir/tmp/nginx-offline/packages \ pcre pcre-devel zlib zlib-devel openssl openssl-devel--resolve是关键参数它会把指定包的依赖递归下载避免只下主包漏掉依赖。--destdir指定输出目录所有 rpm 会平铺在这个目录里。如果依赖树很深yumdownloader偶尔会漏这时候用repotrack更彻底# repotrack 会把完整依赖树全部下载适合依赖复杂的场景 repotrack -p /tmp/nginx-offline/packages gcc gcc-c make pcre-devel zlib-devel openssl-develrepotrack的-p指定下载目录它比yumdownloader --resolve更激进会把所有相关包都拉下来包数量多但不会漏。我一般先用yumdownloader装的时候报缺再补repotrack。nginx 源码包本身也要带上从官方下载对应版本的 tar.gz和 rpm 放一起。版本选择上稳定版优先比如 1.24.x 或 1.26.x不要追 mainline 的最新版离线环境出问题不好回退。3.2 打包传输与完整性校验包凑齐后打成 tar 包传过去。传输方式看环境U 盘、内网 scp、跳板机中转都行关键是传完要校验。# 在联网机打包同时生成 md5 清单 cd /tmp/nginx-offline tar -czvf nginx-offline.tar.gz packages/ nginx-1.24.0.tar.gz md5sum nginx-offline.tar.gz nginx-offline.tar.gz.md5 # 传到目标机后先校验再解压 md5sum -c nginx-offline.tar.gz.md5 tar -xzvf nginx-offline.tar.gz -C /opt/md5sum -c会比对清单里的哈希输出OK才说明传输没损坏。这一步别省我踩过一次 U 盘拷贝大文件尾部截断的坑解压出来的 rpm 装到一半报cpio: premature end of archive查了半天才发现是传输问题。解压到/opt/下后面统一从这个目录装。3.3 按依赖顺序安装 rpm 并验证 gcc 可用装包顺序有讲究先底层库后上层工具。手动装的话按这个顺序cd /opt/packages # 第一层基础库glibc 相关和 gcc 的数学库依赖 rpm -ivh glibc-devel-*.rpm glibc-headers-*.rpm kernel-headers-*.rpm \ libmpc-*.rpm mpfr-*.rpm cpp-*.rpm # 第二层gcc 主包和 make rpm -ivh gcc-*.rpm gcc-c-*.rpm make-*.rpm # 第三层nginx 依赖 rpm -ivh pcre-*.rpm pcre-devel-*.rpm zlib-*.rpm zlib-devel-*.rpm \ openssl-*.rpm openssl-devel-*.rpm如果顺序拿不准用yum localinstall让 yum 算# 本地目录当源yum 自动解决依赖顺序 yum localinstall -y /opt/packages/*.rpm装完立刻验证 gcc 和 make 是否可用别等到编译 nginx 时才发现工具链有问题gcc --version make --version # 编译一个最小 C 程序确认头文件和链接都正常 echo int main(){return 0;} /tmp/t.c gcc /tmp/t.c -o /tmp/t /tmp/t echo toolchain okgcc --version能输出版本号说明主包装上了但头文件缺失时编译仍会失败所以补一个最小 C 程序编译测试。输出toolchain ok才算工具链真正可用。4. 编译安装 nginxconfigure 参数怎么选、make 报错怎么读工具链就位后进入 nginx 本身的编译。这一步的坑集中在./configure的参数选择和make阶段的报错解读上。参数选错会导致模块缺失报错读不懂会让人误以为是依赖没装好其实是参数问题。4.1 configure 参数逐项说明与推荐组合nginx 的./configure参数很多离线环境常用的就那几个。先解压源码进目录然后按需组合。cd /opt tar -xzvf nginx-1.24.0.tar.gz cd nginx-1.24.0 # 推荐组合指定安装路径、开 HTTPS、开状态页、开 gzip 相关 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-pcre \ --with-zlib/usr \ --with-openssl/usr逐项说--prefix决定安装目录我习惯放/usr/local/nginx和系统包管理的路径分开卸载时直接删目录。--with-http_ssl_module开 HTTPS依赖 openssl-devel不开的话后面配 443 会报unknown directive ssl。--with-http_stub_status_module开状态页监控用得上。--with-http_gzip_static_module支持预压缩的.gz静态文件。--with-pcre、--with-zlib、--with-openssl是指定依赖路径系统装了 devel 包的话一般能自动探测到显式写上更稳。如果 openssl 是自己源码编译的高版本--with-openssl要指向源码目录而不是安装目录这是 nginx 的约定指向错了会报找不到openssl/ssl.h。./configure跑完会输出一个汇总重点看两处Configuration summary里列出的模块是否符合预期以及最后有没有error。有 error 就往上翻通常是某个 devel 包没装或路径不对。4.2 make 与 make install 阶段的典型报错解读./configure通过后make阶段仍可能报错这时候的报错信息比 configure 阶段更具体但也更容易误读。# 编译-j 按 CPU 核数并行加快速度 make -j$(nproc) # 编译成功后安装 make installmake -j$(nproc)用全部核并行编译nproc输出核数。并行编译偶尔会因为依赖顺序问题报错如果报错信息看起来莫名其妙先去掉-j单线程重跑一次能过就说明是并行竞争问题不是代码问题。典型报错一fatal error: pcre.h: No such file or directory。这是 pcre-devel 没装或路径没指定检查rpm -qa | grep pcre确认 devel 包在再确认--with-pcre路径。典型报错二undefined reference to SSL_CTX_new。这是链接阶段找不到 openssl 库通常是 openssl-devel 版本和运行库不匹配或者--with-openssl指向了错误的目录。用rpm -qa | grep openssl核对版本一致性。典型报错三make: *** No rule to make target build。这多半是./configure没跑成功或者跑在了错误的目录。确认当前目录下有Makefile没有就重新./configure。make install一般不会报错装完在--prefix指定的目录下能看到sbin/nginx、conf/nginx.conf、logs/等。4.3 安装后的目录结构与关键文件装完先认目录后面配置和排错都靠它。路径内容说明/usr/local/nginx/sbin/nginx主程序启动、停止、重载都靠它/usr/local/nginx/conf/nginx.conf主配置全局配置和 server 块/usr/local/nginx/logs/日志目录access.log、error.log、nginx.pid/usr/local/nginx/html/默认站点静态文件根目录logs/nginx.pid存主进程 PIDnginx -s reload靠它找进程。error.log是排错第一现场启动失败先看它。conf/nginx.conf里默认监听 80离线环境如果 80 被占用改listen端口再启动。5. 避坑与排查离线装 nginx 最常见的五个翻车点离线环境的坑和联网环境不一样联网时yum帮你兜底离线时每个依赖都得自己扛。下面五条是我实际踩过、也帮别人排查过的按「现象 → 原因 → 解决」记下来。5.1 现象rpm 装 gcc 报 Failed dependencies原因gcc 依赖 glibc-devel、libmpc、mpfr 等手动rpm -ivh不解决依赖顺序先装 gcc 主包就会报缺依赖。解决改用yum localinstall /opt/packages/*.rpm让 yum 算顺序或者按 3.3 节的顺序先装底层库。如果 yum 也报缺说明包没凑全回联网机用repotrack补下。5.2 现象configure 报 C compiler cannot create executables原因gcc 装上了但头文件或链接器有问题常见于只装了 gcc 主包、漏了 glibc-devel 和 kernel-headers。解决跑 3.3 节的最小 C 程序编译测试确认工具链完整。报这个错时看config.log里面会写明是哪个头文件或库找不到按提示补包。5.3 现象启动 nginx 报 error while loading shared libraries原因编译时链接的库在目标机器上不存在或版本不对典型是 openssl 或 pcre 的运行库版本和 devel 包不一致。解决ldd /usr/local/nginx/sbin/nginx看哪个库not found用rpm -qa | grep核对运行库版本补装对应版本的运行库 rpm。离线环境最容易出现 devel 包装了、运行库没装的情况。5.4 现象make 并行编译随机报错单线程能过原因make -j并行时部分目标依赖顺序不确定源码包的 Makefile 没处理好并行依赖。解决去掉-j单线程重跑或者make -j2降低并行度。这不是环境问题是构建脚本的并行安全性问题单线程能过就以单线程为准。5.5 现象nginx 起来了但访问 403 或 404原因nginx.conf里root指向的目录不存在或者index文件缺失或者 SELinux 拦截了目录访问。解决先看error.log403 常见是权限或 SELinuxgetenforce确认状态临时setenforce 0验证是不是 SELinux 问题404 检查root路径和index配置。离线环境经常忘了建站点目录root指向一个不存在的路径。6. 装完怎么验证三条命令确认 nginx 真的跑通了装完不验证等于没装。我见过太多「装完了」结果服务起不来、端口没监听、配置语法错的情况。验证分三层配置语法、进程与端口、实际请求。三层都过才算这套离线环境真正跑通。6.1 配置语法与进程状态检查先做静态检查再做动态检查。静态检查不启动服务能提前发现配置错误。# 检查配置语法-t 只测试不启动 /usr/local/nginx/sbin/nginx -t # 启动 nginx /usr/local/nginx/sbin/nginx # 确认进程在主进程和工作进程都要有 ps -ef | grep nginx | grep -v grep # 确认端口监听默认 80 ss -lntp | grep nginxnginx -t输出syntax is ok和test is successful两行才算配置没问题。启动后ps应该能看到一个 master 进程和至少一个 worker 进程只有 master 没有 worker 说明 worker 启动失败去看error.log。ss -lntp确认 80 端口处于LISTEN状态没有的话要么没启动成功要么端口被占用改了配置没生效。6.2 用 curl 做端到端请求验证进程和端口都正常最后用curl发一个真实请求确认能返回内容。# 请求本机看返回状态码和内容 curl -I http://127.0.0.1/ # 如果改了端口带上端口 curl -I http://127.0.0.1:8080/ # 看返回体前几行确认是默认页或自己的站点 curl http://127.0.0.1/ | head -n 5curl -I只看响应头返回HTTP/1.1 200 OK说明请求链路通了。返回 403 查目录权限和 SELinux返回 404 查root和index返回 502 说明反代后端有问题离线静态站点一般不会。curl拿不到响应但进程在检查防火墙firewall-cmd --list-ports看端口有没有放行。6.3 重载与开机自启的收尾验证服务跑通后还要验证重载和自启否则改配置或重启机器就露馅。# 改配置后重载不中断服务 /usr/local/nginx/sbin/nginx -s reload # 确认重载后进程还在、端口还在 ps -ef | grep nginx | grep -v grep ss -lntp | grep nginxreload是平滑重载master 进程不变worker 进程替换。重载后如果进程没了说明新配置有语法错误导致启动失败error.log里会有记录。开机自启离线环境一般写 systemd unit 或者塞进/etc/rc.local写完systemctl enable后重启一次机器验证别只 enable 不重启重启后起不来才发现 unit 文件路径写错。我现在的习惯是每装完一台离线机器nginx -t、ps、ss、curl四条命令强制走一遍少一条都不算完。有一次赶时间只跑了nginx -t就交付结果目标机器 SELinux 是 enforcingcurl直接 403回头又跑一趟。从那以后这套验证流程我一次都没省过。希望帮到你。本文还有配套的精品资源点击获取
简介面向无外网或网络受限环境下的 Linux 服务器运维人员这份资源提供了一套完整的 nginx 离线部署方案重点解决编译环境缺失与依赖包难以获取的问题。压缩包共 4 个文件以 gz 源码与依赖归档为主辅以一份 html 安装说明整体约 62.15MB便于一次性拷贝到目标机器后按说明逐步落地。内容围绕 gcc 编译套件与 nginx 依赖 rpm 集合展开覆盖从编译环境准备到 nginx 安装所需的主要依赖适合需要在内网数据中心、隔离机房中快速搭建 Web 与反向代理服务的初中级运维人员参考。已有 1683 人学习下载说明该离线组合在实际运维场景中具有一定通用性。读者可据此减少逐台联网找包的时间理清依赖安装顺序并借助说明文档完成配置与启动提升受限网络下的部署效率。1. 内网机器装 nginx为什么我每次都先翻依赖包清单上周又碰到一台不能连外网的机器要装 nginx 做静态资源服务。系统是最小化安装的 CentOS 7gcc没有pcre-devel、zlib-devel、openssl-devel一个都没有直接./configure就是一路报错。这种场景在运维里太常见了生产环境隔离、机房只开内网、客户现场不给外网权限nginx 又偏偏是绕不开的那一层。装不好会怎样最典型的就是编译到一半卡在checking for C compiler ... not found或者编译过了启动时报error while loading shared libraries服务起不来还查不出原因。这篇笔记就是给卡在这一步的开发者看的从 gcc 到 nginx 依赖 rpm 集合一步步把离线环境搭起来新手能照着走通熟手能看到版本取舍和踩坑点。2. 装前把环境盘清楚系统版本、gcc 与依赖 rpm 的对应关系离线安装 nginx 最容易翻车的地方不是 nginx 本身而是依赖链没盘清。nginx 源码编译依赖四类东西C 编译器gcc 及其依赖、PCRE正则用于location匹配、zlibgzip 压缩、OpenSSLHTTPS 支持。这四类在联网机器上一条yum install就解决了离线环境必须提前把 rpm 包凑齐而且要和目标机器的系统版本、架构严格对应。2.1 先确认目标机器的系统与架构动手之前先在目标机器上跑三条命令把底数摸清。系统大版本决定 rpm 包从哪个源取架构决定包名后缀glibc 版本决定 gcc 能不能装。# 查看系统版本确认是 CentOS 7 还是 8、Rocky 还是 Alma cat /etc/os-release # 查看架构x86_64 还是 aarch64包名后缀完全不同 uname -m # 查看 glibc 版本gcc 的 rpm 对 glibc 有最低要求 ldd --version | head -n 1/etc/os-release里的VERSION_ID是关键CentOS 7 是7CentOS 8 / Rocky 8 是8两代系统的 rpm 包不能混用。uname -m输出x86_64就取x86_64.rpm输出aarch64就得找aarch64的包拿错了装上去会报package is intended for a different architecture。ldd --version看 glibcCentOS 7 一般是 2.17CentOS 8 是 2.28gcc 的 rpm 如果要求更高版本的 glibc装的时候会直接冲突。我一般会在联网的同版本机器上先做一次对照把目标机器和联网机器的os-release、uname -m输出并排比一下确认完全一致再开始凑包。这一步多花两分钟能省掉后面半小时的依赖报错。2.2 gcc 及编译工具链的 rpm 清单最小化安装的系统连make都没有gcc 也不是单个包而是一串。下面这张表是我在 CentOS 7 x86_64 上实际凑过的一套缺一个都可能编译中断。包名作用是否必需gccC 编译器主包必需gcc-cC 编译器部分依赖会用到建议装glibc-develC 库头文件必需glibc-headersC 库头文件必需kernel-headers内核头文件必需libmpcgcc 依赖的数学库必需mpfrgcc 依赖的浮点库必需cpp预处理器必需make构建工具必需autoconf / automake部分源码包需要按需这些包之间有依赖顺序直接rpm -ivh *.rpm一把梭经常报Failed dependencies。常见做法是先rpm -ivh装底层库glibc、libmpc、mpfr再装 gcc 主包最后装 make。如果嫌手动排序麻烦可以用yum localinstall *.rpm让 yum 自己算依赖顺序前提是本地源配好了。2.3 nginx 三大依赖pcre、zlib、openssl 的版本取舍nginx 源码编译时./configure会去探测这三个库探测不到就报错。离线环境有两种做法装 devel 的 rpm 包或者把源码包一起带过去手动编译。前者省事后者灵活我一般优先用 rpm。pcrenginx 的rewrite、location ~正则全靠它。CentOS 7 自带的是 pcre 8.x装pcre和pcre-devel两个包。注意 nginx 1.22 之后对 pcre2 的支持更完整如果目标系统是 CentOS 8 及以上优先用pcre2和pcre2-devel。zlibgzip 压缩模块依赖装zlib和zlib-devel。这个包一般系统自带但最小化安装可能没有 devel。openssl要开 HTTPS 就必须有openssl和openssl-devel。这里有个版本坑nginx 对 openssl 1.1.1 和 3.x 的支持在不同版本间有差异CentOS 7 自带 1.0.2够用但偏老如果要上 TLS 1.3得自己带 openssl 1.1.1 以上源码编译配置时用--with-openssl指定路径。提示pcre、zlib、openssl 的 devel 包版本要和运行库版本一致混装不同小版本容易出现头文件和库文件对不上的情况编译能过但运行时报符号找不到。3. 离线包怎么凑、怎么传、怎么装从联网机到目标机的完整链路环境盘清之后核心工作就是「凑包」和「传包」。这一步的难点不在技术在细心包要凑全、版本要对、传输过程不能损坏。我见过太多次因为少一个kernel-headers或者传包时断点续传出错导致编译到一半失败回头重来。3.1 在联网机器上用 yumdownloader 凑齐 rpm最稳的凑包方式是在一台和目标机器同版本、同架构的联网机器上用yumdownloader把包和依赖一起下载下来。yumdownloader属于yum-utils先装上。# 安装 yum-utils拿到 yumdownloader 和 repotrack yum install -y yum-utils # 建一个目录专门放包 mkdir -p /tmp/nginx-offline/packages cd /tmp/nginx-offline/packages # 下载 gcc 及其全部依赖--resolve 会把依赖树一起拉下来 yumdownloader --resolve --destdir/tmp/nginx-offline/packages gcc gcc-c make # 下载 nginx 三大依赖的 devel 包 yumdownloader --resolve --destdir/tmp/nginx-offline/packages \ pcre pcre-devel zlib zlib-devel openssl openssl-devel--resolve是关键参数它会把指定包的依赖递归下载避免只下主包漏掉依赖。--destdir指定输出目录所有 rpm 会平铺在这个目录里。如果依赖树很深yumdownloader偶尔会漏这时候用repotrack更彻底# repotrack 会把完整依赖树全部下载适合依赖复杂的场景 repotrack -p /tmp/nginx-offline/packages gcc gcc-c make pcre-devel zlib-devel openssl-develrepotrack的-p指定下载目录它比yumdownloader --resolve更激进会把所有相关包都拉下来包数量多但不会漏。我一般先用yumdownloader装的时候报缺再补repotrack。nginx 源码包本身也要带上从官方下载对应版本的 tar.gz和 rpm 放一起。版本选择上稳定版优先比如 1.24.x 或 1.26.x不要追 mainline 的最新版离线环境出问题不好回退。3.2 打包传输与完整性校验包凑齐后打成 tar 包传过去。传输方式看环境U 盘、内网 scp、跳板机中转都行关键是传完要校验。# 在联网机打包同时生成 md5 清单 cd /tmp/nginx-offline tar -czvf nginx-offline.tar.gz packages/ nginx-1.24.0.tar.gz md5sum nginx-offline.tar.gz nginx-offline.tar.gz.md5 # 传到目标机后先校验再解压 md5sum -c nginx-offline.tar.gz.md5 tar -xzvf nginx-offline.tar.gz -C /opt/md5sum -c会比对清单里的哈希输出OK才说明传输没损坏。这一步别省我踩过一次 U 盘拷贝大文件尾部截断的坑解压出来的 rpm 装到一半报cpio: premature end of archive查了半天才发现是传输问题。解压到/opt/下后面统一从这个目录装。3.3 按依赖顺序安装 rpm 并验证 gcc 可用装包顺序有讲究先底层库后上层工具。手动装的话按这个顺序cd /opt/packages # 第一层基础库glibc 相关和 gcc 的数学库依赖 rpm -ivh glibc-devel-*.rpm glibc-headers-*.rpm kernel-headers-*.rpm \ libmpc-*.rpm mpfr-*.rpm cpp-*.rpm # 第二层gcc 主包和 make rpm -ivh gcc-*.rpm gcc-c-*.rpm make-*.rpm # 第三层nginx 依赖 rpm -ivh pcre-*.rpm pcre-devel-*.rpm zlib-*.rpm zlib-devel-*.rpm \ openssl-*.rpm openssl-devel-*.rpm如果顺序拿不准用yum localinstall让 yum 算# 本地目录当源yum 自动解决依赖顺序 yum localinstall -y /opt/packages/*.rpm装完立刻验证 gcc 和 make 是否可用别等到编译 nginx 时才发现工具链有问题gcc --version make --version # 编译一个最小 C 程序确认头文件和链接都正常 echo int main(){return 0;} /tmp/t.c gcc /tmp/t.c -o /tmp/t /tmp/t echo toolchain okgcc --version能输出版本号说明主包装上了但头文件缺失时编译仍会失败所以补一个最小 C 程序编译测试。输出toolchain ok才算工具链真正可用。4. 编译安装 nginxconfigure 参数怎么选、make 报错怎么读工具链就位后进入 nginx 本身的编译。这一步的坑集中在./configure的参数选择和make阶段的报错解读上。参数选错会导致模块缺失报错读不懂会让人误以为是依赖没装好其实是参数问题。4.1 configure 参数逐项说明与推荐组合nginx 的./configure参数很多离线环境常用的就那几个。先解压源码进目录然后按需组合。cd /opt tar -xzvf nginx-1.24.0.tar.gz cd nginx-1.24.0 # 推荐组合指定安装路径、开 HTTPS、开状态页、开 gzip 相关 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-pcre \ --with-zlib/usr \ --with-openssl/usr逐项说--prefix决定安装目录我习惯放/usr/local/nginx和系统包管理的路径分开卸载时直接删目录。--with-http_ssl_module开 HTTPS依赖 openssl-devel不开的话后面配 443 会报unknown directive ssl。--with-http_stub_status_module开状态页监控用得上。--with-http_gzip_static_module支持预压缩的.gz静态文件。--with-pcre、--with-zlib、--with-openssl是指定依赖路径系统装了 devel 包的话一般能自动探测到显式写上更稳。如果 openssl 是自己源码编译的高版本--with-openssl要指向源码目录而不是安装目录这是 nginx 的约定指向错了会报找不到openssl/ssl.h。./configure跑完会输出一个汇总重点看两处Configuration summary里列出的模块是否符合预期以及最后有没有error。有 error 就往上翻通常是某个 devel 包没装或路径不对。4.2 make 与 make install 阶段的典型报错解读./configure通过后make阶段仍可能报错这时候的报错信息比 configure 阶段更具体但也更容易误读。# 编译-j 按 CPU 核数并行加快速度 make -j$(nproc) # 编译成功后安装 make installmake -j$(nproc)用全部核并行编译nproc输出核数。并行编译偶尔会因为依赖顺序问题报错如果报错信息看起来莫名其妙先去掉-j单线程重跑一次能过就说明是并行竞争问题不是代码问题。典型报错一fatal error: pcre.h: No such file or directory。这是 pcre-devel 没装或路径没指定检查rpm -qa | grep pcre确认 devel 包在再确认--with-pcre路径。典型报错二undefined reference to SSL_CTX_new。这是链接阶段找不到 openssl 库通常是 openssl-devel 版本和运行库不匹配或者--with-openssl指向了错误的目录。用rpm -qa | grep openssl核对版本一致性。典型报错三make: *** No rule to make target build。这多半是./configure没跑成功或者跑在了错误的目录。确认当前目录下有Makefile没有就重新./configure。make install一般不会报错装完在--prefix指定的目录下能看到sbin/nginx、conf/nginx.conf、logs/等。4.3 安装后的目录结构与关键文件装完先认目录后面配置和排错都靠它。路径内容说明/usr/local/nginx/sbin/nginx主程序启动、停止、重载都靠它/usr/local/nginx/conf/nginx.conf主配置全局配置和 server 块/usr/local/nginx/logs/日志目录access.log、error.log、nginx.pid/usr/local/nginx/html/默认站点静态文件根目录logs/nginx.pid存主进程 PIDnginx -s reload靠它找进程。error.log是排错第一现场启动失败先看它。conf/nginx.conf里默认监听 80离线环境如果 80 被占用改listen端口再启动。5. 避坑与排查离线装 nginx 最常见的五个翻车点离线环境的坑和联网环境不一样联网时yum帮你兜底离线时每个依赖都得自己扛。下面五条是我实际踩过、也帮别人排查过的按「现象 → 原因 → 解决」记下来。5.1 现象rpm 装 gcc 报 Failed dependencies原因gcc 依赖 glibc-devel、libmpc、mpfr 等手动rpm -ivh不解决依赖顺序先装 gcc 主包就会报缺依赖。解决改用yum localinstall /opt/packages/*.rpm让 yum 算顺序或者按 3.3 节的顺序先装底层库。如果 yum 也报缺说明包没凑全回联网机用repotrack补下。5.2 现象configure 报 C compiler cannot create executables原因gcc 装上了但头文件或链接器有问题常见于只装了 gcc 主包、漏了 glibc-devel 和 kernel-headers。解决跑 3.3 节的最小 C 程序编译测试确认工具链完整。报这个错时看config.log里面会写明是哪个头文件或库找不到按提示补包。5.3 现象启动 nginx 报 error while loading shared libraries原因编译时链接的库在目标机器上不存在或版本不对典型是 openssl 或 pcre 的运行库版本和 devel 包不一致。解决ldd /usr/local/nginx/sbin/nginx看哪个库not found用rpm -qa | grep核对运行库版本补装对应版本的运行库 rpm。离线环境最容易出现 devel 包装了、运行库没装的情况。5.4 现象make 并行编译随机报错单线程能过原因make -j并行时部分目标依赖顺序不确定源码包的 Makefile 没处理好并行依赖。解决去掉-j单线程重跑或者make -j2降低并行度。这不是环境问题是构建脚本的并行安全性问题单线程能过就以单线程为准。5.5 现象nginx 起来了但访问 403 或 404原因nginx.conf里root指向的目录不存在或者index文件缺失或者 SELinux 拦截了目录访问。解决先看error.log403 常见是权限或 SELinuxgetenforce确认状态临时setenforce 0验证是不是 SELinux 问题404 检查root路径和index配置。离线环境经常忘了建站点目录root指向一个不存在的路径。6. 装完怎么验证三条命令确认 nginx 真的跑通了装完不验证等于没装。我见过太多「装完了」结果服务起不来、端口没监听、配置语法错的情况。验证分三层配置语法、进程与端口、实际请求。三层都过才算这套离线环境真正跑通。6.1 配置语法与进程状态检查先做静态检查再做动态检查。静态检查不启动服务能提前发现配置错误。# 检查配置语法-t 只测试不启动 /usr/local/nginx/sbin/nginx -t # 启动 nginx /usr/local/nginx/sbin/nginx # 确认进程在主进程和工作进程都要有 ps -ef | grep nginx | grep -v grep # 确认端口监听默认 80 ss -lntp | grep nginxnginx -t输出syntax is ok和test is successful两行才算配置没问题。启动后ps应该能看到一个 master 进程和至少一个 worker 进程只有 master 没有 worker 说明 worker 启动失败去看error.log。ss -lntp确认 80 端口处于LISTEN状态没有的话要么没启动成功要么端口被占用改了配置没生效。6.2 用 curl 做端到端请求验证进程和端口都正常最后用curl发一个真实请求确认能返回内容。# 请求本机看返回状态码和内容 curl -I http://127.0.0.1/ # 如果改了端口带上端口 curl -I http://127.0.0.1:8080/ # 看返回体前几行确认是默认页或自己的站点 curl http://127.0.0.1/ | head -n 5curl -I只看响应头返回HTTP/1.1 200 OK说明请求链路通了。返回 403 查目录权限和 SELinux返回 404 查root和index返回 502 说明反代后端有问题离线静态站点一般不会。curl拿不到响应但进程在检查防火墙firewall-cmd --list-ports看端口有没有放行。6.3 重载与开机自启的收尾验证服务跑通后还要验证重载和自启否则改配置或重启机器就露馅。# 改配置后重载不中断服务 /usr/local/nginx/sbin/nginx -s reload # 确认重载后进程还在、端口还在 ps -ef | grep nginx | grep -v grep ss -lntp | grep nginxreload是平滑重载master 进程不变worker 进程替换。重载后如果进程没了说明新配置有语法错误导致启动失败error.log里会有记录。开机自启离线环境一般写 systemd unit 或者塞进/etc/rc.local写完systemctl enable后重启一次机器验证别只 enable 不重启重启后起不来才发现 unit 文件路径写错。我现在的习惯是每装完一台离线机器nginx -t、ps、ss、curl四条命令强制走一遍少一条都不算完。有一次赶时间只跑了nginx -t就交付结果目标机器 SELinux 是 enforcingcurl直接 403回头又跑一趟。从那以后这套验证流程我一次都没省过。希望帮到你。本文还有配套的精品资源点击获取
