企业官网建设流程全解析

简介：面向离线或内网环境下的 Linux 服务器运维人员，这套资源将 nginx 离线安装过程中所需的编译器依赖包与 nginx 自身依赖集合整合为一体，解决无网络时无法用常见包管理器安装的痛点。压缩包共 4 个文件，以三个 gz 格式的依赖归档为主要内容，分别对应编译工具链和 nginx 运行依赖，另附一个 html 安装说明文档，整体大小约 62.15 兆字节，方便直接拷贝至内网服务器使用。目前已有 1682 人学习使用。借助打包好的 rpm 依赖集合，读者可快速搭建编译环境、完成 nginx 部署，同时配套文档针对版本匹配和依赖冲突提供了详细的排查思路，能显著降低安装失败概率。该资源尤其适合高并发静态服务、反向代理等场景，也可与基于 Java 的中间件组合实现动静分离，从而提升服务器整体吞吐与响应能力，是内网环境高效部署 nginx 的实用工具。

1. nginx离线安装，到底在卡谁

把一台内网服务器交付到现场，装应用前先装 nginx，结果发现系统里连 gcc 都没有。yum 源指向外网，网络不通；rpm 包手里一个也没有；上网查资料只能靠手机。这时候你才明白，nginx离线安装这件事，难点从来不在 nginx 本身，而在它前面那一长串依赖。标题里说的“包含 gcc、nginx 的依赖包 rpm 集合”，就是把整条依赖链提前在联网机器上备好，再搬到离线机器上一次性装齐。这篇笔记就是沿着这条路径走一遍，从依赖怎么下载、怎么打包，到本地 yum 源怎么建、nginx 怎么编，再到最常见的翻车点，适合内网交付、机房实施、以及所有被“没网装不了东西”卡住过的同事。

2. 装 nginx 之前，先把 gcc 依赖打包成 rpm 集合

2.1 nginx 编译依赖 gcc 与三个基础库，版本关系先搞清楚

nginx 官方提供的二进制包在部分内网环境里未必适用，最常见的方式还是源码编译。源码编译需要一套完整的 C 编译器，也就是 gcc 和 gcc-c++，再加上 make。这三样是“编译工具链”，没有它们，configure 脚本第一步就会直接报错。

除了编译器，nginx 编译还依赖三个基础库：pcre 负责正则表达式，zlib 负责 gzip 压缩，openssl 负责 HTTPS。对应到 rpm 包上，不仅要装 pcre、zlib、openssl 本体，还要装 pcre-devel、zlib-devel、openssl-devel，因为编译时需要的头文件都在 devel 包里。很多新手只装了本体没装 devel，configure 跑一半提示找不到头文件，就是这个原因。

版本匹配上，CentOS 7 默认自带 pcre 1.x 和 openssl 1.0.2k，编 nginx 1.18 到 1.24 都没问题；CentOS 8 系统自带的是 pcre2 和 openssl 1.1.1，直接用系统库也能编过。需要特别注意的是，别把 CentOS 8 的 rpm 包拿到 CentOS 7 机器上装，gcc 版本、glibc 版本都可能对不上，这是离线安装里最常见的版本串台问题。

2.2 在联网机器上用 yumdownloader 一次性拉全 rpm 依赖

下载依赖的机器要和离线机器系统版本一致，最好大版本相同、小版本相近。比如目标机器是 CentOS 7.9，就找一台 CentOS 7.x 的联网机器来下载，不要用 CentOS 8 或别的发行版，否则 rpm 包的兼容性很难保证。

下载工具用 yumdownloader，它在 yum-utils 包里，需要先安装：

yum install -y yum-utils createrepo mkdir -p /opt/nginx-rpms cd /opt/nginx-rpms yumdownloader --resolve --destdir=/opt/nginx-rpms \ gcc gcc-c++ make \ pcre pcre-devel zlib zlib-devel \ openssl openssl-devel \ createrepo

--resolve参数会自动把指定包的依赖一起下载，这是最关键的一个选项。不加它，yumdownloader 只下载你列出的 rpm，依赖不会跟着下来。createrepo也一起放进列表里，因为离线机器上多半没有这个工具，而后面建本地 yum 源必须用到它。

下载时会遇到一个实际问题：如果这台联网机器本身已经装过 gcc 或 openssl，yumdownloader 会跳过已安装的包，导致下载集合不完整。我一般会临时用一台最小化安装的干净机器来下载，或者下载完统计一下 rpm 数量，对照依赖关系检查。更保险的做法是用repotrack命令，它会无视本机已安装状态，把依赖全部拉下来：

