企业官网建设流程全解析

简介：在Linux服务器运维中，无外网或内网受限环境下部署软件常成痛点，这份离线安装资源包正是为此准备。包内含gcc与nginx的依赖rpm集合，并附带完整安装步骤说明，共4个文件，以3个压缩包和1个HTML文档为主，整体大小62.15MB，可帮助运维人员或初学Java生态的开发者在内网环境快速完成nginx部署。已有1682人学习下载，说明其实用性获得认可。通过该包可免去逐处寻找依赖的麻烦，覆盖编译环境与nginx运行所需的核心库，配合HTML说明能清晰完成解压、安装、配置与启动验证，尤其适合部署静态服务或与Tomcat等Java应用搭配的场景，有效提升系统稳定性和响应速度。

1. nginx离线安装：一大半人卡在依赖收集这一步

nginx离线安装这件事，真正卡人的从来不是nginx源码本身，而是编译前那一整条依赖链。gcc、pcre、zlib、openssl，这些包有网的时候一条命令全搞定，一旦换成内网、离线环境，缺一个就原地卡死。尤其是生产内网机器不能连外网yum源，rpm包必须提前在联网机器上备齐，带到目标机器上再装。这篇文章围绕“把gcc和nginx依赖的rpm集合做出来、传进去、装上去”这条主线走一遍，覆盖从环境盘点、离线包制作、本地yum源配置，到nginx编译、systemd注册、验证跑通的完整过程。如果你正卡在nginx离线安装的依赖问题上，照着这套流程能少踩一大半坑。

2. 离线安装前先盘家底：系统版本、nginx版本、依赖清单

2.1 确认Linux系统版本与CPU架构

离线安装的第一步不是下载rpm，而是确认目标机器的系统版本和CPU架构。同一个rpm包在不同版本、不同架构之间不通用，装错了会出现架构不匹配或者依赖不满足的报错，到时候排查起来很费劲。

cat /etc/os-release uname -m

第一行看发行版和版本号，比如CentOS 7.9这种，第二行看架构，x86_64最常见，也有aarch64的ARM机器。稍后下载rpm包时，这两个信息决定了你从哪个yum仓库拉包。如果下载机器的系统版本和目标机器不一致，比如一个CentOS 7一个是CentOS 8，rpm包不能通用，glibc版本和依赖关系都不一样。所以最稳妥的做法是：找一台和目标机器同大版本、同架构的联网机器来制作离线包。

2.2 nginx版本怎么选：稳定版优先，看重openssl兼容

nginx版本分主线版和稳定版，离线环境下我一般选稳定版。稳定版的编译依赖相对固定，网上踩坑记录多，真出问题容易搜到答案。主线版功能新，但有些新特性会牵扯出更高版本的依赖库，在老系统上反而给离线安装添麻烦。

选具体版本号之前，先看目标机器自带openssl的版本。比如CentOS 7系统上默认openssl是1.0.2系列，那nginx选1.18.0或1.20.2这类版本编译很稳，不需要额外升级openssl。如果你非要装一个依赖openssl 1.1.1特性的新版nginx，就得在离线包里额外准备openssl和openssl-devel的高版本rpm，依赖链条一下子变长，非必要不碰。顺序记住：先确认openssl，再选nginx版本，别反过来。

2.3 离线依赖rpm清单：gcc那套一个都不能少

理清依赖是离线安装的核心。nginx源码编译时必须装齐gcc编译器、make工具，以及pcre-devel（正则支持）、zlib-devel（压缩支持）、openssl-devel（HTTPS支持）这三个开发库。下面是我在CentOS 7上编译nginx 1.20.2时用到的rpm依赖集合参考：

注意nginx新版在1.19.10之后对pcre的处理方式变了，configure脚本里不再强制依赖--with-pcre参数，但pcre-devel在很多模块里仍然会被引用，稳妥起见还是放在清单里。

3. 在联网机器上制作离线rpm包集合：一台同版本机器搞定

3.1 装好yumdownloader：yum-utils是前置

yumdownloader是yum-utils工具集里的命令，它能按照yum的依赖解析逻辑，把指定软件包连同依赖一起下载到本地，而不是真的安装这些包。先确认联网机器上有没有这个工具：

