简介这份资源面向需要在无外网环境下部署Web服务的Linux运维与后端人员提供nginx离线安装所需的完整rpm依赖集合重点解决数据中心、内网服务器等受限场景下软件包无法在线拉取的问题。压缩包共4个文件以gz归档为主另附一份html说明文档整体约62.15MB其中gcc与nginx相关依赖包分别打包便于按需解压安装。资源围绕gcc编译环境与nginx运行依赖两条主线组织读者可据此在目标机器上依次补齐编译工具链与Web服务器组件避免因缺少依赖导致的安装中断。目前已有1681人学习下载适合希望掌握离线部署流程、排查依赖冲突的初中级运维人员参考也可作为内网环境标准化部署的备查资料。1. 内网机器上装 nginx为什么我最后放弃了源码编译上周帮一个做电力监控的客户部署环境服务器在纯内网连 yum 源都没有只有一台跳板机能往外拷文件。需求很明确装 nginx 做反向代理前端是 Java 服务后端跑 Tomcat。我第一反应是源码编译结果./configure直接报错——没有 gcc没有 make连 pcre 和 zlib 的头文件都找不到。从零开始补编译工具链在离线环境里就是个无底洞。后来换了个思路既然系统是 CentOS 7.9那就用 rpm 包离线装。这份资源就是干这个的——它把 nginx 本体、gcc 编译器、以及 nginx 依赖的 pcre、zlib、openssl 这些 rpm 包全部打包在一起拷到目标机器上rpm -ivh就能跑起来。适合谁适合那些手里只有一台能联网的机器、目标服务器完全隔离、又不想折腾源码编译依赖链的运维和 Java 后端。下面把我实际操作的顺序和踩过的坑拆开讲。2. 离线 rpm 安装的依赖逻辑为什么不能只拷一个 nginx.rpm2.1 rpm 的依赖链是怎么卡住你的很多人第一次离线装 nginx会去下载一个nginx-1.x.x.rpm就完事。拷到目标机器上执行rpm -ivh nginx.rpm立刻报一堆Failed dependencies。原因很简单nginx 的 rpm 包在构建时声明了运行时依赖比如pcre、zlib、openssl-libs还有更底层的glibc、libcrypto等。这些依赖不会自动打包进 nginx 的 rpm 里rpm 安装器只负责检查不负责帮你找。更麻烦的是 gcc。如果你后续要装任何需要编译的模块或者 nginx 本身想加第三方模块没有 gcc 就寸步难行。而 gcc 在 CentOS 7 上又依赖cpp、glibc-devel、kernel-headers、libmpc、mpfr、gmp等一串包。这些包之间还有版本匹配关系随便下几个版本对不上就会陷入“装 A 要 B装 B 要 C装 C 又缺 A”的死循环。这份资源的价值就在于它把这条依赖链提前在联网机器上跑通了把需要的 rpm 全部收齐并且版本是互相兼容的。你拿到的是一个闭环不是散件。2.2 资源里到底放了什么根据包名和常见 CentOS 7.9 环境我整理了一下这份 rpm 集合的构成。实际文件列表可能因打包者略有差异但核心组件如下类别典型包名作用nginx 本体nginx-1.20.2-1.el7.x86_64.rpm主程序nginx 依赖pcre-8.32-17.el7.x86_64.rpm正则表达式支持nginx 依赖zlib-1.2.7-18.el7.x86_64.rpmgzip 压缩nginx 依赖openssl-libs-1.0.2k-19.el7.x86_64.rpmSSL/TLS编译工具gcc-4.8.5-44.el7.x86_64.rpmC 编译器编译工具gcc-c-4.8.5-44.el7.x86_64.rpmC 编译器编译依赖cpp-4.8.5-44.el7.x86_64.rpm预处理器编译依赖glibc-devel-2.17-317.el7.x86_64.rpm标准库头文件编译依赖kernel-headers-3.10.0-1160.el7.x86_64.rpm内核头文件编译依赖libmpc-1.0.1-3.el7.x86_64.rpm数学库编译依赖mpfr-3.1.1-4.el7.x86_64.rpm高精度浮点编译依赖gmp-6.0.0-15.el7.x86_64.rpm大数运算注意不同 CentOS 7 小版本7.6 / 7.7 / 7.9的 glibc 和 kernel-headers 版本号不同强行混装可能报Error: Package: ... requires: ...。这份资源如果标注了适用 7.9就尽量别往 7.6 上硬套。2.3 安装顺序有讲究rpm 安装不像 yum 会自动解析依赖顺序手动rpm -ivh *.rpm虽然能一次性喂进去但 rpm 内部还是会按依赖关系决定安装次序。如果依赖包版本不对它会直接中断留下半装状态。我一般会先把所有包放在一个目录然后执行# 进入 rpm 存放目录 cd /opt/offline-rpm # 一次性安装所有包rpm 会自动处理依赖顺序 rpm -ivh *.rpm --nodeps --force这里--nodeps是跳过依赖检查--force是强制覆盖已安装的包。但这两个参数是双刃剑如果你确定包集合是完整的用它们可以避免 rpm 因为某个已存在的旧版本而卡住如果不确定跳过依赖检查可能导致装完跑不起来。我的习惯是先不加参数跑一遍看报什么错再决定是否加--nodeps。3. 从联网机到内网机rpm 包收集与传输的完整操作3.1 在联网机器上把依赖下全如果你手头没有现成的 rpm 集合需要自己从一台能联网的 CentOS 7 上把包拉下来。最稳的方式是用yumdownloader它只下载不安装而且会把依赖一起拉下来。# 安装 yum-utils里面包含 yumdownloader yum install -y yum-utils # 创建存放目录 mkdir -p /tmp/nginx-offline cd /tmp/nginx-offline # 下载 nginx 及其所有依赖 yumdownloader --resolve --destdir/tmp/nginx-offline nginx # 下载 gcc 及其所有依赖 yumdownloader --resolve --destdir/tmp/nginx-offline gcc gcc-c--resolve是关键参数它会递归解析依赖树把 nginx 依赖的 pcre、zlib、openssl 以及 gcc 依赖的 cpp、glibc-devel、kernel-headers 全部下载到指定目录。--destdir指定输出路径不写的话默认在当前目录。执行完之后ls /tmp/nginx-offline应该能看到几十个 rpm 文件。如果只有 nginx 一个包说明--resolve没生效检查一下 yum 源配置。3.2 打包传输到内网把所有 rpm 打成一个 tar 包方便拷贝# 打包 tar -czvf nginx-offline.tar.gz /tmp/nginx-offline # 查看包大小通常 30-50MB 左右 ls -lh nginx-offline.tar.gz传输方式取决于你的环境U 盘、scp 到跳板机再中转、或者通过堡垒机上传。这一步没什么技术含量但要注意文件完整性。我遇到过 tar 包在拷贝过程中损坏解压时报gzip: stdin: unexpected end of file。解决办法是传输前后各算一次 md5# 联网机 md5sum nginx-offline.tar.gz # 内网机 md5sum nginx-offline.tar.gz两个值一致再解压能省掉很多“为什么装不上”的玄学排查。3.3 内网机器上的安装与验证到了目标机器解压后先别急着装。看一眼系统版本和已安装的包# 查看系统版本 cat /etc/redhat-release # 查看是否已有 nginx 或 gcc rpm -qa | grep -E nginx|gcc如果已经有旧版本 nginx先卸载干净# 卸载旧 nginx保留配置文件 rpm -e nginx然后进入解压目录执行安装cd /opt/nginx-offline rpm -ivh *.rpm安装完成后验证# 查看 nginx 版本 nginx -v # 查看 gcc 版本 gcc --version # 启动 nginx systemctl start nginx # 检查端口 ss -tlnp | grep 80如果nginx -v输出nginx version: nginx/1.20.2gcc --version输出gcc (GCC) 4.8.5并且 80 端口处于 LISTEN 状态说明整套环境已经就位。4. 避坑与排查离线装 nginx 最常见的五个翻车现场4.1 现象rpm -ivh 报 “error: Failed dependencies: libpcre.so.1()(64bit) is needed”原因pcre 包没装或者版本不对。nginx 的动态链接库依赖libpcre.so.1这个文件由 pcre 包提供。如果你只拷了 nginx 没拷 pcre或者拷的 pcre 是 i686 版本而系统是 x86_64就会报这个错。解决确认 pcre 包的架构是 x86_64并且版本与 nginx 编译时一致。用rpm -qlp pcre-*.rpm | grep libpcre查看包内是否包含该 so 文件。如果缺失从同版本 CentOS 的 yum 源重新下载。4.2 现象gcc 装完后执行 gcc --version 仍然显示旧版本原因系统里存在多个 gcc 版本/usr/bin/gcc是一个软链接指向了旧版本。rpm 安装新 gcc 时如果没有正确更新 alternatives 或者软链接命令行调用的还是老的。解决用which gcc和ls -l /usr/bin/gcc查看实际指向。如果是软链接问题手动重建# 查看当前 gcc 路径 which gcc ls -l /usr/bin/gcc # 如果指向旧版本更新软链接 ln -sf /usr/bin/gcc-4.8.5 /usr/bin/gcc更规范的做法是用alternatives管理但离线环境下直接改软链接更快。4.3 现象nginx 启动报 “nginx: error while loading shared libraries: libssl.so.10: cannot open shared object file”原因openssl-libs 没装或者版本不匹配。nginx 如果编译时启用了 SSL 模块运行时需要libssl.so.10和libcrypto.so.10。CentOS 7 的 openssl-libs 提供这两个文件。解决安装 openssl-libs 包然后用ldd $(which nginx) | grep ssl检查动态链接是否解析成功。如果显示not found说明库路径不对可以手动建立软链接或设置LD_LIBRARY_PATH。4.4 现象rpm 安装过程中提示 “package xxx is already installed”原因目标机器上已经有同名包可能是之前装过但没卸干净或者系统自带。rpm 默认不允许重复安装。解决如果确认旧包不影响加--force强制覆盖如果旧包版本冲突先rpm -e卸载。注意卸载时如果其他包依赖它会报依赖错误这时候要么一起卸要么用--nodeps跳过。4.5 现象装完 nginx 后 systemctl start nginx 失败日志显示 “Permission denied”原因SELinux 拦截。CentOS 7 默认开启 SELinuxnginx 以非标准路径运行时可能被拒绝访问。解决先看/var/log/nginx/error.log和journalctl -u nginx。如果是 SELinux 问题临时设为 permissive 模式验证setenforce 0如果确认是 SELinux 导致永久关闭需要改/etc/selinux/config把SELINUXenforcing改为SELINUXdisabled然后重启。生产环境更推荐用semanage添加策略但离线环境下关闭是最快的验证手段。5. 装完之后把 nginx 配成 Java 服务的反向代理5.1 一个最小可用的反向代理配置nginx 跑起来只是第一步你的目标是让它给 Java 服务做反向代理。假设后端 Tomcat 跑在127.0.0.1:8080前端希望通过 80 端口访问。编辑/etc/nginx/nginx.conf或者直接在conf.d/下新建一个配置文件server { listen 80; server_name localhost; # 静态资源交给 nginx 直接返回 location /static/ { root /var/www/html; expires 7d; } # 动态请求转发给 Tomcat location / { proxy_pass http://127.0.0.1:8080; 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; # 超时设置避免后端慢时 nginx 直接断连 proxy_connect_timeout 30s; proxy_read_timeout 60s; proxy_send_timeout 60s; } }proxy_set_header这几行是必须的。如果不传X-Real-IP和X-Forwarded-ForTomcat 里拿到的客户端 IP 全是127.0.0.1日志和限流都没法做。proxy_read_timeout默认 60 秒如果后端有长任务需要调大。改完配置后先测试语法nginx -t输出syntax is ok和test is successful再重载systemctl reload nginx5.2 验证反向代理是否生效在浏览器或者用 curl 访问curl -I http://localhost/如果返回HTTP/1.1 200或者302并且响应头里有Server: nginx说明代理链路通了。再看 Tomcat 的访问日志应该能看到来自 nginx 的请求记录并且X-Forwarded-For里是真实客户端 IP。5.3 离线环境下的日志排查习惯离线机器没有外网出问题只能看本地日志。我一般会同时盯三个地方日志位置看什么/var/log/nginx/error.lognginx 自身错误如权限、上游连接失败/var/log/nginx/access.log请求记录确认流量是否到达 nginxjournalctl -u nginxsystemd 层面的启动失败原因如果 nginx 启动失败但 error.log 是空的优先看journalctl -u nginx通常是端口占用或者配置文件路径错误。5.4 一个容易忽略的细节rpm 安装的 nginx 默认用户rpm 包安装的 nginx 默认以nginx用户运行这个用户是包安装时自动创建的。如果你把静态资源放在/var/www/html要确保nginx用户有读权限chown -R nginx:nginx /var/www/html chmod -R 755 /var/www/html否则访问静态资源会返回 403而 error.log 里写的是Permission denied。这个坑我踩过不止一次后来每次配完静态目录都习惯性跑一遍namei -l /var/www/html看权限链。从那以后我每次离线部署 nginx都会先把 rpm 集合的 md5 对一遍装完立刻nginx -t加systemctl reload再配一个最小反向代理跑通 200 响应才敢交给业务方。这套流程走下来基本不会再出现“装是装上了但跑不起来”的尴尬。希望帮到你。本文还有配套的精品资源点击获取
内网离线环境安装Nginx：放弃源码编译，用RPM包解决依赖链
简介这份资源面向需要在无外网环境下部署Web服务的Linux运维与后端人员提供nginx离线安装所需的完整rpm依赖集合重点解决数据中心、内网服务器等受限场景下软件包无法在线拉取的问题。压缩包共4个文件以gz归档为主另附一份html说明文档整体约62.15MB其中gcc与nginx相关依赖包分别打包便于按需解压安装。资源围绕gcc编译环境与nginx运行依赖两条主线组织读者可据此在目标机器上依次补齐编译工具链与Web服务器组件避免因缺少依赖导致的安装中断。目前已有1681人学习下载适合希望掌握离线部署流程、排查依赖冲突的初中级运维人员参考也可作为内网环境标准化部署的备查资料。1. 内网机器上装 nginx为什么我最后放弃了源码编译上周帮一个做电力监控的客户部署环境服务器在纯内网连 yum 源都没有只有一台跳板机能往外拷文件。需求很明确装 nginx 做反向代理前端是 Java 服务后端跑 Tomcat。我第一反应是源码编译结果./configure直接报错——没有 gcc没有 make连 pcre 和 zlib 的头文件都找不到。从零开始补编译工具链在离线环境里就是个无底洞。后来换了个思路既然系统是 CentOS 7.9那就用 rpm 包离线装。这份资源就是干这个的——它把 nginx 本体、gcc 编译器、以及 nginx 依赖的 pcre、zlib、openssl 这些 rpm 包全部打包在一起拷到目标机器上rpm -ivh就能跑起来。适合谁适合那些手里只有一台能联网的机器、目标服务器完全隔离、又不想折腾源码编译依赖链的运维和 Java 后端。下面把我实际操作的顺序和踩过的坑拆开讲。2. 离线 rpm 安装的依赖逻辑为什么不能只拷一个 nginx.rpm2.1 rpm 的依赖链是怎么卡住你的很多人第一次离线装 nginx会去下载一个nginx-1.x.x.rpm就完事。拷到目标机器上执行rpm -ivh nginx.rpm立刻报一堆Failed dependencies。原因很简单nginx 的 rpm 包在构建时声明了运行时依赖比如pcre、zlib、openssl-libs还有更底层的glibc、libcrypto等。这些依赖不会自动打包进 nginx 的 rpm 里rpm 安装器只负责检查不负责帮你找。更麻烦的是 gcc。如果你后续要装任何需要编译的模块或者 nginx 本身想加第三方模块没有 gcc 就寸步难行。而 gcc 在 CentOS 7 上又依赖cpp、glibc-devel、kernel-headers、libmpc、mpfr、gmp等一串包。这些包之间还有版本匹配关系随便下几个版本对不上就会陷入“装 A 要 B装 B 要 C装 C 又缺 A”的死循环。这份资源的价值就在于它把这条依赖链提前在联网机器上跑通了把需要的 rpm 全部收齐并且版本是互相兼容的。你拿到的是一个闭环不是散件。2.2 资源里到底放了什么根据包名和常见 CentOS 7.9 环境我整理了一下这份 rpm 集合的构成。实际文件列表可能因打包者略有差异但核心组件如下类别典型包名作用nginx 本体nginx-1.20.2-1.el7.x86_64.rpm主程序nginx 依赖pcre-8.32-17.el7.x86_64.rpm正则表达式支持nginx 依赖zlib-1.2.7-18.el7.x86_64.rpmgzip 压缩nginx 依赖openssl-libs-1.0.2k-19.el7.x86_64.rpmSSL/TLS编译工具gcc-4.8.5-44.el7.x86_64.rpmC 编译器编译工具gcc-c-4.8.5-44.el7.x86_64.rpmC 编译器编译依赖cpp-4.8.5-44.el7.x86_64.rpm预处理器编译依赖glibc-devel-2.17-317.el7.x86_64.rpm标准库头文件编译依赖kernel-headers-3.10.0-1160.el7.x86_64.rpm内核头文件编译依赖libmpc-1.0.1-3.el7.x86_64.rpm数学库编译依赖mpfr-3.1.1-4.el7.x86_64.rpm高精度浮点编译依赖gmp-6.0.0-15.el7.x86_64.rpm大数运算注意不同 CentOS 7 小版本7.6 / 7.7 / 7.9的 glibc 和 kernel-headers 版本号不同强行混装可能报Error: Package: ... requires: ...。这份资源如果标注了适用 7.9就尽量别往 7.6 上硬套。2.3 安装顺序有讲究rpm 安装不像 yum 会自动解析依赖顺序手动rpm -ivh *.rpm虽然能一次性喂进去但 rpm 内部还是会按依赖关系决定安装次序。如果依赖包版本不对它会直接中断留下半装状态。我一般会先把所有包放在一个目录然后执行# 进入 rpm 存放目录 cd /opt/offline-rpm # 一次性安装所有包rpm 会自动处理依赖顺序 rpm -ivh *.rpm --nodeps --force这里--nodeps是跳过依赖检查--force是强制覆盖已安装的包。但这两个参数是双刃剑如果你确定包集合是完整的用它们可以避免 rpm 因为某个已存在的旧版本而卡住如果不确定跳过依赖检查可能导致装完跑不起来。我的习惯是先不加参数跑一遍看报什么错再决定是否加--nodeps。3. 从联网机到内网机rpm 包收集与传输的完整操作3.1 在联网机器上把依赖下全如果你手头没有现成的 rpm 集合需要自己从一台能联网的 CentOS 7 上把包拉下来。最稳的方式是用yumdownloader它只下载不安装而且会把依赖一起拉下来。# 安装 yum-utils里面包含 yumdownloader yum install -y yum-utils # 创建存放目录 mkdir -p /tmp/nginx-offline cd /tmp/nginx-offline # 下载 nginx 及其所有依赖 yumdownloader --resolve --destdir/tmp/nginx-offline nginx # 下载 gcc 及其所有依赖 yumdownloader --resolve --destdir/tmp/nginx-offline gcc gcc-c--resolve是关键参数它会递归解析依赖树把 nginx 依赖的 pcre、zlib、openssl 以及 gcc 依赖的 cpp、glibc-devel、kernel-headers 全部下载到指定目录。--destdir指定输出路径不写的话默认在当前目录。执行完之后ls /tmp/nginx-offline应该能看到几十个 rpm 文件。如果只有 nginx 一个包说明--resolve没生效检查一下 yum 源配置。3.2 打包传输到内网把所有 rpm 打成一个 tar 包方便拷贝# 打包 tar -czvf nginx-offline.tar.gz /tmp/nginx-offline # 查看包大小通常 30-50MB 左右 ls -lh nginx-offline.tar.gz传输方式取决于你的环境U 盘、scp 到跳板机再中转、或者通过堡垒机上传。这一步没什么技术含量但要注意文件完整性。我遇到过 tar 包在拷贝过程中损坏解压时报gzip: stdin: unexpected end of file。解决办法是传输前后各算一次 md5# 联网机 md5sum nginx-offline.tar.gz # 内网机 md5sum nginx-offline.tar.gz两个值一致再解压能省掉很多“为什么装不上”的玄学排查。3.3 内网机器上的安装与验证到了目标机器解压后先别急着装。看一眼系统版本和已安装的包# 查看系统版本 cat /etc/redhat-release # 查看是否已有 nginx 或 gcc rpm -qa | grep -E nginx|gcc如果已经有旧版本 nginx先卸载干净# 卸载旧 nginx保留配置文件 rpm -e nginx然后进入解压目录执行安装cd /opt/nginx-offline rpm -ivh *.rpm安装完成后验证# 查看 nginx 版本 nginx -v # 查看 gcc 版本 gcc --version # 启动 nginx systemctl start nginx # 检查端口 ss -tlnp | grep 80如果nginx -v输出nginx version: nginx/1.20.2gcc --version输出gcc (GCC) 4.8.5并且 80 端口处于 LISTEN 状态说明整套环境已经就位。4. 避坑与排查离线装 nginx 最常见的五个翻车现场4.1 现象rpm -ivh 报 “error: Failed dependencies: libpcre.so.1()(64bit) is needed”原因pcre 包没装或者版本不对。nginx 的动态链接库依赖libpcre.so.1这个文件由 pcre 包提供。如果你只拷了 nginx 没拷 pcre或者拷的 pcre 是 i686 版本而系统是 x86_64就会报这个错。解决确认 pcre 包的架构是 x86_64并且版本与 nginx 编译时一致。用rpm -qlp pcre-*.rpm | grep libpcre查看包内是否包含该 so 文件。如果缺失从同版本 CentOS 的 yum 源重新下载。4.2 现象gcc 装完后执行 gcc --version 仍然显示旧版本原因系统里存在多个 gcc 版本/usr/bin/gcc是一个软链接指向了旧版本。rpm 安装新 gcc 时如果没有正确更新 alternatives 或者软链接命令行调用的还是老的。解决用which gcc和ls -l /usr/bin/gcc查看实际指向。如果是软链接问题手动重建# 查看当前 gcc 路径 which gcc ls -l /usr/bin/gcc # 如果指向旧版本更新软链接 ln -sf /usr/bin/gcc-4.8.5 /usr/bin/gcc更规范的做法是用alternatives管理但离线环境下直接改软链接更快。4.3 现象nginx 启动报 “nginx: error while loading shared libraries: libssl.so.10: cannot open shared object file”原因openssl-libs 没装或者版本不匹配。nginx 如果编译时启用了 SSL 模块运行时需要libssl.so.10和libcrypto.so.10。CentOS 7 的 openssl-libs 提供这两个文件。解决安装 openssl-libs 包然后用ldd $(which nginx) | grep ssl检查动态链接是否解析成功。如果显示not found说明库路径不对可以手动建立软链接或设置LD_LIBRARY_PATH。4.4 现象rpm 安装过程中提示 “package xxx is already installed”原因目标机器上已经有同名包可能是之前装过但没卸干净或者系统自带。rpm 默认不允许重复安装。解决如果确认旧包不影响加--force强制覆盖如果旧包版本冲突先rpm -e卸载。注意卸载时如果其他包依赖它会报依赖错误这时候要么一起卸要么用--nodeps跳过。4.5 现象装完 nginx 后 systemctl start nginx 失败日志显示 “Permission denied”原因SELinux 拦截。CentOS 7 默认开启 SELinuxnginx 以非标准路径运行时可能被拒绝访问。解决先看/var/log/nginx/error.log和journalctl -u nginx。如果是 SELinux 问题临时设为 permissive 模式验证setenforce 0如果确认是 SELinux 导致永久关闭需要改/etc/selinux/config把SELINUXenforcing改为SELINUXdisabled然后重启。生产环境更推荐用semanage添加策略但离线环境下关闭是最快的验证手段。5. 装完之后把 nginx 配成 Java 服务的反向代理5.1 一个最小可用的反向代理配置nginx 跑起来只是第一步你的目标是让它给 Java 服务做反向代理。假设后端 Tomcat 跑在127.0.0.1:8080前端希望通过 80 端口访问。编辑/etc/nginx/nginx.conf或者直接在conf.d/下新建一个配置文件server { listen 80; server_name localhost; # 静态资源交给 nginx 直接返回 location /static/ { root /var/www/html; expires 7d; } # 动态请求转发给 Tomcat location / { proxy_pass http://127.0.0.1:8080; 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; # 超时设置避免后端慢时 nginx 直接断连 proxy_connect_timeout 30s; proxy_read_timeout 60s; proxy_send_timeout 60s; } }proxy_set_header这几行是必须的。如果不传X-Real-IP和X-Forwarded-ForTomcat 里拿到的客户端 IP 全是127.0.0.1日志和限流都没法做。proxy_read_timeout默认 60 秒如果后端有长任务需要调大。改完配置后先测试语法nginx -t输出syntax is ok和test is successful再重载systemctl reload nginx5.2 验证反向代理是否生效在浏览器或者用 curl 访问curl -I http://localhost/如果返回HTTP/1.1 200或者302并且响应头里有Server: nginx说明代理链路通了。再看 Tomcat 的访问日志应该能看到来自 nginx 的请求记录并且X-Forwarded-For里是真实客户端 IP。5.3 离线环境下的日志排查习惯离线机器没有外网出问题只能看本地日志。我一般会同时盯三个地方日志位置看什么/var/log/nginx/error.lognginx 自身错误如权限、上游连接失败/var/log/nginx/access.log请求记录确认流量是否到达 nginxjournalctl -u nginxsystemd 层面的启动失败原因如果 nginx 启动失败但 error.log 是空的优先看journalctl -u nginx通常是端口占用或者配置文件路径错误。5.4 一个容易忽略的细节rpm 安装的 nginx 默认用户rpm 包安装的 nginx 默认以nginx用户运行这个用户是包安装时自动创建的。如果你把静态资源放在/var/www/html要确保nginx用户有读权限chown -R nginx:nginx /var/www/html chmod -R 755 /var/www/html否则访问静态资源会返回 403而 error.log 里写的是Permission denied。这个坑我踩过不止一次后来每次配完静态目录都习惯性跑一遍namei -l /var/www/html看权限链。从那以后我每次离线部署 nginx都会先把 rpm 集合的 md5 对一遍装完立刻nginx -t加systemctl reload再配一个最小反向代理跑通 200 响应才敢交给业务方。这套流程走下来基本不会再出现“装是装上了但跑不起来”的尴尬。希望帮到你。本文还有配套的精品资源点击获取
