简介：针对无外网或内网受限的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-devel |
| gzip压缩传输 | --with-http_gzip_static_module | zlib、zlib-devel |
| HTTPS/TLS | --with-http_ssl_module | openssl、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-utils |
| yum 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 2>&1 || 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 \ --user=nginx \ --group=nginx各参数含义如下：--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] Description=nginx web server After=network.target [Service] Type=forking 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 PrivateTmp=true [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable --now nginxnginx以master-worker模式运行，master进程启动后fork出worker，所以Type=forking。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进程以--user=nginx身份运行，而html目录或日志目录的属主还是root，nginx用户没有读取权限。解决方法是调整目录属主：
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 installed
rpm集合在当前机器装完正常，但换到另一台机器执行时提示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_fails=2 fail_timeout=30s; 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应用，我都强制自己按这套顺序过一遍，不给自己留碰运气式安装的空间。离线环境特殊，提前把依赖备齐并验证透，省的是后面排错的时间。希望这份操作路径对你也有帮助。
本文还有配套的精品资源，点击获取