which yumdownloader || yum install -y yum-utils

这条命令先检查yumdownloader是否在PATH里，不在就直接装yum-utils。注意联网机器本身必须能访问外网yum源，或者已经配好了可用的内网yum仓库。yum-utils装好后，后续批量下载才能顺畅跑起来。

3.2 批量下载gcc与nginx依赖rpm包

依赖清单确认后，第二步是把gcc相关包和nginx依赖包合并成一次下载。我用yumdownloader的--resolve参数，让yum自动处理依赖关系：

mkdir -p /data/nginx-offline-rpm cd /data/nginx-offline-rpm yumdownloader --resolve --destdir=/data/nginx-offline-rpm \ gcc gcc-c++ make pcre-devel zlib-devel openssl-devel

--resolve是核心参数，让yum解析并下载所有依赖；--destdir指定下载目录。执行完在目录里ls看一下，rpm文件应该有几十个，因为gcc这条依赖链本身就大，glibc-devel、cpp、libmpc这些会被一起拉下来。如果这一步报错，多半是yum源没有匹配系统版本，或者repo文件里的baseurl失效了，先回看第2章确认系统和源。

3.3 用createrepo建立本地yum仓库索引

rpm包放在一堆，直接用rpm -ivh逐个装也能装完，但顺序错了会报依赖不满足。我习惯先用createrepo建本地yum仓库，把依赖顺序交给yum处理：

yum install -y createrepo createrepo /data/nginx-offline-rpm

createrepo会在目录下生成repodata子目录，里面是仓库索引信息。有了这个索引，这个目录就能作为本地yum源来用。有一点要注意：createrepo必须在所有rpm放好之后执行，中途如果追加了新的rpm包，要重新跑一次createrepo刷新索引。

3.4 打包传到离线机器：tar加scp一套走

目录里几十个rpm文件，加上repodata目录，打成tar包再传输比一个一个scp省心：

cd /data tar czf nginx-offline-rpm.tar.gz nginx-offline-rpm scp nginx-offline-rpm.tar.gz root@目标机IP:/opt/

打包时cd到父目录再执行tar，这样解压后的路径固定是/opt/nginx-offline-rpm，后面写repo文件时路径不容易写错。如果你在跳板机环境不能直连scp，先把包传到中转目录，再想办法拷贝过内网，这一步只是传输方式不同，思路一样。

3.5 配置本地yum源并安装rpm包

离线机器上解压tar包，然后写一个本地repo文件指向rpm目录：

tar zxf /opt/nginx-offline-rpm.tar.gz -C /opt/ cat > /etc/yum.repos.d/nginx-offline.repo <<'EOF' [nginx-offline] name=nginx offline rpm repo baseurl=file:///opt/nginx-offline-rpm gpgcheck=0 enabled=1 EOF yum clean all yum makecache

baseurl用file://指向本地目录，因为createrepo已经在里面建了repodata，yum能识别为合法仓库。gpgcheck=0跳过GPG签名校验，离线环境下自己打包的rpm没有签名，不关掉会报错。这套配置做完，yum install就可以直接从本地仓库拉包了：

yum install -y gcc gcc-c++ make pcre-devel zlib-devel openssl-devel

yum会自动解析依赖并安装所有需要的rpm。这一步把离线环境里最麻烦的依赖顺序问题绕过去了。如果这里报错，首先看repodata路径对不对，再确认rpm包是不是适配这套系统版和架构。

4. 编译安装nginx：configure参数取舍与systemd注册

4.1 解压源码并敲定configure参数

依赖全部就位，接下来是nginx本体。先把源码包传到机器上解压，进入源码目录执行configure。参数这块最容易翻车，逐个敲清楚再执行：

tar zxf nginx-1.20.2.tar.gz -C /opt/ cd /opt/nginx-1.20.2 ./configure --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_gzip_static_module \ --with-http_realip_module \ --with-http_stub_status_module

