简介面向无外网或网络受限环境下的Linux服务器运维人员这份资源提供了一套完整的nginx离线部署方案重点解决内网数据中心无法在线拉取依赖的安装难题。压缩包共4个文件以gz压缩包为主体分别承载nginx源码、gcc编译环境及nginx运行所需的rpm依赖集合另附一份html格式的安装说明文档整体约62.15MB便于一次性拷贝至目标服务器使用。资源将编译工具链与Web服务器依赖打包整合读者可据此在断网条件下完成gcc环境准备、nginx安装与配置启动避免逐一下载依赖造成的版本冲突与时间损耗。目前已有1683人学习下载适合需要在内网快速搭建静态文件服务、反向代理或负载均衡环境的中初级运维与开发人员参考实践。1. 内网机器装 nginx为什么我宁可背一包 rpm 进去上周又碰到一台生产环境的 CentOS 7 机器网卡是通的但只放行了内网端口yum install nginx直接卡在Could not resolve host: mirrorlist.centos.org。这种场景在金融、制造、能源的隔离区里太常见了机器能 SSH能传文件就是不能出网。你要装个 nginx 做反向代理或者静态资源服务结果第一步./configure就报C compiler cc is not found因为最小化安装的系统连 gcc 都没带。这份资源就是为这种局面准备的一个 nginx 离线安装包里面把 gcc 编译工具链和 nginx 运行所需的 rpm 依赖一起打进去了。它解决的不是怎么学 nginx而是在一台完全断网的 Linux 上怎么把 nginx 从零装起来并且能跑。适合谁做内网部署的运维、交付工程师、以及被派去客户机房装中间件的后端。如果你平时机器能联网yum一把梭就行这份包对你价值不大但只要你有一次要在无外网环境装 nginx它就是能救命的后悔药。我见过太多人栽在以为只差一个 nginx rpm上。实际上 nginx 依赖 pcre、zlib、openssl编译安装还要 gcc、make、glibc-headers这些依赖之间还有版本咬合关系。离线包的价值不在于文件多而在于它把这条依赖链一次性锁死了。2. 先搞清楚包里有什么依赖链与安装路径的选择2.1 为什么是 rpm 集合而不是单个二进制nginx 的安装方式大致三种源码编译、官方预编译包、系统包管理器。离线环境下源码编译最灵活但最吃依赖你得先有 gcc 和一堆-devel包官方预编译包体积小但版本和系统 ABI 要对得上rpm 集合则是把系统包管理器能认的依赖全部备齐用rpm -ivh或本地 yum 源的方式灌进去。这份资源走的是第三条路核心逻辑是先把编译/运行依赖用 rpm 补齐再装 nginx 本体。为什么不用源码编译因为隔离区机器往往连make都没有你传一个 tar.gz 进去照样卡在编译阶段。rpm 的好处是安装即生效不需要现场编译失败时rpm -qa能立刻看出哪个包没进去。常见做法是建一个本地 yum 仓库让yum自己去解依赖而不是一个个rpm -ivh硬装——后者遇到依赖顺序问题会反复报Failed dependencies非常折磨人。2.2 依赖清单与版本咬合一个典型的 nginx 离线依赖集合按用途可以分成四组。下面这张表是我按实际拆包经验整理的具体包名以你拿到的资源为准但分组逻辑是通用的分组典型包作用缺失后的现象编译工具链gcc、gcc-c、make、glibc-devel源码编译或部分模块构建C compiler cc is not found正则库pcre、pcre-develrewrite、location 正则匹配编译报 pcre 找不到或启动后 rewrite 失效压缩库zlib、zlib-develgzip 静态压缩the HTTP gzip module requires the zlib librarySSL 库openssl、openssl-develHTTPS、TLSSSL modules require the OpenSSL library这里有个血泪经验pcre和pcre-devel是两个包前者是运行库后者是头文件。只装前者nginx 能跑但编译不过只装后者编译过了运行可能缺 so。离线包里如果只给了一个你得自己判断当前是编译场景还是运行场景。版本咬合是另一个坑。CentOS 7 自带 openssl 1.0.2如果你拿到的 nginx 包是针对 openssl 1.1 编译的装上去启动就报libssl.so.1.1: cannot open shared object file。所以拿到资源第一件事不是急着装而是先核对目标系统的发行版和 glibc 版本。# 先摸清目标机器的底细再决定装哪套包 cat /etc/redhat-release # 确认是 CentOS 7 还是 8决定 rpm 的 el7/el8 后缀 ldd --version | head -1 # 看 glibc 版本低于包要求会直接段错误 uname -m # x86_64 还是 aarch64架构不对 rpm 直接拒装 rpm -qa | grep -E pcre|zlib|openssl # 看系统已有哪些库避免重复装冲突这段命令的逻辑是先侦察后动手。/etc/redhat-release决定你选el7还是el8的包ldd --version看 glibc因为 rpm 包的依赖里常带glibc 2.17这类硬约束uname -m防止把 x86 包传到 ARM 机器上最后一条是查已有库避免你装的 openssl 和系统自带的打架。参数上没什么可调的关键是养成装之前先跑一遍的习惯。2.3 两种落地路径本地 yum 源 vs 直接 rpm拿到 rpm 集合后有两条路。第一条是直接rpm -ivh *.rpm简单粗暴但依赖顺序错了会连环报错而且--nodeps强装是给自己埋雷。第二条是搭本地 yum 源让 yum 解依赖稳得多。我一般推荐第二条尤其是包数量超过十个的时候。搭源只需要createrepo如果目标机连这个都没有可以在有网的机器上先createrepo生成好repodata目录整个文件夹拷过去即可。# 路径一本地 yum 源推荐依赖自动解 mkdir -p /opt/localrepo cp /path/to/rpms/*.rpm /opt/localrepo/ createrepo /opt/localrepo # 生成 repodata 元数据没网机器可提前在有网机器做 cat /etc/yum.repos.d/local.repo EOF [local] nameLocal Offline Repo baseurlfile:///opt/localrepo enabled1 gpgcheck0 EOF yum clean all yum makecache yum install -y nginx # 让 yum 自己按依赖顺序装# 路径二直接 rpm 硬装包少时用注意顺序 cd /path/to/rpms rpm -ivh pcre-*.rpm zlib-*.rpm openssl-*.rpm # 先装基础库 rpm -ivh gcc-*.rpm make-*.rpm glibc-devel-*.rpm # 再装编译链 rpm -ivh nginx-*.rpm # 最后装本体路径一的关键在baseurlfile://三个斜杠不能少少一个 yum 就找不到源gpgcheck0是因为离线包的签名你没法验证生产环境如果在意完整性应该在内网自建签名而不是关校验。路径二的顺序不是随便排的基础库在前编译链在中nginx 本体在后因为 rpm 安装时会检查依赖是否已满足顺序反了就得反复--nodeps。rpm -ivh的-i是安装、-v显示过程、-h打进度条这三个字母组合是肌肉记忆但真正决定成败的是包顺序而不是参数。3. 装完不等于能用配置、启动与验证的完整闭环3.1 安装后的目录结构与关键路径rpm 方式装的 nginx路径和源码编译不一样很多人第一次找配置文件找半天。典型布局是二进制在/usr/sbin/nginx主配置在/etc/nginx/nginx.conf站点配置在/etc/nginx/conf.d/日志在/var/log/nginx/默认站点根目录在/usr/share/nginx/html。源码编译默认是/usr/local/nginx/两者别搞混。先验证二进制和版本再看配置语法最后才启动。这个顺序能帮你把问题挡在启动之前。/usr/sbin/nginx -v # 看版本确认装的是预期的那份 /usr/sbin/nginx -V # 大写 V 看编译参数重点看 --with-http_ssl_module 在不在 /usr/sbin/nginx -t # 测配置语法改完配置必跑-t这条是保命命令。我见过有人改完nginx.conf直接systemctl restart结果配置里少个分号nginx 起不来线上服务直接断。-t会在不重启的前提下把配置解析一遍报错会精确到行号。-V的大写很关键小写-v只给版本号大写才吐编译参数——你要确认 HTTPS 支持、gzip 模块这些是否编进去了全靠它。3.2 最小可用配置与启动方式装完默认配置通常能跑但生产上你至少要改监听端口、站点根目录和日志格式。下面是一个能直接抄的最小反向代理配置放在/etc/nginx/conf.d/app.confserver { listen 8080; # 避开 80防止和已有服务冲突 server_name _; # 下划线表示匹配任意 Host access_log /var/log/nginx/app_access.log; error_log /var/log/nginx/app_error.log warn; location / { proxy_pass http://127.0.0.1:9000; # 后端真实服务地址 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_connect_timeout 5s; # 后端连不上时快速失败别让客户端干等 proxy_read_timeout 30s; } }这段配置的逻辑listen 8080先避开 80 端口因为隔离区机器上 80 很可能被别的老服务占着proxy_set_header那三行是把真实客户端信息透传给后端不设的话后端日志里全是127.0.0.1排查问题时等于黑匣子两个 timeout 是防止后端挂掉时 nginx 一直挂着连接proxy_connect_timeout 5s让失败快速暴露。参数怎么调后端是内网低延迟服务5s 连接超时足够如果是跨机房可以放到 10s但别超过 30s否则故障时客户端体验极差。启动用 systemd 最稳rpm 包一般自带 unit 文件systemctl start nginx systemctl enable nginx # 开机自启隔离区机器重启后不用人工拉 systemctl status nginx # 看 active (running) 才算成 ss -lntp | grep 8080 # 确认端口真的在监听而不是进程活着但没绑上 curl -I http://127.0.0.1:8080 # 本机自测看返回码ss -lntp这条容易被忽略。systemctl status显示 running 不代表端口绑成功了有可能配置里 listen 写错或者被 SELinux 拦了。ss直接看内核的监听表-l是 listening、-n是数字端口、-t是 TCP、-p显示进程一眼就能确认 nginx 到底有没有在 8080 上等连接。curl -I只取响应头快且不拉全量内容适合做连通性冒烟测试。3.3 用 java 侧做一次端到端验证关键词里有 java实际交付场景里 nginx 前面挂的经常是 Java 后端。装完 nginx 别只在本机 curl最好从应用侧验证一次转发链路是否通。假设后端是个 Spring Boot 服务跑在 9000可以用一段极简的 Java 代码打一次请求确认经过 nginx 后X-Forwarded-For头有没有正确带上。import java.net.HttpURLConnection; import java.net.URL; public class ProxyCheck { public static void main(String[] args) throws Exception { // 请求打到 nginx 的 8080而不是后端 9000验证的是代理链路 URL url new URL(http://127.0.0.1:8080/health); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(GET); conn.setConnectTimeout(3000); // 连接超时和 nginx 的 proxy_connect_timeout 呼应 conn.setReadTimeout(5000); // 读超时略大于后端处理时间 int code conn.getResponseCode(); System.out.println(status code); // 后端若把请求头回显这里能看到 X-Forwarded-For 是否被 nginx 注入 System.out.println(xff conn.getHeaderField(X-Forwarded-For)); conn.disconnect(); } }这段代码的价值在于从消费方视角验证。setConnectTimeout(3000)比 nginx 的 5s 略短是为了在 nginx 还没放弃时 Java 侧先报错方便定位是代理层还是后端层的问题getHeaderField(X-Forwarded-For)读的是响应头前提是后端把这个请求头回显出来如果没有回显就改成在后端日志里查。参数上超时值要和 nginx 的 timeout 形成梯度否则两边同时超时你根本分不清是谁先挂的。4. 离线安装的避坑清单五个真实翻车现场4.1 现象rpm -ivh报一堆 Failed dependencies越装越乱原因几乎总是依赖顺序错或者缺包。rpm 不像 yum 会自己排序它要求你装的包在装的那一刻依赖已满足。有人图省事加--nodeps强装结果 nginx 起来了但一访问就 500因为 pcre 的 so 根本没链上。解决优先走本地 yum 源那条路让 yum 解依赖。实在要硬装先rpm -qpR nginx-*.rpm把 nginx 的依赖列出来逐个确认系统里有没有缺的补进去再装。已经用--nodeps装坏的rpm -e卸掉重来别在坏地基上继续盖。4.2 现象nginx 启动报libssl.so.1.1: cannot open shared object file原因是 nginx 二进制编译时链接的 openssl 版本和系统里的不一致。CentOS 7 默认 openssl 1.0.2而你拿到的包可能是针对 1.1 编的。这不是配置问题是 ABI 不匹配。解决ldd /usr/sbin/nginx | grep ssl看它到底找哪个 so。要么换一份匹配系统 openssl 的 nginx 包要么把对应版本的 openssl 库一起离线装进去。别想着软链接糊弄ln -s一个版本号对不上的 so大概率段错误。4.3 现象systemctl start nginx成功但curl连接被拒原因通常是端口没绑上常见于三种情况配置里 listen 的端口被占用、SELinux 拦了非标准端口、或者 nginx 实际读的不是你改的那个配置文件。systemctl status显示 running 只说明主进程活着。解决ss -lntp | grep nginx看真实监听端口getenforce看 SELinux 状态如果是 Enforcing 且你用了 8080 这类非默认端口需要semanage port -a -t http_port_t -p tcp 8080最后nginx -T大写 T把最终生效的完整配置打出来确认你改的文件真的被 include 了。4.4 现象配置改完nginx -t通过重启后仍旧是旧行为原因是改了conf.d/下的文件但主配置没 include或者改的是/usr/local/nginx/conf/而实际运行的是/etc/nginx/。源码编译和 rpm 安装的路径不同这是高频混淆点。解决nginx -T输出里搜你的 server_name 或 listen 端口看它到底加载了哪些文件。养成改完配置先-t再-T确认生效范围的习惯比重启后抓瞎强。4.5 现象离线装完 gcc编译某个模块仍报头文件找不到原因是只装了gcc没装glibc-devel或对应的-devel包。gcc 是编译器前端头文件在-devel包里两者是分开的。离线包如果只打了 gcc编译任何带系统调用的代码都会缺stdio.h之类。解决rpm -qa | grep devel查已装的开发包缺什么补什么。判断方法很直接报错里出现xxx.h: No such file就去装提供这个头文件的-devel包。这也是为什么依赖清单里编译工具链那一组要整组备齐而不是只给一个 gcc。5. 把离线包变成可复用资产校验、归档与一次装对的习惯装完一台机器不算完真正省事的是把这套流程沉淀成可复用的东西。我现在的做法是每拿到一份离线包先做完整性校验再按系统版本 架构归档最后写一个幂等的安装脚本。这样下次换一台同型号机器一条命令跑完不用再回忆上次踩了哪个坑。校验这一步很多人跳过但离线包在拷贝、U 盘传递过程中损坏是常事。rpm 自带校验能力# 校验每个 rpm 包的完整性损坏的包会在输出里标出来 for f in /opt/localrepo/*.rpm; do rpm -K $f || echo BROKEN: $f done # 装完后统一核对关键包是否都在 rpm -qa | grep -E ^(nginx|gcc|make|pcre|zlib|openssl) | sortrpm -K做的是签名和摘要校验输出digests OK才算过循环里用||把坏包单独打出来避免一屏输出里漏看。第二条rpm -qa是装后对账把关键包列出来排序和你的清单逐行比对少一个都能立刻发现。这两条命令我一般写进安装脚本的开头和结尾形成装前校验、装后对账的闭环。归档命名我固定用nginx-offline-发行版-架构-日期这种格式比如nginx-offline-el7-x86_64-202406目录里再放一个MANIFEST.txt记录每个包的版本和用途。别小看这个习惯半年后你再翻出来没有 manifest 的包等于一堆无名 rpm根本不敢往生产上装。最后是一个幂等脚本的骨架核心是已装则跳过、未装则装、装完必验#!/bin/bash set -e # 任何一步失败立即退出避免半装状态继续往下跑 REPO/opt/localrepo rpm -q nginx /dev/null 21 { echo nginx already installed; exit 0; } # 本地源方式安装yum 负责解依赖 yum install -y --disablerepo* --enablerepolocal nginx # 装完立刻验证三件事语法、端口、进程 nginx -t systemctl enable --now nginx ss -lntp | grep -q nginx echo OK: nginx listening || { echo FAIL: not listening; exit 1; }set -e是这类脚本的底线没有它中间某步失败脚本还会继续跑最后给你一个看起来成功的假象。--disablerepo* --enablerepolocal是强制只用本地源防止脚本在能联网的机器上偷偷去拉外网包导致行为和离线环境不一致。最后那条ss | grep -q把进程活着升级成端口真的在听这才是可交付的验证标准。从那以后我每次交付离线环境都强制走一遍校验 → 装 → 对账 → 端口验证这四步哪怕时间再紧也不省。因为省下的那五分钟往往会在客户现场用两小时来还。希望这套流程帮到你下次再面对一台断网机器时心里有底。本文还有配套的精品资源点击获取
简介面向无外网或网络受限环境下的Linux服务器运维人员这份资源提供了一套完整的nginx离线部署方案重点解决内网数据中心无法在线拉取依赖的安装难题。压缩包共4个文件以gz压缩包为主体分别承载nginx源码、gcc编译环境及nginx运行所需的rpm依赖集合另附一份html格式的安装说明文档整体约62.15MB便于一次性拷贝至目标服务器使用。资源将编译工具链与Web服务器依赖打包整合读者可据此在断网条件下完成gcc环境准备、nginx安装与配置启动避免逐一下载依赖造成的版本冲突与时间损耗。目前已有1683人学习下载适合需要在内网快速搭建静态文件服务、反向代理或负载均衡环境的中初级运维与开发人员参考实践。1. 内网机器装 nginx为什么我宁可背一包 rpm 进去上周又碰到一台生产环境的 CentOS 7 机器网卡是通的但只放行了内网端口yum install nginx直接卡在Could not resolve host: mirrorlist.centos.org。这种场景在金融、制造、能源的隔离区里太常见了机器能 SSH能传文件就是不能出网。你要装个 nginx 做反向代理或者静态资源服务结果第一步./configure就报C compiler cc is not found因为最小化安装的系统连 gcc 都没带。这份资源就是为这种局面准备的一个 nginx 离线安装包里面把 gcc 编译工具链和 nginx 运行所需的 rpm 依赖一起打进去了。它解决的不是怎么学 nginx而是在一台完全断网的 Linux 上怎么把 nginx 从零装起来并且能跑。适合谁做内网部署的运维、交付工程师、以及被派去客户机房装中间件的后端。如果你平时机器能联网yum一把梭就行这份包对你价值不大但只要你有一次要在无外网环境装 nginx它就是能救命的后悔药。我见过太多人栽在以为只差一个 nginx rpm上。实际上 nginx 依赖 pcre、zlib、openssl编译安装还要 gcc、make、glibc-headers这些依赖之间还有版本咬合关系。离线包的价值不在于文件多而在于它把这条依赖链一次性锁死了。2. 先搞清楚包里有什么依赖链与安装路径的选择2.1 为什么是 rpm 集合而不是单个二进制nginx 的安装方式大致三种源码编译、官方预编译包、系统包管理器。离线环境下源码编译最灵活但最吃依赖你得先有 gcc 和一堆-devel包官方预编译包体积小但版本和系统 ABI 要对得上rpm 集合则是把系统包管理器能认的依赖全部备齐用rpm -ivh或本地 yum 源的方式灌进去。这份资源走的是第三条路核心逻辑是先把编译/运行依赖用 rpm 补齐再装 nginx 本体。为什么不用源码编译因为隔离区机器往往连make都没有你传一个 tar.gz 进去照样卡在编译阶段。rpm 的好处是安装即生效不需要现场编译失败时rpm -qa能立刻看出哪个包没进去。常见做法是建一个本地 yum 仓库让yum自己去解依赖而不是一个个rpm -ivh硬装——后者遇到依赖顺序问题会反复报Failed dependencies非常折磨人。2.2 依赖清单与版本咬合一个典型的 nginx 离线依赖集合按用途可以分成四组。下面这张表是我按实际拆包经验整理的具体包名以你拿到的资源为准但分组逻辑是通用的分组典型包作用缺失后的现象编译工具链gcc、gcc-c、make、glibc-devel源码编译或部分模块构建C compiler cc is not found正则库pcre、pcre-develrewrite、location 正则匹配编译报 pcre 找不到或启动后 rewrite 失效压缩库zlib、zlib-develgzip 静态压缩the HTTP gzip module requires the zlib librarySSL 库openssl、openssl-develHTTPS、TLSSSL modules require the OpenSSL library这里有个血泪经验pcre和pcre-devel是两个包前者是运行库后者是头文件。只装前者nginx 能跑但编译不过只装后者编译过了运行可能缺 so。离线包里如果只给了一个你得自己判断当前是编译场景还是运行场景。版本咬合是另一个坑。CentOS 7 自带 openssl 1.0.2如果你拿到的 nginx 包是针对 openssl 1.1 编译的装上去启动就报libssl.so.1.1: cannot open shared object file。所以拿到资源第一件事不是急着装而是先核对目标系统的发行版和 glibc 版本。# 先摸清目标机器的底细再决定装哪套包 cat /etc/redhat-release # 确认是 CentOS 7 还是 8决定 rpm 的 el7/el8 后缀 ldd --version | head -1 # 看 glibc 版本低于包要求会直接段错误 uname -m # x86_64 还是 aarch64架构不对 rpm 直接拒装 rpm -qa | grep -E pcre|zlib|openssl # 看系统已有哪些库避免重复装冲突这段命令的逻辑是先侦察后动手。/etc/redhat-release决定你选el7还是el8的包ldd --version看 glibc因为 rpm 包的依赖里常带glibc 2.17这类硬约束uname -m防止把 x86 包传到 ARM 机器上最后一条是查已有库避免你装的 openssl 和系统自带的打架。参数上没什么可调的关键是养成装之前先跑一遍的习惯。2.3 两种落地路径本地 yum 源 vs 直接 rpm拿到 rpm 集合后有两条路。第一条是直接rpm -ivh *.rpm简单粗暴但依赖顺序错了会连环报错而且--nodeps强装是给自己埋雷。第二条是搭本地 yum 源让 yum 解依赖稳得多。我一般推荐第二条尤其是包数量超过十个的时候。搭源只需要createrepo如果目标机连这个都没有可以在有网的机器上先createrepo生成好repodata目录整个文件夹拷过去即可。# 路径一本地 yum 源推荐依赖自动解 mkdir -p /opt/localrepo cp /path/to/rpms/*.rpm /opt/localrepo/ createrepo /opt/localrepo # 生成 repodata 元数据没网机器可提前在有网机器做 cat /etc/yum.repos.d/local.repo EOF [local] nameLocal Offline Repo baseurlfile:///opt/localrepo enabled1 gpgcheck0 EOF yum clean all yum makecache yum install -y nginx # 让 yum 自己按依赖顺序装# 路径二直接 rpm 硬装包少时用注意顺序 cd /path/to/rpms rpm -ivh pcre-*.rpm zlib-*.rpm openssl-*.rpm # 先装基础库 rpm -ivh gcc-*.rpm make-*.rpm glibc-devel-*.rpm # 再装编译链 rpm -ivh nginx-*.rpm # 最后装本体路径一的关键在baseurlfile://三个斜杠不能少少一个 yum 就找不到源gpgcheck0是因为离线包的签名你没法验证生产环境如果在意完整性应该在内网自建签名而不是关校验。路径二的顺序不是随便排的基础库在前编译链在中nginx 本体在后因为 rpm 安装时会检查依赖是否已满足顺序反了就得反复--nodeps。rpm -ivh的-i是安装、-v显示过程、-h打进度条这三个字母组合是肌肉记忆但真正决定成败的是包顺序而不是参数。3. 装完不等于能用配置、启动与验证的完整闭环3.1 安装后的目录结构与关键路径rpm 方式装的 nginx路径和源码编译不一样很多人第一次找配置文件找半天。典型布局是二进制在/usr/sbin/nginx主配置在/etc/nginx/nginx.conf站点配置在/etc/nginx/conf.d/日志在/var/log/nginx/默认站点根目录在/usr/share/nginx/html。源码编译默认是/usr/local/nginx/两者别搞混。先验证二进制和版本再看配置语法最后才启动。这个顺序能帮你把问题挡在启动之前。/usr/sbin/nginx -v # 看版本确认装的是预期的那份 /usr/sbin/nginx -V # 大写 V 看编译参数重点看 --with-http_ssl_module 在不在 /usr/sbin/nginx -t # 测配置语法改完配置必跑-t这条是保命命令。我见过有人改完nginx.conf直接systemctl restart结果配置里少个分号nginx 起不来线上服务直接断。-t会在不重启的前提下把配置解析一遍报错会精确到行号。-V的大写很关键小写-v只给版本号大写才吐编译参数——你要确认 HTTPS 支持、gzip 模块这些是否编进去了全靠它。3.2 最小可用配置与启动方式装完默认配置通常能跑但生产上你至少要改监听端口、站点根目录和日志格式。下面是一个能直接抄的最小反向代理配置放在/etc/nginx/conf.d/app.confserver { listen 8080; # 避开 80防止和已有服务冲突 server_name _; # 下划线表示匹配任意 Host access_log /var/log/nginx/app_access.log; error_log /var/log/nginx/app_error.log warn; location / { proxy_pass http://127.0.0.1:9000; # 后端真实服务地址 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_connect_timeout 5s; # 后端连不上时快速失败别让客户端干等 proxy_read_timeout 30s; } }这段配置的逻辑listen 8080先避开 80 端口因为隔离区机器上 80 很可能被别的老服务占着proxy_set_header那三行是把真实客户端信息透传给后端不设的话后端日志里全是127.0.0.1排查问题时等于黑匣子两个 timeout 是防止后端挂掉时 nginx 一直挂着连接proxy_connect_timeout 5s让失败快速暴露。参数怎么调后端是内网低延迟服务5s 连接超时足够如果是跨机房可以放到 10s但别超过 30s否则故障时客户端体验极差。启动用 systemd 最稳rpm 包一般自带 unit 文件systemctl start nginx systemctl enable nginx # 开机自启隔离区机器重启后不用人工拉 systemctl status nginx # 看 active (running) 才算成 ss -lntp | grep 8080 # 确认端口真的在监听而不是进程活着但没绑上 curl -I http://127.0.0.1:8080 # 本机自测看返回码ss -lntp这条容易被忽略。systemctl status显示 running 不代表端口绑成功了有可能配置里 listen 写错或者被 SELinux 拦了。ss直接看内核的监听表-l是 listening、-n是数字端口、-t是 TCP、-p显示进程一眼就能确认 nginx 到底有没有在 8080 上等连接。curl -I只取响应头快且不拉全量内容适合做连通性冒烟测试。3.3 用 java 侧做一次端到端验证关键词里有 java实际交付场景里 nginx 前面挂的经常是 Java 后端。装完 nginx 别只在本机 curl最好从应用侧验证一次转发链路是否通。假设后端是个 Spring Boot 服务跑在 9000可以用一段极简的 Java 代码打一次请求确认经过 nginx 后X-Forwarded-For头有没有正确带上。import java.net.HttpURLConnection; import java.net.URL; public class ProxyCheck { public static void main(String[] args) throws Exception { // 请求打到 nginx 的 8080而不是后端 9000验证的是代理链路 URL url new URL(http://127.0.0.1:8080/health); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(GET); conn.setConnectTimeout(3000); // 连接超时和 nginx 的 proxy_connect_timeout 呼应 conn.setReadTimeout(5000); // 读超时略大于后端处理时间 int code conn.getResponseCode(); System.out.println(status code); // 后端若把请求头回显这里能看到 X-Forwarded-For 是否被 nginx 注入 System.out.println(xff conn.getHeaderField(X-Forwarded-For)); conn.disconnect(); } }这段代码的价值在于从消费方视角验证。setConnectTimeout(3000)比 nginx 的 5s 略短是为了在 nginx 还没放弃时 Java 侧先报错方便定位是代理层还是后端层的问题getHeaderField(X-Forwarded-For)读的是响应头前提是后端把这个请求头回显出来如果没有回显就改成在后端日志里查。参数上超时值要和 nginx 的 timeout 形成梯度否则两边同时超时你根本分不清是谁先挂的。4. 离线安装的避坑清单五个真实翻车现场4.1 现象rpm -ivh报一堆 Failed dependencies越装越乱原因几乎总是依赖顺序错或者缺包。rpm 不像 yum 会自己排序它要求你装的包在装的那一刻依赖已满足。有人图省事加--nodeps强装结果 nginx 起来了但一访问就 500因为 pcre 的 so 根本没链上。解决优先走本地 yum 源那条路让 yum 解依赖。实在要硬装先rpm -qpR nginx-*.rpm把 nginx 的依赖列出来逐个确认系统里有没有缺的补进去再装。已经用--nodeps装坏的rpm -e卸掉重来别在坏地基上继续盖。4.2 现象nginx 启动报libssl.so.1.1: cannot open shared object file原因是 nginx 二进制编译时链接的 openssl 版本和系统里的不一致。CentOS 7 默认 openssl 1.0.2而你拿到的包可能是针对 1.1 编的。这不是配置问题是 ABI 不匹配。解决ldd /usr/sbin/nginx | grep ssl看它到底找哪个 so。要么换一份匹配系统 openssl 的 nginx 包要么把对应版本的 openssl 库一起离线装进去。别想着软链接糊弄ln -s一个版本号对不上的 so大概率段错误。4.3 现象systemctl start nginx成功但curl连接被拒原因通常是端口没绑上常见于三种情况配置里 listen 的端口被占用、SELinux 拦了非标准端口、或者 nginx 实际读的不是你改的那个配置文件。systemctl status显示 running 只说明主进程活着。解决ss -lntp | grep nginx看真实监听端口getenforce看 SELinux 状态如果是 Enforcing 且你用了 8080 这类非默认端口需要semanage port -a -t http_port_t -p tcp 8080最后nginx -T大写 T把最终生效的完整配置打出来确认你改的文件真的被 include 了。4.4 现象配置改完nginx -t通过重启后仍旧是旧行为原因是改了conf.d/下的文件但主配置没 include或者改的是/usr/local/nginx/conf/而实际运行的是/etc/nginx/。源码编译和 rpm 安装的路径不同这是高频混淆点。解决nginx -T输出里搜你的 server_name 或 listen 端口看它到底加载了哪些文件。养成改完配置先-t再-T确认生效范围的习惯比重启后抓瞎强。4.5 现象离线装完 gcc编译某个模块仍报头文件找不到原因是只装了gcc没装glibc-devel或对应的-devel包。gcc 是编译器前端头文件在-devel包里两者是分开的。离线包如果只打了 gcc编译任何带系统调用的代码都会缺stdio.h之类。解决rpm -qa | grep devel查已装的开发包缺什么补什么。判断方法很直接报错里出现xxx.h: No such file就去装提供这个头文件的-devel包。这也是为什么依赖清单里编译工具链那一组要整组备齐而不是只给一个 gcc。5. 把离线包变成可复用资产校验、归档与一次装对的习惯装完一台机器不算完真正省事的是把这套流程沉淀成可复用的东西。我现在的做法是每拿到一份离线包先做完整性校验再按系统版本 架构归档最后写一个幂等的安装脚本。这样下次换一台同型号机器一条命令跑完不用再回忆上次踩了哪个坑。校验这一步很多人跳过但离线包在拷贝、U 盘传递过程中损坏是常事。rpm 自带校验能力# 校验每个 rpm 包的完整性损坏的包会在输出里标出来 for f in /opt/localrepo/*.rpm; do rpm -K $f || echo BROKEN: $f done # 装完后统一核对关键包是否都在 rpm -qa | grep -E ^(nginx|gcc|make|pcre|zlib|openssl) | sortrpm -K做的是签名和摘要校验输出digests OK才算过循环里用||把坏包单独打出来避免一屏输出里漏看。第二条rpm -qa是装后对账把关键包列出来排序和你的清单逐行比对少一个都能立刻发现。这两条命令我一般写进安装脚本的开头和结尾形成装前校验、装后对账的闭环。归档命名我固定用nginx-offline-发行版-架构-日期这种格式比如nginx-offline-el7-x86_64-202406目录里再放一个MANIFEST.txt记录每个包的版本和用途。别小看这个习惯半年后你再翻出来没有 manifest 的包等于一堆无名 rpm根本不敢往生产上装。最后是一个幂等脚本的骨架核心是已装则跳过、未装则装、装完必验#!/bin/bash set -e # 任何一步失败立即退出避免半装状态继续往下跑 REPO/opt/localrepo rpm -q nginx /dev/null 21 { echo nginx already installed; exit 0; } # 本地源方式安装yum 负责解依赖 yum install -y --disablerepo* --enablerepolocal nginx # 装完立刻验证三件事语法、端口、进程 nginx -t systemctl enable --now nginx ss -lntp | grep -q nginx echo OK: nginx listening || { echo FAIL: not listening; exit 1; }set -e是这类脚本的底线没有它中间某步失败脚本还会继续跑最后给你一个看起来成功的假象。--disablerepo* --enablerepolocal是强制只用本地源防止脚本在能联网的机器上偷偷去拉外网包导致行为和离线环境不一致。最后那条ss | grep -q把进程活着升级成端口真的在听这才是可交付的验证标准。从那以后我每次交付离线环境都强制走一遍校验 → 装 → 对账 → 端口验证这四步哪怕时间再紧也不省。因为省下的那五分钟往往会在客户现场用两小时来还。希望这套流程帮到你下次再面对一台断网机器时心里有底。本文还有配套的精品资源点击获取