repotrack gcc gcc-c++ make pcre-devel zlib-devel openssl-devel createrepo

repotrack会写到当前目录。它比 yumdownloader 多下载不少包，包括已经装过的，体积大一点，但更稳妥。两种工具都在 yum-utils 里，选一种即可。

2.3 打包与传输：rpm 集合要带上系统标识再上路

下载完成后，目录里通常是几十个 rpm 文件。打包时建议在压缩包名字里带上系统版本和架构，方便以后复用和排查：

tar czf nginx-deps-centos7-x86_64.tar.gz /opt/nginx-rpms

命名格式按“用途-系统-架构”来写，比如nginx-deps-centos7-x86_64.tar.gz。别小看这一步，离线环境越攒越多之后，机器上会堆一堆 tar 包，没有标识根本分不清哪个是给哪台机器用的。

传输方式看现场条件，U 盘拷、内网共享目录拉取都行。注意传输完成的校验，用md5sum对比一下包校验值，避免拷贝过程中文件损坏。文件拷到离线机器后解压：

mkdir -p /opt/nginx-rpms tar xzf nginx-deps-centos7-x86_64.tar.gz -C /opt

解压后确认目录里 rpm 文件的数量和联网机器上一致。数量对不上就先别继续，回查下载环节，这一步省了后面全是坑。

3. 离线机器上建本地 yum 源，让 gcc 和 nginx 依赖一次装齐

3.1 为什么不用 rpm -Uvh 直接批量装

rpm 集合拿到手，第一反应可能是rpm -Uvh *.rpm一把梭。这个命令在依赖简单时能成功，但 gcc、openssl 这组依赖链比较复杂，尤其是 openssl 可能和系统原有版本冲突，或者某些包依赖的库版本顺序不对，rpm -Uvh批量安装会因为一个依赖问题中断执行，留下一堆半装状态。

更麻烦的是回滚。rpm 批量安装失败后，哪些包装上了、哪些没装上，只能靠rpm -qa一个个查，查完还得手动清理，纯粹浪费时间。

所以我一般不在离线机器上直接rpm -Uvh，而是把 rpm 集合目录建成一个本地 yum 源。yum 会自己解析依赖关系，自动决定安装顺序，遇到缺包会明确报错提示，而不是装到一半卡住。这个思路在 CentOS 6/7/8 上都适用。

3.2 用 createrepo 生成本地仓库，再把 gcc 全家装进去

在解压好的 rpm 目录下执行 createrepo 生成仓库元数据：

cd /opt/nginx-rpms createrepo .

执行成功后目录下会多出一个repodata子目录，里面有仓库的元数据文件。这就是本地 yum 源的标识，没有它 yum 无法识别这个目录。

然后在/etc/yum.repos.d/下新建一个仓库配置文件：

[nginx-local] name=nginx local deps repository baseurl=file:///opt/nginx-rpms enabled=1 gpgcheck=0

baseurl用的是file://协议，指向本地目录。gpgcheck=0表示跳过 GPG 签名校验，离线环境下这些包是自己下载的，安全性可以自行把握。如果公司内网有签名校验要求，可以保留gpgcheck=1并导入对应公钥，但一般离线场景没必要。

配置完成后刷新缓存并安装：

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

这里有几个细节。第一，yum clean all必须执行，否则 yum 缓存里可能还是旧的仓库数据，识别不到新增的本地源。第二，安装的是 devel 包而非本体库，因为本体库通常系统已经装了，真正缺的是头文件。第三，如果离线机器之前配置过外网 yum 源，建议把外网源文件先移走或者禁用，避免 yum 在解析依赖时去尝试访问不可达的地址，导致超时等待。

安装完成后用rpm -qa验证一下关键包是否到位。

3.3 装完核对版本，确认编译环境可用

rpm -qa | grep -E "^(gcc|gcc-c++|make|pcre|zlib|openssl)"

正常输出里能看到gcc-4.8.5、pcre-8.32、openssl-1.0.2k这一类的完整包名和版本号。核对两项内容：一是 gcc 和 make 确实装上了，二是 devel 包都在。只看本体的包名不算成功，比如pcre装了但pcre-devel没装，后面 configure 照样挂。

这一步还可以顺手确认 openssl 的版本。CentOS 7 默认是 1.0.2k，编 nginx 的 ssl 模块完全够用；如果你准备配置 HTTP/2 或需要用 TLS 1.3，就得确认系统 openssl 是不是 1.1.1 以上版本，不是的话后面第 5 章有对应的处理说明。