--prefix指定安装目录，--with-http_ssl_module开启HTTPS支持，--with-http_gzip_static_module和--with-http_stub_status_module分别是静态gzip预压缩和状态监控页，前者对带宽敏感的内网环境有帮助，后者排查流量时很好用。注意如果你的nginx版本比较新，configure脚本不再接受--with-pcre参数了，直接去掉就行，pcre会被默认处理。configure报错的话，错误信息会明确告诉你缺哪个库，对照第2章的依赖清单补装对应的-devel包就行。

4.2 make编译与make install

configure通过之后就是编译安装，这个没什么玄学，就是等待：

make -j4 make install

-j4表示4个CPU核心并行编译，可以按实际核数调大。make过程中报错，大概率是缺开发头文件，比如pcre.h、zlib.h，而不是缺运行库。记住一个经验：编译报错缺头文件，去装对应的-devel包；运行时缺so库，才去装基础运行库。很多人来回折腾，就是没分清编译依赖和运行依赖的区别。

安装完成后验证一下二进制和编译参数：

/usr/local/nginx/sbin/nginx -V

-V输出编译参数和版本号，同时确认安装路径没跑偏。如果这里提示找不到命令，说明--prefix指定路径和实际安装路径不一致，回看configure参数。

4.3 nginx.conf核心配置：worker、日志、gzip

nginx.conf是nginx的主配置文件，默认在/usr/local/nginx/conf/nginx.conf。启动之前先改几个基本参数，避免默认配置扛不住实际流量：

worker_processes auto; worker_connections 4096; gzip on; error_log logs/error.log warn;

worker_processes设auto会根据CPU核数自动分配worker进程，比手写数字省心；worker_connections是每个worker能并发处理的连接数，内网流量下4096够用；gzip on开启响应压缩，对带宽有限的离线环境有帮助。error_log日志级别先用warn，初期排查够了，稳定之后可以调回error减少磁盘写入。

4.4 给Java后端配反向代理

nginx最典型的落地场景之一，是给Java应用做反向代理。比如你有个Java后端服务跑在8080端口，用nginx把80端口的请求转发过去：

upstream java_backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name _; location / { 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; } }

upstream块定义后端Java服务地址，max_fails和fail_timeout控制故障转移策略：30秒内请求失败3次，就认为后端不可用，暂时摘掉这个节点。proxy_set_header三行是反向代理必须带上的头信息，否则Java应用拿到的客户端IP全是nginx服务器的IP，应用日志里的来源地址全错掉。这段配置加上去，nginx才真正接入了Java应用的链路。

4.5 注册systemd服务并加入开机自启

源码编译安装的nginx不会自动注册系统服务，需要手写一个systemd unit文件来管理进程、设置开机自启：

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 nginx

Type=forking很关键，因为nginx主进程会fork出worker进程后daemon化，systemd需要PIDFile才能跟踪主进程状态。PIDFile路径必须和nginx.conf里pid指令的路径一致，默认是logs/nginx.pid。写完unit文件先daemon-reload让systemd重新加载，再enable设置开机自启。

5. nginx离线安装避坑：5个高频翻车现场

5.1 yumdownloader下载到一半失败：源失效或网络抖动

现象：yumdownloader执行到一半，报“Could not retrieve mirrorlist”或者某个rpm下载超时，下载过程中断。

原因：联网机器上的yum源配置有问题，baseurl失效、镜像列表过期，或者网络对某些镜像站点不稳定。还有种情况是repo文件里的$releasever变量解析失败，常见于手动改过releasever的场景。

解决：先执行yum clean all和yum makecache重新缓存源，确认repo源可用。如果特定镜像源不稳定，在yumdownloader命令里临时指定可用的镜像源，或者把/etc/yum.repos.d下无效的repo文件暂时移到备份目录，只保留一个能用的源再跑。

5.2 rpm -ivh报依赖冲突或版本太旧：清单没对齐

现象：在离线机器上手动执行rpm -ivh *.rpm时，报“package xxx conflicts with”或“requires yyy >= xxx”。

原因：跳过了yum依赖解析，直接用rpm硬装。几十个rpm包的依赖顺序靠人肉捋不现实，一个包装错位置就卡住。

