Nginx安装全指南：源码编译、包管理器、Docker与离线部署一次讲透

做过几年服务器运维和Java后端的人，对Nginx应该都不陌生。前一阵同事在给测试环境搭新服务，照着网上教程吭哧吭哧装Nginx，结果configure那一步就报缺PCRE库，装完PCRE又发现没带SSL模块，反反复整了半天，最后我过去一行命令直接搞定。这件事让我觉得，与其让大家继续零散地搜教程，不如把Nginx三种主流安装方式——源码编译、包管理器、Docker容器化，外加内网常用的离线方案，一次讲透。每种的适用场景、操作步骤、常见坑和底层逻辑我都会说清楚，新手能照着复现，老手也能查漏补缺。

1. 三种安装方式分别什么时候用——先搞清场景再动手

很多人一上来就问“怎么装”，其实更应该先问“在什么环境里装、装来干什么”。选错安装方式，后面全是麻烦。

1.1 三种方式的脾气秉性完全不同

先给一个直观的对比，看过之后你就知道为什么不能乱选：

这个表格建议收藏，后面每次纠结选哪种的时候拿出来扫一眼。

1.2 我踩过的选型事故：编译时漏了SSL模块

有一年我负责部署一个需要频繁做HTTPS反向代理的服务，图省事直接从系统源用yum装了个Nginx。量不大的时候一切正常，后来要上HTTP/2和新版本TLS协议，才发现仓库里的Nginx版本太旧，连--with-http_ssl_module这个编译选项对应的官方模块行为都已经变了。想换新版本，又不敢直接动正在跑业务的机器，最后只能临时加一台新机器做迁移，那个周末我都是在机房里过的。

反过来，如果你只是本地联调，装源码版就是给自己找罪受——下载依赖、跑configure、等编译，半小时一步没走完，开发热情已经消磨光了。所以我的习惯很简单：本机能跑就行选包管理器，要求可控、要上生产选源码，要隔离、要复制环境选Docker。

2. 源码编译安装：从configure到make install的完整链路

源码编译是三种方式里最麻烦但最“通透”的，只要完整走一遍，Nginx的安装原理、目录结构和模块机制就全清楚了。这也是我建议每位想深入Nginx的人至少手动做一次的原因。

2.1 编译之前必须搞懂的依赖四件套

Nginx源码编译不是解压完就能跑，它依赖几个基础的库。以Linux平台为例，最常见的是这四个：

• gcc：C语言编译器，没它连make都进行不了。
• PCRE库：Nginx重写模块（rewrite）和正则表达式匹配的基础。
• zlib库：HTTP头部gzip压缩的依赖，做传输压缩时必需。
• OpenSSL库：HTTPS/SSL/TLS功能的基础，版本直接影响支持的协议等级。

你可以先检查一下系统里是否已经有这些：

gcc --version pcre-config --version zlib-config --version openssl version

如果你用的是最小化安装的CentOS或者纯净的Ubuntu Server，大概率会缺几个。Debian/Ubuntu系可以用一条命令补齐：

sudo apt update sudo apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev

CentOS/RHEL系则对应：

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

注意：这里有个很容易踩的坑——不要只装运行库而不装-devel开发包。configure检查的是头文件（.h），不是动态库本身。我记得有新手同事明明装了pcre，但configure仍然报“the HTTP rewrite module requires the PCRE library”，就是因为他只装了什么pcre2，没装libpcre3-dev或pcre-devel。

2.2 下载并解压对应版本的源码

去Nginx官网下载想要的版本，我建议生产环境选择Stable稳定版，别追最新mainline。下载时认准.tar.gz结尾的源码包：

wget https://nginx.org/download/nginx-1.26.2.tar.gz tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2

如果你对文件完整性有要求，可以顺手下载同目录下的.asc签名文件，用PGP校验一手，虽然大多数内网部署没这个条件，但公网下载建议养成习惯。

2.3 configure参数是整场戏的核心

进入到解压出来的目录后，最关键的步骤是configure。它相当于Nginx的“体检+量体裁衣”环节，会检查系统环境、依赖库，并根据你给的参数决定启用哪些模块、安装到哪里。

常用的配置组合是这种：

./configure \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-pcre \ --with-stream

几个关键参数解释一下：