4. nginx 源码编译安装：configure 参数与启动配置

4.1 configure 最小参数集与路径约定

依赖装齐之后，把 nginx 源码包传到离线机器并解压。源码版本建议选当前主流稳定版，比如 1.24 系列，具体版本号按你下载的为准。

进入解压目录后执行 configure，我的最小参数集是：

cd /opt/nginx-1.24.0 ./configure \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream

--prefix指定安装路径，后续所有文件会装到/usr/local/nginx下，卸载时直接删这个目录就行。--with-http_ssl_module是必选项，不加它 HTTPS 功能完全不可用。--with-http_stub_status_module提供/nginx_status页面，日常看连接数很有用。--with-stream开启四层 TCP 代理能力，做端口转发时用得上。不需要的模块不写，参数越少编译时间越短.

如果 configure 报错说找不到 pcre 或 zlib，先检查第 3 章有没有把对应的 devel 包装上。常见报错是the HTTP rewrite module requires the PCRE library，基本就是 pcre-devel 缺失，回去yum install再重新 configure 即可。

4.2 make 编译与常见的编译失败定位

configure 通过之后再执行编译。离线机器内存普遍不大，编译参数要克制：

make -j2 make install

-j2表示用两个进程并行编译。如果机器内存小于 2G，去掉-j直接make反而更快。内存不足时并行编译会因为内存耗尽被系统 kill 掉，表现为进程消失、终端输出中断，这种问题加-j1就能解决。

make install会创建/usr/local/nginx目录并复制文件。编译失败时看终端输出里的error:行，往上翻几个屏幕找到第一个 error，那才是真正的原因。常见错误就是缺头文件、缺库，回到 yum 安装对应 devel 包再重新./configure && make。重新编译前不需要清理，configure 会覆盖配置。

4.3 启动 nginx 与配置开机自启

安装完成后先做基础验证：

/usr/local/nginx/sbin/nginx -t /usr/local/nginx/sbin/nginx curl http://127.0.0.1

nginx -t会检查配置文件语法，输出syntax is ok和test is successful才算通过。启动后curl应该返回 nginx 默认欢迎页的 HTML 内容。

手动启动只能让 nginx 临时运行，重启机器后不会自动拉起。需要写一个 systemd service 文件，放到/usr/lib/systemd/system/nginx.service：

[Unit] Description=nginx - high performance web server After=network.target remote-fs.target nss-lookup.target [Service] Type=forking PIDFile=/usr/local/nginx/logs/nginx.pid ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s quit PrivateTmp=true [Install] WantedBy=multi-user.target

保存后执行：

systemctl daemon-reload systemctl enable nginx systemctl start nginx systemctl status nginx

ExecStartPre会在启动前自动做语法检查，配置写错时服务启动会失败，但能直接看到错误原因。这里用WantedBy=multi-user.target，系统进入多用户模式后自动启动 nginx。这一步做完，nginx 离线安装就算基本落地了。

5. nginx离线安装常见问题：5个高频坑与排查路径

5.1 现象：rpmlib(FileDigests) 版本报错，rpm 拒绝安装

执行rpm -Uvh *.rpm时提示rpmlib(FileDigests) is needed by xxx，有些包能装，有些包直接拒绝。

原因是离线机器的 rpm 版本太老，识别不了新版 rpm 包的文件摘要格式。解决路径只有一个：不要用rpm -Uvh直接装，回到第 3 章的本地 yum 源方案，yum 内部会处理这些差异。如果 yum 也报同样错误，说明 rpm 包本身来自更新的系统版本，换一批和目标系统版本匹配的 rpm 包。

这个坑在 CentOS 6 和 CentOS 7 混用 rpm 时比较常见。下载依赖之前，先用cat /etc/redhat-release确认目标系统版本，再找对应版本的联网机器下载。

5.2 现象：openssl 版本过低，ssl 模块编不过去

configure 时指定--with-http_ssl_module，报错提示 openssl 相关函数缺失，或者提示OpenSSL version is too old。

CentOS 7 默认 openssl 1.0.2k，对大多数 nginx 场景够用，但如果 nginx 新版本代码里用了 1.1.1 才有的 API，就可能出现这个报错。

解决方式分两种。一是换用旧的 nginx 版本，和系统 openssl 匹配；二是下载 openssl 1.1.1 源码单独编译，再在 nginx configure 时用--with-openssl=/path/to/openssl-source指定。第二种方式编译时间会明显变长，并且之后升级 openssl 时 nginx 也要跟着重新编译，维护成本高。除非业务明确需要 TLS 1.3，否则我一般建议直接用系统自带 openssl，少折腾。

