离线环境部署nginx：rpm集合方案与依赖避坑全解析

简介：面向Linux服务器运维与部署场景，这套离线安装包专门解决无网络或网络受限环境下nginx快速部署的难题，涵盖gcc与nginx所需的rpm依赖集合，适合需在内网服务器、数据中心离线安装nginx的技术人员使用。压缩包共4个文件，其中3个gz格式的依赖包分别对应gcc编译环境、nginx主程序及所需rpm集合，另有1个html格式的图文安装说明，整体大小62.15MB，便于拷贝到目标机器后进行本地安装。已有1682人学习下载，不少运维人员借此规避了逐一下载依赖的麻烦。gcc作为Linux下软件编译的基础工具链，nginx则承担着高并发Web服务与反向代理职责，二者离线组合可帮助内网环境快速构建稳定服务；配合说明文档中的版本兼容性提示，能有效减少依赖冲突，为离线部署提供一套完整、可复用的操作路径。

1. nginx离线安装为什么非用rpm集合不可

我在某运营商内网做过一次nginx部署，机器不能连外网，yum源也没有，连yum install都直接超时。一开始想着源码编译，结果configure就报缺pcre，缺openssl，缺zlib，每个都得到处找rpm，而且依赖环一环套一环，找包找了一下午。后来一个运维老手扔给我一个打包好的rpm集合，里面gcc、pcre、openssl、zlib、nginx全都有，直接rpm -ivh一条命令全装上，十分钟不到就把nginx跑起来了。这套路我后来在新项目里又用了几次，每次都能把离线环境下的部署时间从小时级压到分钟级。

这篇文章就把这套rpm集合方案彻底拆开：为什么要用rpm集合而不是源码编译、每个依赖包是干嘛的、怎么在离线环境里按顺序安装、装完怎么配nginx.conf、以及那些不踩不行的坑——包括SELinux拦截、依赖顺序不对、openssl和java证书库的兼容性问题。读者是需要在隔离网络、政务云或堡垒机环境里装nginx的人，尤其是有Java后端服务要一起跑的，这篇能让你少走一整天的弯路。

2. 离线部署选型：rpm集合包是怎么攒出来的

2.1 三种离线装nginx的路线对比

我在离线环境里试过三条路，各有各的适用场景，先说结论再展开。

源码编译：需要gcc、make、pcre-devel、zlib-devel、openssl-devel全套，任何一个缺失就得去别的机器上找rpm。运气好半天搞定，运气差一周都在补依赖。优点是能定制编译参数，比如--add-module加第三方模块，但离线环境根本没这个条件，因为你缺哪个模块的源码都拉不下来。

静态编译二进制：直接把nginx编成一个大二进制文件，拷贝过去就能跑。这是资深运维的利器，但前提是你得先有一台能联网的同架构机器去编，而且glibc版本要匹配。你在一台CentOS 7上编的二进制，拿到CentOS 6上很可能直接Segmentation fault，拿CentOS 8上也未必能跑，因为glibc的符号版本对不上。

rpm集合安装：这是最能打的方案。用yumdownloader或repotrack在有网的机器上把所有rpm包拉到本地，然后拷贝到离线环境，用rpm -ivh *.rpm或者rpm -Uvh *.rpm批量安装。依赖关系在打包的时候就已经统一验证过了，不存在装到中间发现缺包的情况。我把这套流程总结成一张对比表。

离线且没有yum源的环境，选rpm集合就是最优解。前提是你能找到一台有网且系统版本一致的机器去攒包，这个前置条件一般都能满足。

2.2 rpm包清单：每个包是干什么的

这个rpm集合的核心组成我拆给你看，你拿到手别一上来就rpm -ivh *.rpm，先心里有数。

gcc：编译工具链的基础，nginx源码编译和部分扩展模块的编译都依赖它。虽然我们用rpm安装nginx本身不需要编译了，但如果后续要装一些需要编译的PHP扩展或认证模块，gcc还是得有。

pcre / pcre-devel：nginx的rewrite模块和location匹配用的就是PCRE正则库，没有它，nginx.conf里的location /xxx和rewrite规则直接失效。

zlib / zlib-devel：nginx开启gzip压缩功能时的依赖。zlib-devel里提供的头文件是编译http_gzip_module时的必需品。另外要注意，zlib的版本直接影响gzip压缩等级的性能，老版本zlib压缩效率会差不少。