• --prefix：指定安装根目录，默认是/usr/local/nginx。所有配置文件、日志、二进制都会放到这个目录下面。想统一管理到/opt/nginx或/app/nginx这里改就行。
• --with-http_ssl_module：启用HTTPS支持。**没有这个参数，你后面配置listen 443 ssl会直接报错。**我见过很多线上事故就是编译时忘了加。
• --with-http_v2_module：启用HTTP/2。现在追求性能必加。
• --with-http_stub_status_module：提供/nginx_status页面，方便用Prometheus采集连接数指标。
• --with-stream：启用四层TCP/UDP代理。做数据库负载均衡、Redis代理时使用。
• --with-pcre：显式启用PCRE，如果前面依赖装好了，这里通常直接通过。

如果你想看一共还能配哪些参数，执行./configure --help，输出会列出所有可用选项。不用全看懂，建议把--with-http_ssl_module、--with-http_v2_module这种明显的安全、性能项优先掌握。

2.4 编译、安装与验证

configure通过之后，目录下会生成Makefile，接下来就交给make：

make -j$(nproc) sudo make install

-j$(nproc)的意思是让编译器用上所有CPU核心来并行编译，源码编译慢的话，这一步能省一半以上的时间。编译过程可能持续几分钟到十几分钟，取决于机器配置。

装完之后检查关键文件：

ls -l /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx -V

-V会打印出Nginx版本号以及刚才你configure时启用的所有编译参数，是日后排查模块有没有编进去的最快方法。

启动：

sudo /usr/local/nginx/sbin/nginx

查看是否起来：

ps -ef | grep nginx curl -I http://localhost

看到HTTP/1.1 200 OK（或者302，取决于默认首页），就说明源码安装成功了。

2.5 源码安装的卸载与升级，没那么可怕

很多人不敢用源码安装，是怕卸载不干净。其实Nginx源码版卸载不复杂，因为所有文件都在--prefix指定的目录里：

# 停止 sudo /usr/local/nginx/sbin/nginx -s stop # 删除整个目录 sudo rm -rf /usr/local/nginx # 清理可选的软链接 sudo rm -f /etc/systemd/system/nginx.service

升级则是在新源码目录里重新configure（参数保持一致或按需增加），然后：

make # 不要 make install，会覆盖配置！ sudo cp -f /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak sudo cp -f objs/nginx /usr/local/nginx/sbin/nginx sudo /usr/local/nginx/sbin/nginx -t sudo kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid)

用USR2信号平滑升级worker进程，这个操作不中断现有连接，是生产环境热升级的标准手法。

3. 包管理器安装：一条命令的便利与版本泥潭

如果你只是想快速跑起来，或者你对操作系统包管理机制有天然信任，那用yum或apt装Nginx是最省心的一条路。

3.1 Debian/Ubuntu系安装

Ubuntu、Debian默认仓库里就有Nginx，直接：

sudo apt update sudo apt install -y nginx

装完它就自动注册成了systemd服务：

sudo systemctl start nginx sudo systemctl enable nginx

这是包管理器安装的最大好处——服务管理、开机自启、日志清理这些活全被系统接管了。

3.2 CentOS/RHEL系安装与EPEL源的问题

CentOS原生源里没有Nginx，通常得先装EPEL（Extra Packages for Enterprise Linux）：

sudo yum install -y epel-release sudo yum install -y nginx

但EPEL里的Nginx版本更新严重滞后，有时候生产环境都要用1.26了，EPEL还在1.20打转。想用官方维护的、版本较新的包，建议直接配置Nginx官方源。以CentOS 7为例：