5.3 现象：nginx 启动报 libpcre.so.1 找不到，但 pcre 确实装了

启动时提示error while loading shared libraries: libpcre.so.1，用rpm -qa | grep pcre看到的却是pcre2-*的包。

原因基本可以锁定为：装的是 pcre2 而不是 pcre1。CentOS 8 系统默认带 pcre2，但 nginx 1.24 及更早版本编译链接的是 pcre1 的库文件。系统找不到libpcre.so.1，因为 pcre2 提供的是libpcre2-8.so.0。

解决方式：在本地 yum 源里补上pcre和pcre-devel两个包，安装后再重新 configure、make、make install。注意下载依赖时把pcre显式写进 yumdownloader 列表，别依赖系统自动带出来。这个问题的迷惑性在于看起来 pcre“已经装了”，实际上装的是全然不同的另一个东西。

5.4 现象：make 报 cc1 无法识别的选项，编译中断

编译执行到一半，报cc1: error: unrecognized command line option，后面跟一串选项。

原因是 gcc 版本和目标系统编译环境不匹配，最常见的就是把 CentOS 8 的 gcc rpm 装到了 CentOS 7 机器上。rpm 安装时因为 glibc 版本碰巧满足，装上了，但编译参数不兼容。

解决思路：先gcc --version查看当前 gcc 版本，确认是不是下载时搞混了系统来源，重新用匹配的 rpm 集合安装。这个坑的根源在 2.3 节说的打包标识，压缩包名字里写清楚系统版本，就不会把集合搞混。

5.5 现象：SELinux 拦截 80 端口，页面打不开

nginx 启动正常，curl http://127.0.0.1也能通，但从其他机器访问 80 端口就是不通，或者systemctl status nginx显示 active 但网页超时。

优先怀疑 SELinux。getenforce如果输出Enforcing，十有八九是 SELinux 不允许 nginx 监听 80 端口。SELinux 的策略里默认只放行了某些端口，非标准端口或未登记的端口会被拦。

临时验证可以先setenforce 0切到 Permissive，再访问页面。如果通了，说明就是 SELinux 的问题。然后找一台联网机器下载policycoreutils-python-utils这个包，装了之后用 semanage 放行端口：

semanage port -a -t http_port_t -p tcp 80

或者干脆给 nginx 写一条自定义 SELinux 策略，这是正规做法，但对离线环境来说成本偏高，很多现场就是直接放行端口了事。顺带一提，SELinux 拦截这类问题在 CentOS 7 上表现得很隐蔽，排查网络问题时习惯性先getenforce看看，能少走很多弯路。

6. 把 rpm 集合变成可复用的内网工具包

6.1 一次性验证安装成果的命令序列

离线环境交付时，验证项目总得留下记录。我习惯用下面这一组命令，输出存成文本作为交付物之一：

/usr/local/nginx/sbin/nginx -V /usr/local/nginx/sbin/nginx -t curl -I http://127.0.0.1 ss -lntp | grep :80 rpm -qa | grep -E "^(gcc|pcre|zlib|openssl)"

nginx -V输出的编译参数能看出装了哪些模块，curl -I确认 HTTP 响应头正常，ss确认监听端口，rpm -qa确认依赖版本。这组输出同时写到项目交付文档里，后续排障也有据可查。

6.2 后续补依赖与多机复用的两种思路

rpm 集合不是一次性的。同一个内网里往往有几十台同系统版本的机器，后续还会在机器上装其他软件，又缺新的依赖包。复用方式有两个：一是把/opt/nginx-rpms这个目录直接打包保留，后续补充新 rpm 时放进目录重新执行createrepo .，让仓库元数据更新；二是把这个目录通过内网 HTTP 服务开放，其他机器把baseurl=file:///opt/nginx-rpms换成baseurl=http://内网IP/nginx-rpms，就能直接从内网拉依赖。

我自己的习惯是给每类软件建独立目录，比如nginx-rpms、python-rpms，压缩包统一按“用途-系统-架构”命名。这样再遇到新机器安装环境，直接解压、建源、装包三条命令搞定，不用重新上网找资源。

第一次做离线安装时，我也干过把 pcre2 当成 pcre 用了半天的事，最后发现是系统库里同名不同族。这类问题写下来比记在脑子里靠谱。希望这篇笔记能帮你少走几趟弯路。

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