openssl / openssl-devel：https证书、TLS握手全靠这个库。如果你要跑HTTPS站点，或者用nginx做TCP流量转发到Java后端，openssl版本太低会导致TLS1.3握手失败。

nginx：主包，包含nginx二进制、默认配置、启动脚本和日志轮转配置。一般会带一堆依赖，比如nginx-filesystem、nginx-filesystem-common、nginx-mod-http-*这些子包。

libxml2 / libxslt：如果编译时带上了http_xslt模块做XML/XLST转换，这两个库就有用。大部分场景用不到，但包里带着也不算多余，反正离线环境里多备几个rpm不占多少空间。

2.3 攒包命令：用yumdownloader把依赖全拉下来

这套rpm集合的攒包过程其实不复杂，核心就一条命令。我一般在一台有网的机器上执行，系统版本和离线目标机器保持一致，比如都是CentOS 7.9。

mkdir -p /root/nginx-rpms cd /root/nginx-rpms yumdownloader --resolve --destdir=/root/nginx-rpms nginx gcc pcre-devel zlib-devel openssl-devel

这段命令的逻辑是：yumdownloader负责把指定的包及其依赖全部下载到指定目录，--resolve参数会解析所有依赖关系，一次把nginx、gcc以及pcre、zlib、openssl的devel包全部拉下来。

参数说明：--resolve是核心，没加这个参数yumdownloader只会下载指定的包本身，不会把依赖带下来；--destdir指定下载目录；nginx和gcc是主包，pcre-devel、zlib-devel、openssl-devel是后续可能要用的编译依赖。

如果你跑完这条命令发现还缺包，比如提示需要libxcrypt，加一行--downloadonly再跑一遍也可以，但更推荐直接用repotrack把所有依赖一次性拉全。repotrack和yumdownloader的区别在于，repotrack会把依赖的所有版本都拉下来，包括已经安装过但版本更新的包，覆盖面更广。

repotrack nginx gcc pcre-devel zlib-devel openssl-devel

跑完之后，你会发现包里文件很多，主要是gcc的依赖也一起被拉进来了。把这些rpm打成tar包，用U盘或内网传输工具拷到目标机器，就完成攒包阶段了。拷贝完在目标机器上先看一眼有没有遗漏：

cd /root/nginx-rpms && ls -l *.rpm | wc -l

数字出来了心里就有底了，一般有20到30个rpm文件，具体数量取决于你的系统版本和gcc依赖的完整度。

3. 离线环境安装rpm集合：从检查到启动的完整步骤

3.1 先检查你的系统底线

拿到rpm集合包后，不要直接就开始装。先把目标机器的底细摸清楚，否则装到一半发现系统版本不对，所有rpm校验全失败，翻车丢人。

# 查看系统内核和发行版本 uname -a cat /etc/redhat-release # 检查系统架构 arch # 查看磁盘空间，rpm集合加nginx至少需要500MB剩余空间 df -h /root

系统版本必须和攒包机器一致或极相近。CentOS 7的rpm不能拿到CentOS 8上装，因为glibc版本不同，nginx二进制跑不起来。最常见翻车场景是把CentOS 7攒的rpm拿到Rocky Linux 8或AlmaLinux上装，报错信息基本就是libc.so.6(GLIBC_2.28)(64bit) is needed，这是glibc版本不匹配的经典信号。

架构也要对。x86_64的rpm放到ARM架构的鲲鹏服务器上，直接报wrong ELF class，这个错好认，但也容易忘，尤其是用国产化服务器的时候，拿到rpm集合前一定先arch一下。

磁盘空间给个参考值：nginx的本体rpm大约1-2MB，但gcc全家桶加依赖加起来可能要200-400MB，加上解压后的中间文件和日志文件，你想跑得舒服点别低于500MB。

3.2 按顺序安装rpm：先底座后主程序

rpm集合包里的rpm虽然已经把依赖关系找全了，但批量安装时还是要注意顺序。我一般按这个顺序来，先装编译工具链，再装库文件，最后装nginx主程序。

cd /root/nginx-rpms # 先装gcc及相关编译工具链 rpm -Uvh gcc-*.rpm glibc-*.rpm libgcc-*.rpm # 再装pcre/zlib/openssl的devel库 rpm -Uvh pcre-*.rpm pcre-devel-*.rpm zlib-*.rpm zlib-devel-*.rpm openssl-*.rpm openssl-devel-*.rpm # 最后装nginx及子包 rpm -Uvh nginx-*.rpm nginx-*.rpm