解决：不要用rpm -ivh *.rpm莽装，改用第3章配好的本地yum源，一条yum install -y让yum自己解析依赖。如果yum也报版本冲突，说明下载rpm时的系统版本与目标机器不一致，回到联网机器上重新确认os-release和架构，重新下载。

5.3 configure阶段报pcre/zlib找不到：头文件缺失

现象：执行./configure时出现“checking for PCRE library ... not found”或“zlib.h not found”。

原因：运行库装上了，但对应的-devel开发包没装。nginx编译时找的是头文件（.h），不是.so运行库，两者的rpm包是分开的。

解决：回到本地yum源，执行yum install -y pcre-devel zlib-devel，然后重新跑configure。这个坑特别容易踩，因为很多人只看“pcre”两个字就装了pcre，没意识到还要装pcre-devel。记住一句：编译找头文件，运行找so库，编译阶段缺什么就补对应的-devel包。

5.4 openssl版本太旧导致TLS协议受限：configure能过但HTTPS跑不起来

现象：nginx编译成功，但浏览器或Java客户端访问HTTPS时报TLS握手错误，wget访问本地HTTPS服务提示cipher协商失败。

原因：系统自带openssl版本过老，只支持TLSv1.0/1.1，现代客户端默认要求TLSv1.2以上，双方握不上手。

解决：两个方案。第一，在nginx.conf的ssl配置里显式指定TLS协议版本，把TLSv1.2加上去，不升级openssl也能让老系统兼容现代客户端。第二，升级openssl-devel后重新编译nginx，但这个方案依赖链条长，离线环境下要额外准备一堆openssl相关rpm，非必要不碰。

5.5 systemd启动nginx失败：pid文件路径不一致

现象：systemctl start nginx提示控制进程退出或启动失败，但直接执行/usr/local/nginx/sbin/nginx却能正常运行。

原因：systemd unit文件里的PIDFile路径，和nginx实际运行时的pid文件路径不一致。nginx.conf里pid指令如果改成/var/run/nginx.pid之类的自定义路径，而unit文件仍然按默认路径写，systemd就跟踪不到主进程状态，判断启动失败。

解决：把PIDFile改成和nginx.conf里pid指令完全一致，两边路径统一后systemctl start一次通过。我遇到过nginx.conf里pid写的是/var/run/nginx.pid，unit文件里还是默认路径，折腾了半小时才发现是这个不显眼的配置项不一致。

6. 装完怎么验证nginx跑通了：一套验证命令从头到尾

安装完成不等于跑通。我习惯按下面的顺序把nginx每一项都验一遍，避免之后出问题来回猜：

systemctl status nginx curl -I http://127.0.0.1:80 ss -tlnp | grep :80 /usr/local/nginx/sbin/nginx -t

第一条确认服务处于active状态；第二条看HTTP响应头，注意Server字段是不是nginx；第三条确认80端口被nginx监听；第四条是nginx自带的配置检查命令，改过任何配置之后建议先跑一遍再reload。这四条全过，说明nginx进程、端口监听、配置文件三方面都正常。

接着验证反代是不是真的把流量转给了Java后端。假设Java应用跑在8080端口，执行：

curl http://127.0.0.1/health tail -f /usr/local/nginx/logs/error.log

/health是Java后端自定义的健康检查接口，返回200和JSON内容说明nginx成功把请求转发到了Java应用，整条链路是通的。同时开着error.log观察有没有连接失败或超时日志。如果这一步返回502，说明nginx连不上Java后端，先确认Java应用是否真的在监听8080，再查防火墙和SELinux设置，内网机器最常见的坑就是firewalld拦了本地回环和端口。

最后验一个容易被忽略的点：重启机器后nginx会不会自动起来。执行reboot后重新登录，确认systemctl status nginx仍然是active。这一步虽然简单，但生产环境里不少事故出在“上次装完没重启过，重启后nginx没起来”。从那以后，我每次装完nginx都会强制自己走一遍完整验证：进程、端口、curl、日志、重启，一条不落才敢交差。希望这篇基于实际踩坑记录的nginx离线安装流程，能帮你在离线环境里少走几步弯路。

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