sudo cat > /etc/yum.repos.d/nginx.repo <<'EOF' [nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/centos/7/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true EOF sudo yum install -y nginx

Ubuntu也有类似官方源：

sudo apt install -y curl gnupg2 ca-certificates lsb-release ubuntu-keyring curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install -y nginx

官方源和系统源的Nginx可能互相冲突，装之前先确认系统里没有残留的Nginx。我之前在一台机器上同时被两个源各装了一份，结果systemctl启动的是一份，nginx -t检查的又是另一份，配置文件改到怀疑人生。

3.3 包管理器安装的目录结构特点

用包管理器装出来的Nginx，目录布局和源码编译版差异很大，这个经常让源码版用户一头雾水：

• 主配置：/etc/nginx/nginx.conf
• 子配置目录：/etc/nginx/conf.d/（以.conf结尾的都会自动加载）
• 日志：/var/log/nginx/access.log和error.log
• 站点默认目录：/usr/share/nginx/html/
• 二进制：/usr/sbin/nginx

最关键的是conf.d/这个目录机制，主配置文件里通过include把这里的所有.conf文件导入。你部署新站点时根本不用改主配置，在conf.d/下建一个新的.conf文件就行：

server { listen 8080; server_name example.local; location / { root /var/www/example; index index.html; } }

然后：

sudo nginx -t sudo systemctl reload nginx

这种“即放即生效”的配置方式对多站点管理非常友好。

3.4 别忘了默认站点和版本旧这两个“坑”

包管理器安装默认会带一个default站点配置，监听80端口并指向一个欢迎页。新手经常遇到“我写好了配置但访问还是欢迎页”的问题，原因就是这个default配置占着端口。解决方案是删掉默认站点的软链或者直接移除：

sudo rm -f /etc/nginx/sites-enabled/default

Ubuntu系特别注意。CentOS系则是看/etc/nginx/conf.d/default.conf。

版本旧的问题我在本章开头提过了，这里给一条血泪教训：如果要用HTTP/2、要配TLSv1.3、要用更细粒度的限流，先确认包管理器仓库里的版本带不带对应能力。不带就果断换源码编译或者用Docker，别在旧版本上浪费时间调参数。

4. Docker部署：让Nginx成为可移植的基础设施

我从开始用Docker部署Nginx之后，“装Nginx”这个动作基本变成了一条命令的事。容器化带来的环境隔离和可移植性，让Nginx更像基础设施而不再是一个需要专人伺候的系统组件。

4.1 最简单的拉镜像起容器

假设你已经装好了Docker，一行命令完成启动：

docker run -d --name my-nginx -p 80:80 nginx:alpine

• -d：后台运行。
• --name：容器取名。
• -p 80:80：宿主机的80端口映射到容器的80端口。
• nginx:alpine：基于Alpine Linux的精简镜像，体积小，生产环境比默认的nginx:latest更推荐。

启动后直接访问本机80端口就能看到默认页面。

4.2 挂载目录：改写配置和静态资源

容器是临时的，如果你直接在容器里改配置，容器一删什么都没了，所以必须用-v参数把宿主机的目录或文件挂载进去：

docker run -d \ --name web-nginx \ -p 80:80 \ -p 443:443 \ -v /data/nginx/html:/usr/share/nginx/html \ -v /data/nginx/conf.d:/etc/nginx/conf.d \ -v /data/nginx/nginx.conf:/etc/nginx/nginx.conf \ -v /data/nginx/logs:/var/log/nginx \ nginx:alpine

这样配置和页面文件都在宿主机上，容器挂了换一个新的，数据一点不丢。用这个命令之前，先确认宿主机上/data/nginx这些目录存在：

mkdir -p /data/nginx/{html,conf.d,logs}

这里必须提醒一个权限问题：Nginx官方镜像里的worker进程以nginx用户运行，不是root。如果你挂载的宿主机配置或日志目录权限是700且属主是root，容器内进程可能写不了日志。我踩过的具体表现是：容器起来，页面也正常，但/data/nginx/logs下死活不生成access.log。后来把宿主机目录属主改成容器里那个nginx用户的UID（官方alpine镜像的nginx用户UID通常是101）：

chown -R 101:101 /data/nginx/logs

就正常了。不同镜像的UID可能不一样，直接docker exec my-nginx id nginx看一眼最准。

4.3 多项目挂载：不同站点如何共用一个Nginx容器

热词里提到的“挂载多个项目目录”，是Docker化Nginx最高频的需求。做法是把每个项目的配置放进conf.d/，再为每个项目映射一块静态资源目录：

docker run -d \ --name multi-nginx \ -p 80:80 \ -v /data/project-a/dist:/usr/share/nginx/html/project-a \ -v /data/project-b/dist:/usr/share/nginx/html/project-b \ -v /data/nginx/conf.d:/etc/nginx/conf.d \ nginx:alpine

对应的conf.d/project-a.conf长这样：

server { listen 80; server_name a.example.com; location / { root /usr/share/nginx/html/project-a; index index.html; } }

B项目同理，只要server_name不同，端口可以共用80。以后再接新项目，只需把前端构建产物放到宿主机新目录，再新增一个conf.d配置，重新reload容器进程即可。

4.4 容器内修改配置后的两大“生效”姿势

容器化之后的配置变更方式有两种，很多人傻傻分不清：

姿势一：docker exec进容器reload

docker exec multi-nginx nginx -t docker exec multi-nginx nginx -s reload

reload是平滑重载配置，不中断正在处理的请求，适合频繁调整Nginx配置的场景。

姿势二：删容器换新的

docker restart multi-nginx

这其实是重启容器，不是单纯reload。它会让容器生命周期走一遍，代价是这段时间内连接可能断开，但好处是能把容器内外部状态彻底重置。如果是挂载了卷、配置都外部化的场景，重启容器和reload效果差不多。

注意：改了宿主机上的nginx.conf或conf.d里文件后，容器里的Nginx是感知不到的，必须reload或重启容器才能拿到新配置。这个逻辑和直接在服务器上装Nginx完全不同，容器抽象层让“文件变更通知”这件事不存在了。我见过有人改了宿主机配置，一等半小时说“Nginx不生效”，就是这个原因。

4.5 docker-compose：多人协作时更推荐的方式

docker run参数一多就难维护，项目多了还得再封装脚本。这种情况下用docker-compose.yml管理更成熟：

version: '3' services: nginx: image: nginx:alpine container_name: ops-nginx ports: - "80:80" - "443:443" volumes: - /data/nginx/conf.d:/etc/nginx/conf.d - /data/nginx/html:/usr/share/nginx/html - /data/nginx/logs:/var/log/nginx restart: always

然后：

docker compose up -d

配置变更后：

docker compose exec nginx nginx -s reload

整套流程和团队协作的工作流很搭，配置能入库、能review，比手动敲docker run可靠得多。

5. 内网离线环境：没有外网也能装Nginx的三条路

很多单位的生产内网和外网物理隔离，既没有yum源也拉不了Docker镜像。这时候装Nginx属于典型的离线安装，热词里“linux离线安装nginx”就是这个场景。离线环境有三条路，按推荐程度排：

5.1 离线源码编译（最推荐）

在有外网的机器上提前下载好源码包和依赖包，用优盘或内网传输工具拷进去。源码包的依赖下载清单如下：

wget https://nginx.org/download/nginx-1.26.2.tar.gz wget https://ftp.pcre.org/pub/pcre/pcre-8.45.tar.gz wget https://www.zlib.net/zlib-1.3.1.tar.gz wget https://www.openssl.org/source/openssl-3.0.14.tar.gz

到内网机器上解压，然后configure时把依赖路径指过去：

./configure \ --prefix=/usr/local/nginx \ --with-pcre=../pcre-8.45 \ --with-zlib=../zlib-1.3.1 \ --with-openssl=../openssl-3.0.14 \ --with-http_ssl_module \ --with-http_v2_module

--with-pcre、--with-zlib、--with-openssl后面跟的路径是依赖包源码解压出来的目录位置，Nginx会把这些库一起编译进去，不用系统安装动态库。这种方式的优势是不污染系统环境，依赖完全自包含，而且动态编译出来的二进制在相同Linux发行版上通常可以直接拷贝复用。

如果你连编译器都没有，那这条也走不通，看下一种。

5.2 离线rpm包方式

在有外网的CentOS机器上用yumdownloader把Nginx及其依赖全拉下来：

# 安装yum-utils sudo yum install -y yum-utils # 仅下载不安装 sudo yumdownloader --resolve --destdir=/tmp/nginx-rpms nginx

把/tmp/nginx-rpms里的rpm包拷到内网机器，然后：

sudo yum localinstall /tmp/nginx-rpms/*.rpm -y

这里有个好处：rpm安装方式会自动创建systemd服务、系统用户、标准目录结构，对运维最友好。缺点是包的版本取决于你在外网拉取时那个源的版本。

5.3 编译好二进制直接拷贝（备选方案）

如果内网机器和编译机器是同样的Linux版本（如都是CentOS 7.9），你可以把在另一台机器上用源码编译好的整个/usr/local/nginx目录打成压缩包，拷进内网直接解压用：

tar -czvf nginx-binary.tar.gz /usr/local/nginx

到内网：

mkdir -p /usr/local/nginx tar -xzvf nginx-binary.tar.gz -C /usr/local /usr/local/nginx/sbin/nginx

这个办法最快，但有前提：内网机器的glibc版本不能比你编译机器的低。怎么确认：

ldd --version

如果内网机器的glibc主导版本号小，那基本跑不起来。解决方式是在编译机器上多用几个发行版做兼容测试，或者直接用前面说的纯静态编译方式。这种方式不适合正式生产环境，但如果只是临时要个Nginx做联调，它能帮你省掉所有编译等待的时间。

6. 装完不等于完事：启动验证与日常维护经验

不管用三种方式里的哪一种装完，最终都要过一遍验证和维护清单。根据热词里大量“nginx启动命令”“nginx状态码”“nginx配置文件详解”的搜索需求，说明很多人卡在装完之后这一步。我干脆把经验按条梳理清楚。

6.1 启动、语法检查和查看状态的标准动作

启动之前一定要先做语法检查：

nginx -t

这句会告诉你配置文件有没有语法错误。如果是源码安装，可能需要指定路径：

/usr/local/nginx/sbin/nginx -t

输出syntax is ok和test is successful就说明配置没问题。没报错再启动：

nginx # 前台方式（默认），常用源码包 nginx -s start # 部分版本支持 systemctl start nginx # 包管理器安装推荐

查看Nginx是否在运行，我最推荐的两个命令：

ps -ef | grep nginx curl -I http://127.0.0.1

ps看进程在不在，curl看服务是否真的响应。有时候进程在但端口是死的，ps是骗人的，curl -I的输出才是真相。想看Nginx版本和编译参数的：

nginx -V

-V大小写敏感，小写只输出版本号，大写会把编译参数、模块列表一起打出来。

6.2 一个90%新手都会遇到的启动失败场景：80端口被占用

Nginx默认监听80端口，如果这台机器已经跑了Apache、httpd或者其他服务，启动大概率报：

[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

排查步骤：

sudo netstat -tlnp | grep :80

或者新版系统用：

sudo ss -tlnp | grep :80

看到什么进程占了80，要么把它的端口改掉，要么干脆停掉它。如果你不想动现有服务，可以改Nginx监听端口，比如改到8080，重启之后再访问http://IP:8080验证。场景不同，解决路径就不同，这种“从报错到定位”的思路比背命令更重要。

6.3 SELinux和防火墙是另外两个拦路虎

CentOS/RHEL系还有个传统艺能：SELinux拦截。表现很诡异，Nginx进程活着，配置文件也正确，但外面就是访问不了80端口。查看SELinux状态：

getenforce

显示Enforcing就是拦截状态。快速验证是不是它的锅，可以先临时放行：

sudo setsebool -P httpd_can_network_connect 1

如果放行后恢复正常，就是这个原因。生产环境不建议直接关SELinux（setenforce 0），而是用audit2allow生成对应的策略模块，或者像上面这样按需设置布尔值。防火墙同理：

sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --reload

Ubuntu上是ufw allow 80/tcp。

这三板斧下去，绝大多数“装完访问不了”的问题都能定位到原因——端口冲突、SELinux、防火墙，顺序也是从内到外排查：先本机curl，再跨机器telnet，最后查安全策略。

6.4 查看错误日志：遇到问题先看这里

很多人一遇问题就百度，其实Nginx自己的错误日志已经把原因写得很明白了。默认日志位置根据安装方式不同有区别：

• 源码编译：/usr/local/nginx/logs/error.log
• 包管理器：/var/log/nginx/error.log
• Docker容器：docker logs <container_name>，或者挂载的宿主机日志目录

查看最近几十行错误：

tail -n 50 /var/log/nginx/error.log

遇到[emerg]级别的一定要立刻处理，这是启动级别的硬错误；[error]和[crit]要根据是否是高频报错来判断。曾经有个线上事故，现象是偶发502，所有人都在调超时、调缓存，最后发现是错误日志里疯狂刷“upstream prematurely closed connection”，查到底是对应后端服务频繁重启。这个经验想分享的就是：Nginx的错误日志是你最忠实的排障伙伴，养成交叉验证的习惯，别靠猜。

写在最后的个人体会

三种安装方式我分别在不同的项目阶段用过，现在基本形成了一套固定的选择逻辑：日常开发用Docker起一个带官方源版本的容器，测试环境用包管理器装一份方便系统管理，生产环境需要定制模块就上源码编译，遇到内网隔离环境优先准备离线rpm或源码包。没有哪种方式是银弹，关键是清楚自己的场景最看重什么——是速度、是可控、还是可移植。最后再分享一个小技巧：不管用哪种方式装完，都顺手把nginx -V的输出保存到一份环境文档里，下次升级、迁移的时候，这份记录能帮你少踩很多坑。希望这篇内容能让你在Nginx安装和排查上，比之前更从容一点。