每一条命令跑完都盯着输出看一眼，有error: Failed dependencies就停下来排查。用rpm -Uvh而不是rpm -ivh的原因在于，-Uvh会处理已存在的旧版本包并做替换更新，-ivh在有旧包时会直接报文件冲突不让你装。比如系统里已经有老版本的openssl了，你再用-ivh装新版本就会遇到file /usr/lib64/libssl.so.1.1 already exists的报错，换成-Uvh就没有这个问题。

如果你不确定顺序，直接一把梭也行：

cd /root/nginx-rpms && rpm -Uvh --force --nodeps *.rpm

这条命令是暴力安装，加了--force和--nodeps，不用管依赖关系，强制把所有rpm都装上。好处是快，坏处是如果某个rpm实际和系统里已有文件冲突，会把系统搞成半残状态。我兜底的时候才用这招，建议新手一步步来更稳。

3.3 验证安装结果

装完了别急着跑nginx，先做个快速体检，确认每个关键包都装上了，版本对不对。

# 确认nginx版本 nginx -v # 确认依赖库版本 openssl version -a && rpm -qa | grep pcre && rpm -qa | grep zlib

nginx -v输出类似nginx version: nginx/1.20.1，这就说明主程序可执行。openssl version -a可以看TLS版本支持，如果输出里没看到TLS 1.3，说明openssl版本偏低（1.1.1以上才行）。

另一个实用验证是直接用rpm -qa查一下所有已装的rpm包名，确认和你要装的rpm版本完全吻合。

rpm -qa | grep -E "nginx|openssl|pcre|zlib|gcc"

输出名单里至少要能看到nginx、openssl-devel、pcre-devel、zlib-devel和gcc。缺了哪个说明对应的rpm没装上，回头查一下你是不是把对应的rpm文件漏拷了。

3.4 编辑nginx.conf：核心参数先调到位

nginx装上了但不好好配，等于白装。很多人装完nginx直接启动，也不管worker_processes和worker_connections，默认值在低配机器上能跑，但并发稍微上来就撑不住。我给你一份可以直接用的配置，按内网环境调过。

# 全局配置段：进程数和日志路径 worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; # events块：每个worker的最大连接数 events { worker_connections 10240; use epoll; } # http块：基础性能调优 http { include /etc/nginx/mime.types; default_type application/octet-stream; # 关闭版本号暴露，安全加固 server_tokens off; # 高效文件传输 sendfile on; tcp_nopush on; # keepalive超时 keepalive_timeout 65; # gzip压缩 gzip on; gzip_types text/plain text/css application/json application/javascript; # Java后端反向代理示例 upstream java_backend { server 127.0.0.1:8080 weight=3 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 80; server_name localhost; location / { proxy_pass http://java_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 5s; proxy_read_timeout 60s; } } }

worker_processes auto会让nginx按CPU核数自动创建worker进程，四核机器就有四个worker，每个worker可处理的并发连接数是worker_connections 10240，理论总并发就是四万左右。你要是机器配置一般，可以手动写1或2，避免内存占用过高。

use epoll要解释一下：这是Linux下的高性能事件驱动模型。老一点的nginx配置里可能没有这个参数，但显式写上是好事，尤其在高并发环境下，epoll比默认的select模型性能好一个数量级。

upstream java_backend就是给Java后端服务用的反向代理配置。weight=3表示这台后端服务器分配的权重，max_fails=3和fail_timeout=30s配合，30秒内失败三次就会把该后端标记为不可用。keepalive 32保持长连接，减少Java应用服务器频繁建立TCP连接的开销。

gzip_types要根据实际业务配。如果后端返回的是JSON数据，gzip_types里必须有application/json，否则一个几MB的JSON报文不压缩，内网还好，公网就惨了。我给Java服务反代时必加application/json。

3.5 启动nginx：测试配置后优雅拉起

配置改完了先测语法，不要直接启动。nginx -t这个命令的意义在于它会把你改的配置完整跑一遍语法检查，有问题提前报出来，不用启动之后才发现配置写错导致进程起不来。

# 测试配置语法 nginx -t # 没问题则启动 nginx # 查看进程是否存活 ps -ef | grep nginx

