简介针对无外网或内网受限的Linux服务器环境这份nginx离线安装包为运维人员提供了一套完整的部署方案。压缩包共4个文件总大小62.15MB包含gcc.tar.gz、nginxrpm.tar.gz、nginx-1.18.0.tar.gz三个gz压缩包以及一份nginx安装.html说明文档分别对应编译工具链、nginx及其依赖包和操作指引目录结构清晰。其中gcc.tar.gz内置编译环境所需组件nginxrpm.tar.gz涵盖nginx常见模块依赖html文档则附有版本校验、排错提示等细节便于快速定位问题。已有1682人学习下载适用于数据中心内网、政务云等无法访问互联网的场景也适合刚接触linux运维的读者按文档实践。借助这套离线资料无需逐个查找依赖rpm即可完成gcc环境搭建与nginx编译安装其rpm集合还可复用于其他离线机器配合前端静态服务与Java应用如Tomcat的常见组合能显著提升服务器部署与维护效率。1. 离线环境里的nginx安装先解决依赖再谈编译nginx离线安装这件事难点从来不在nginx本身而在于它前面那一长串编译依赖。很多服务器跑在内网不能连外网yum源系统里连gcc都没有手头的nginx源码包压在那里configure一步就卡住了。这份资源正是为此准备的把gcc、gcc-c、make以及pcre-devel、zlib-devel、openssl-devel这些nginx编译阶段绕不开的rpm包集合起来拷进内网就能装。不管是给Java后端应用搭反向代理入口还是在隔离环境里重复交付服务这套流程能让你不依赖外网把nginx从源码完整装起来。接下来从依赖拆解、rpm收集到安装验证一步步过一遍我实际跑通的路径。2. 拆解nginx编译依赖gcc、pcre、zlib、openssl各管什么2.1 为什么必须先有gcc然后再谈configure源码安装nginx的标准链路是解压、configure、make、make install。configure本身是个shell脚本但它的检测逻辑不是靠猜的——它会真的编译一段小C程序放到目标系统上运行根据运行结果判断当前环境里有哪些库、版本够不够、头文件在哪个目录。这个过程没有gcc根本走不下去configure直接报错退出Makefile都不给你生成。gcc之外还需要gcc-c因为nginx的某些功能模块以及不少第三方模块是C写的只有C编译器会在make阶段再次翻车。make命令则是构建驱动的执行器负责调度编译和链接。这三个位于编译工具链最底层是离线安装nginx的第一道坎。有外网环境时一条yum groupinstall Development Tools就够但内网机器没有这个条件所以rpm集合里必须先把这三样备齐。安装后可以用一个简单命令验证工具链是否就位# 分别检查gcc、g和make是否可用 gcc --version | head -1 g --version | head -1 make --version | head -1正常输出会显示三个版本号。如果提示command not found说明对应的rpm没装进去或者环境变量PATH不对顺手rpm -qa | grep gcc看一眼包是否存在。这一步跑通之后configure才值得继续。2.2 pcre、zlib、openssl三个基础库缺哪个configure都会翻车nginx三个最常用的基础库各自管着一段明确的功能理解它们才能明白rpm集合里为什么必须有devel后缀的包。pcre负责正则表达式解析。nginx的location匹配、rewrite重写规则全部依赖pcre的能力。编译时会检测到pcre库如果只有运行时库而没有pcre-devel也就是缺少pcre.h头文件configure阶段直接报错the HTTP rewrite module requires the PCRE library。这里有个典型误区只装了pcre而漏掉pcre-devel系统看起来有库实际编译完全过不去。zlib负责gzip压缩。nginx配置里gzip on要生效编译时必须有zlib-devel。这个库相对宽容缺少时nginx不会拒绝编译只是生成的二进制里没有gzip功能等到业务方要求开压缩才发现得重新编译。离线环境重编一次代价不小rpm集合里干脆一起带上。openssl管的是HTTPS和加密。--with-http_ssl_module模块依赖openssl-devel现代部署里证书、TLS已经成了标配。缺少这个包时configure会提示找不到ssl库明确告诉你无法启用https。这三个库的rpm包和devel包是两回事。运行时库提供.so动态链接文件devel包额外提供头文件和静态链接库。nginx是编译安装只认头文件所以必须装devel版本。以下命令可以快速判断一个devel包是否装好# 检查关键头文件是否存在 ls -l /usr/include/pcre.h /usr/include/zlib.h /usr/include/openssl/ssl.h三个文件都存在nginx编译期的头文件依赖才算集体到位。2.3 根据configure参数倒推依赖清单这一步别省拿到一个nginx源码包别急着configure。先执行./configure --help把输出里的--with-*和--without-*参数扫一遍就能倒推出当前版本需要哪些系统库。常见模块和依赖的对应关系如下nginx功能模块对应configure参数需要的依赖包正则rewrite、location匹配默认启用pcre、pcre-develgzip压缩传输--with-http_gzip_static_modulezlib、zlib-develHTTPS/TLS--with-http_ssl_moduleopenssl、openssl-devel状态监控页--with-http_stub_status_module无额外依赖以上表为参考就能理解为什么rpm集合由gcc、gcc-c、make加pcre-devel、zlib-devel、openssl-devel组成。启动一个模块就多一个依赖宁可在rpm准备阶段多带几个包也不要等configure报错了再满内网找。这一步准备好后面安装就是顺水推舟的事。3. 在有外网的机器上攒rpm包两种做法与一个目录规划3.1 方法一yumdownloader --resolve把依赖一次拉全同一个局域网里找一台能联网的Linux机器最好是和目标服务器同发行版、同版本。这个机器的作用是充当rpm包生产机利用yum自身的依赖解析能力把需要的包全部拉下来。第一步是创建目录并安装yum-utils工具包mkdir -p /root/rpmcache yum install -y yum-utils然后执行yumdownloader命令注意--resolve参数是关键它会把指定包的依赖全部自动解析并下载cd /root/rpmcache yumdownloader --resolve --destdir/root/rpmcache \ gcc gcc-c make pcre-devel zlib-devel openssl-devel--destdir指定下载目录否则会散落在当前路径下。gcc gcc-c make pcre-devel zlib-devel openssl-devel这一串指定了rpm集合要覆盖的核心包。运行结束后目录里会看到几十个rpm文件其中不少是这些包的间接依赖。下载完数一下文件数量一般会在20到40个之间太少说明依赖解析有问题。3.2 方法二yum install --downloadonly攒依赖包部分发行版上yum自带--downloadonly。它的逻辑是yum正常解析依赖、计算要安装的包列表然后不执行安装只把rpm文件落到指定目录yum install --downloadonly --downloaddir/root/rpmcache \ gcc gcc-c make pcre-devel zlib-devel openssl-devel这个命令的前提是系统里有可用的yum源且源里包含上述包。注意--downloadonly在部分发行版上需要额外的yum插件支持如果命令执行时提示未知参数回去用yum-utils里的yumdownloader。对比两种方式方式优点注意点yumdownloader --resolve自动解析全部依赖一次到位需要额外安装yum-utilsyum downloadonly不需要额外插件部分发行版上支持不稳定无论用哪种下载结束后都建议回到目标系统的/root/rpmcache目录逐个确认rpm包的真实依赖情况。这一步可以在有网机器上完成提前排除内网环境的意外。3.3 传输到内网前的目录规划与检查清单下载完的rpm不能一锅炖。实践下来我会按三层目录组织这些文件方便内网安装时按批次执行rpmcache/ ├── base/ # gcc、gcc-c、make等编译工具链 ├── devel/ # pcre-devel、zlib-devel、openssl-devel └── extras/ # 上述包的间接依赖和补充库分目录手动移动文件确实费一些时间但内网环境出问题时能快速定位是哪一层缺了。传输用U盘也好、内网scp也好记得把整个目录原样拷过去不要只挑看起来像的rpm。有个强迫症级别的检查习惯在传输机子上执行一次依赖校验确认当前目录里的rpm两两之间没有缺失# 在rpmcache目录下检查所有rpm的依赖是否都在本目录或系统内 for pkg in *.rpm; do rpm -qpR $pkg /dev/null 21 || echo missing dependency info for $pkg done真正执行时rpm -qpR列出的是这个包运行时需要哪些so()文件和rpmlib依赖其中不少来自系统基础库不需要自己提供。只要确认没有报Unresolved dependency之类的关键错误这批rpm就可以进内网了。4. 内网离线安装全流程rpm顺序、configure参数与systemd接管4.1 先装基础rpm再装devel包顺序直接决定成败到达内网目标机器后不要急着一次性rpm -ivh *.rpm。rpm安装是有顺序的gcc这类编译工具链必须排在前边devel开发包排在后边。原因很简单pcre-devel等包安装时会在系统里注册自身的头文件路径而它的依赖关系里往往包含gcc相关包。顺序反了rpm会抱怨依赖不满足。先执行编译工具链的安装。这里使用的--test参数相当于预演只做依赖检查不实际安装cd /root/rpmcache/base rpm -ivh gcc-*.rpm gcc-c-*.rpm make-*.rpm --test预演没有报错后去掉--test正式安装。安装完成后不要忘记执行ldconfig刷新动态链接库缓存否则部分库文件即使存在也找不到cd /root/rpmcache/base rpm -ivh gcc-*.rpm gcc-c-*.rpm make-*.rpm ldconfig接着装devel包。这组包安装后提供nginx configure阶段需要的全部头文件cd /root/rpmcache/devel rpm -ivh pcre-devel-*.rpm zlib-devel-*.rpm openssl-devel-*.rpm --test确认依赖没问题再正式执行然后再次检查关键头文件是否落位。整个安装过程都不要轻易加--nodeps那个参数不等于解决问题只等于把问题推迟到configure阶段。4.2 configure参数怎么选核心模块、安装路径和日志位置依赖就位后把nginx源码包传到内网机器解压并进入目录tar -xzf nginx-*.tar.gz cd nginx-*建议执行configure前先看一遍./configure --help确认当前版本支持哪些模块然后按需选择。实践中最常用的组合是这样./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-http_realip_module \ --usernginx \ --groupnginx各参数含义如下--prefix指定安装根目录nginx的conf、logs、sbin都会集中在这个目录下后续维护好找--with-http_ssl_module启用HTTPS接受证书、做TLS终止全靠它--with-http_stub_status_module开启监控页可以用curl拉取连接数、请求数等状态信息--with-http_gzip_static_module配合gzip静态压缩--with-http_realip_module在邮件服务器场景下常用当nginx和Java后端之间还有一层负载设备时用它来识别真实客户端IP--user和--group指定worker进程的运行身份。其中--with-http_stub_status_module可以捎带上它产出的监控页会是你排查问题时的高频工具。4.3 make、make install与systemd服务注册configure通过后会生成Makefile接着执行编译和安装make -j4 make install-j4指定用4个并行job编译内网机器CPU较差或者只有2核的改成-j2或直接去掉更稳妥。安装完成后在/usr/local/nginx/sbin/下会出现nginx二进制验证方法/usr/local/nginx/sbin/nginx -V-V会打印当前二进制编译时启用的模块参数能看到刚才传入的全部--with-*说明模块确实编进去了。接着创建nginx用户并注册systemd服务useradd -r -s /sbin/nologin nginx cat /etc/systemd/system/nginx.service EOF [Unit] Descriptionnginx web server Afternetwork.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable --now nginxnginx以master-worker模式运行master进程启动后fork出worker所以Typeforking。PIDFile路径必须和nginx.conf里的pid指令一致否则systemd会认为服务启动失败。ExecReload和ExecStop都调用nginx自身的信号参数平滑重载和优雅退出都由它内部完成。启动后跑两条命令确认进程状态systemctl status nginx ps -ef | grep nginx看到master和worker两个进程都在且systemd状态显示active (running)nginx离线安装的软件部分就算是打通了。5. 离线安装避坑指南五条血泪经验5.1 现象rpm -ivh *.rpm报conflict加--nodeps硬装后configure仍然失败某次在同一版本系统的内网机器上安装时图省事直接rpm -ivh *.rpm --nodeps --force安装过程没报错但configure依然提示找不到pcre。原因在于--nodeps跳过了依赖关系pcre本体和pcre-devel没有按正确顺序落位头文件路径没有注册进系统。解决方法是放弃暴力安装回到分批安装的流程先工具链、再devel包、后补充依赖让rpm自己维护数据库。从那以后我每次离线安装都先分好base和devel两个目录从不用--nodeps做例外安装。5.2 现象configure报错the HTTP rewrite module requires the PCRE library这是最常见的报错。原因很直接系统里只装了pcre运行时库没有pcre-devel。nginx检测pcre.h头文件时找不到。解决方法是确认rpmcache里带有python-rest报中对应的pcre-devel包然后单独安装再重新执行configure。这个坑几乎每个做离线安装的人都会撞上实际原因就是devel包缺失。5.3 现象openssl模块编译进去但nginx启动时加载失败configure时--with-http_ssl_module通过make也过了但启动日志提示cannot open shared object file相关的openssl错误。原因在于系统里openssl运行库版本与编译期用到的版本不一致编译时链接的是devel包提供的共享库路径运行时却找不到同名版本的.so文件。解决方法是检查ldd /usr/local/nginx/sbin/nginx输出里openssl相关库的路径确认LD_LIBRARY_PATH覆盖了正确目录。内网环境排查这类问题先跑ldd比什么猜测都靠谱。5.4 现象nginx启动成功但访问返回403 Forbidden服务状态正常、端口监听正常本地curl却拿到403。原因通常是nginx的worker进程以--usernginx身份运行而html目录或日志目录的属主还是rootnginx用户没有读取权限。解决方法是调整目录属主chown -R nginx:nginx /usr/local/nginx/html /usr/local/nginx/logs同理proxy_pass反代Java后端时连接后端端口也可能遇到SELinux拦截导致的Permission denied这部分要结合/var/log/nginx/error.log里的具体上下文来判断。5.5 现象换一台机器沿用同一套rpm个别包安装时报already installedrpm集合在当前机器装完正常但换到另一台机器执行时提示package already installed。原因是两台机器系统初始状态不同目标机器自带部分同名rpm。解决方法是先查询再安装rpm -qa | grep -E ^(gcc|pcre|zlib|openssl)对比输出后跳过已有包只装确实缺失的那几个。这个习惯能省下大量重复问题的时间。6. 把nginx接到Java后端proxy_pass配置与验证一气呵成6.1 一个干净的proxy_pass配置模板nginx装好只是第一步多数实际场景里它是Java后端服务的前置入口。Java应用一般监听在一个本地端口上nginx负责对外暴露80端口并按路径转发。worker_processes auto; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; upstream java_backend { server 127.0.0.1:8080 max_fails2 fail_timeout30s; keepalive 16; } server { listen 80; server_name _; location / { root /usr/local/nginx/html; index index.html index.htm; } location /api/ { proxy_pass http://java_backend; 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; } } }upstream块定义了Java后端地址127.0.0.1:8080是应用端口max_fails和fail_timeout控制后端故障时的健康检查行为。proxy_pass把/api/前缀的请求转发给后端四个proxy_set_header保证后端能拿到真实客户端IP和原始协议。keepalive 16表示每个worker进程维护16个到后端的复用连接Java应用高并发场景下能省下大量socket建立开销。6.2 验证三步走语法检查、静态资源、动态接口配置改完别直接reload先让nginx自己检查一遍语法/usr/local/nginx/sbin/nginx -t返回syntax is ok才能继续。然后分两层验证第一层确认静态页能访问第二层确认Java后端接口能透传。curl -I http://127.0.0.1/ curl http://127.0.0.1/api/health第一条命令看返回的HTTP状态码是不是200第二条命令让Java后端响应健康检查接口。如果后端接口返回502多半是后端服务没起来或者端口不对回nginx的error.log里看connect() failed的报错。顺手做一个简单的探活脚本后台定时跑#!/bin/bash code$(curl -s -o /dev/null -w %{http_code} http://127.0.0.1/api/health) if [ $code 200 ]; then echo [OK] java backend reachable else echo [FAIL] backend unreachable, check 8080 port fi这个脚本加进crontab每五分钟执行一次能第一时间捕捉到后端挂掉的情况。内网生产环境每次交付我都要走完整个流程依赖目录分类、rpm分批安装、ldconfig刷新、configure参数确认、systemd注册、proxy_pass验证。从那以后每次给新机器部署Java应用我都强制自己按这套顺序过一遍不给自己留碰运气式安装的空间。离线环境特殊提前把依赖备齐并验证透省的是后面排错的时间。希望这份操作路径对你也有帮助。本文还有配套的精品资源点击获取