nginx -t输出nginx: configuration file /etc/nginx/nginx.conf test is successful就代表配置没问题。启动后ps看进程，一般会有一个master进程和若干个worker进程。master只负责管理，worker才是真正干活的。

启动完之后验证一下端口有没有真正监听。

ss -tlnp | grep 80 curl -I http://127.0.0.1

curl -I会发送HEAD请求拿响应头，返回HTTP/1.1 200 OK就说明nginx服务起来了。如果返回connection refused，八成是端口没监听成功，回去查配置或者防火墙。这一步别跳，本地能访问通，说明安装环节闭环了。

4. 避坑必读：离线安装nginx的常见故障排查

4.1 启动失败：nginx: [emerg] bind() to 0.0.0.0:80 failed

现象：nginx -t没问题，但启动时报bind()失败，暗示80端口被占或权限不足。
原因：最常见的两种，一种是有其他服务先占用了80端口，比如httpd、tomcat或之前装过的旧nginx；另一种是非root用户运行nginx，没有权限绑定1024以下端口。
解决：先查谁占了端口：

ss -tlnp | grep :80

输出里能看到占用端口的进程名称和PID，如果是不需要的服务就停掉：systemctl stop httpd。如果是权限问题，确认nginx进程用root启动，或者把nginx.conf里的user字段改成root（但生产环境不建议）。还有个思路是给nginx二进制加systemd启动脚本，使用root权限启动，这个在CentOS 7上比较标准。

4.2 SELinux拦截nginx访问网络或读文件

现象：nginx起来了，但curl访问一直504或403，看error.log里全是Permission denied。
原因：SELinux开启后（默认Enforcing模式），nginx的httpd_t安全上下文不允许访问某些目录，尤其是你自己新建的/opt/webroot这类非默认路径。
解决：确认SELinux状态：

getenforce

如果输出Enforcing，给nginx放行或者临时关闭：

setsebool -P httpd_can_network_connect 1

这是放行nginx访问网络，适合同一服务器反代Java后端、需要对外发起HTTP请求的场景。如果你的站点目录放在非标准位置：

chcon -R -t httpd_sys_content_t /opt/webroot

给整个目录设置正确的SELinux类型。就是把这些安全上下文修炼正确，别动不动就setenforce 0，内网机器图省事可以临时关，但生产环境开着SELinux还是安全些。

4.3 openssl兼容性坑：Java后端TLS1.3握手失败

现象：nginx反代到Java后端时，后端日志报javax.net.ssl.SSLHandshakeException: no cipher suites in common。
原因：这个坑很阴。Linux机器上装了多个版本的openssl，但Java应用服务器自带的SSL实现和系统openssl不是一回事。有时rpm集合里的openssl版本太新（比如OpenSSL 1.1.1k），和你Java环境里的JCE强度策略不匹配，导致cipher suite列表为空。还有种情况是Java启动脚本里-Djavax.net.ssl.trustStore指定的证书库没更新，旧证书库里的CA不认新openssl签发的证书。
解决：先确认Java版本和它加载的openssl：

java -version keytool -list -keystore cacerts -storepass changeit | grep -i openssl

如果证书列表里没有openssl相关的CA条目，用keytool导入：

keytool -import -alias openssl -file /etc/pki/tls/certs/ca-bundle.crt -keystore cacerts

这个操作的本质是把系统里的CA证书链导入Java信任证书库。不导入的话，Java后端做双向TLS校验时会直接拒绝nginx的证书。如果JCE策略文件过老，去替换为不限强度的策略jar包，这个别偷懒，否则后面TLS加密套件全对不上。

4.4 依赖顺序错乱：rpm -Uvh批量装到一半卡住

现象：执行rpm -Uvh *.rpm时，输出好几行error: Failed dependencies，但又不告诉你具体缺哪个包。
原因：rpm是严格按包依赖关系检查的，你一把梭安装了所有rpm，但rpm是按字母序执行的，如果某个包被反复依赖，而它的依赖包排在后面尚未安装，就会报错。
解决：不要在根目录直接rpm -Uvh *.rpm，先按顺序安装。或者用yum的localinstall解决依赖：

yum localinstall --nogpgcheck *.rpm

yum localinstall会智能解析包之间的依赖关系并按序安装，不用你手动排列。加了--nogpgcheck是跳过rpm签名校验，离线环境里rpm包来自自己的拷包，有这个参数能省掉GPG密钥导入的步骤。如果还报缺依赖，用rpm -qR nginx查看它的具体依赖列表，单独把缺失的那个包补装进去。

rpm -qR nginx | grep pcre

这个命令能让你精准看到nginx到底依赖哪个版本的pcre。rpm -qR是你的后悔药，任何依赖问题都能靠它逆向排查。

5. nginx+Java：离线环境下的反向代理配置实战

5.1 为什么要用nginx给Java服务做反代

Java后端服务，尤其是Spring Boot应用，一般都直接跑在8080端口。直接暴露8080端口给外部访问有几个问题：端口不像80/443那样能被防火墙和负载均衡器识别、无法做HTTP缓存和资源压缩、Tomcat的线程模型在高并发下容易被打满。nginx放在前面做反向代理之后，静态资源直接由nginx处理，Java服务只接收API请求，压力小很多。

离线环境和公网环境最大的区别在于，没有云负载均衡器可以买，只能靠自己服务端的软件实现。nginx的反代能力是这套rpm集合安装方案里的隐藏价值，装完nginx别只当Web服务器用，把它反代到Java后端，整体架构的抗压能力立刻上一个档次。

5.2 调优参数实战：针对Java服务的高并发配置

上一章的nginx.conf已经给出了upstream和proxy_pass的基础配置，但那是够用级别。要扛住线上流量，还得再加几个关键参数。

upstream java_backend { # 多实例负载均衡配置 server 10.0.0.11:8080 weight=3 max_fails=3 fail_timeout=30s; server 10.0.0.12:8080 weight=2 max_fails=3 fail_timeout=30s; server 10.0.0.13:8080 backup; keepalive 64; } location /api/ { proxy_pass http://java_backend; proxy_http_version 1.1; proxy_set_header Connection ""; 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; proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; client_max_body_size 20m; proxy_buffering off; }

proxy_http_version 1.1和proxy_set_header Connection ""这两个参数是配套的，目的是关闭nginx到后端之间的HTTP/1.0短连接限制，让keepalive生效。Java后端对HTTP/1.0的支持不好，如果不改这个，每次请求都要新建TCP连接，性能会下降30%以上。

X-Forwarded-For头是给Java后端获取真实客户端IP用的。Java应用服务器上的请求日志默认只记录nginx的IP，加上这个头之后配合Tomcat的remoteAddr解析机制，才能拿到真实IP。如果你做基于IP的访问控制，这个头必配。

proxy_buffering off是给WebSocket和长轮询接口用的，Java的WebSocket场景不需要nginx缓冲数据流，如果开着buffering，数据会被nginx暂存，实时性会受损害。但正常REST接口建议开启buffering（即删除这行），反而能减少nginx到Java的请求次数。

client_max_body_size 20m限制上传请求体大小，Java应用如果接收Base64图片或文件上传，这个值要根据业务调大。默认值是1m，我就是没调这个参数，某次更新头像功能突然414，排查半天发现是body大小超限。

5.3 验证反代是否生效的完整流程

配置改完后不要直接重启，按固定流程来验证。

# 第一步：语法测试 nginx -t # 第二步：优雅重载nginx进程 nginx -s reload # 第三步：从外部请求Java接口，看是否经nginx返回 curl -I http://127.0.0.1/api/health # 第四步：查看Java服务日志确认请求来源是nginx tail -f /var/log/java/app.log | grep "10.0.0.11"

第四步最关键：Java后端日志里如果记录的是10.0.0.11这样的nginx内网地址，说明反代生效。如果日志里直接是客户端IP，说明代理头配置没生效，回去检查proxy_set_header X-Real-IP那几行有没有写在location块里面。

还有个常见的肥肠玄学的场景：nginx反代配置都对了，Java接口偶尔502，查nginx error.log发现upstream prematurely closed connection。这是Java后端线程池被打满后主动断开连接了，和nginx没关系，要调的是tomcat的maxThreads参数。别一看到502就去查nginx，先到Java端看线程池和慢sql。

从那以后我每次离线装完nginx，都会强制走一遍配置、验证、日志确认的完整流程才交给业务方——配置能改，但改完不看日志等于没改，上线前至少提前一天把反代流量跑起来，验证日志文件里记录了真实的客户端IP，确认proxy_set_header真的生效再收工。这个习惯帮我挡过好几次上线翻车，希望帮到你。

本文还有配套的精品资源，点击获取