做过几年服务器运维和Java后端的人对Nginx应该都不陌生。前一阵同事在给测试环境搭新服务照着网上教程吭哧吭哧装Nginx结果configure那一步就报缺PCRE库装完PCRE又发现没带SSL模块反反复整了半天最后我过去一行命令直接搞定。这件事让我觉得与其让大家继续零散地搜教程不如把Nginx三种主流安装方式——源码编译、包管理器、Docker容器化外加内网常用的离线方案一次讲透。每种的适用场景、操作步骤、常见坑和底层逻辑我都会说清楚新手能照着复现老手也能查漏补缺。1. 三种安装方式分别什么时候用——先搞清场景再动手很多人一上来就问“怎么装”其实更应该先问“在什么环境里装、装来干什么”。选错安装方式后面全是麻烦。1.1 三种方式的脾气秉性完全不同先给一个直观的对比看过之后你就知道为什么不能乱选维度源码编译包管理器yum/aptDocker容器安装速度慢要编译最快秒级快取决于镜像拉取版本自由度完全可控想装哪个版本装哪个受仓库源限制往往偏旧由镜像Tag决定模块扩展编译时自定义模块最灵活依赖官方或第三方源编译过的镜像是死的加模块要换镜像或自己build目录位置自己定默认/usr/local/nginx系统标准目录如/etc/nginx容器内部与宿主机隔离卸载/回滚麻烦要手动清理一行命令删容器就行最干净适合场景定制化要求高、生产环境、学习原理开发环境、快速试用、系统深度绑定多项目隔离、CI/CD、异地迁移这个表格建议收藏后面每次纠结选哪种的时候拿出来扫一眼。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平台为例最常见的是这四个gccC语言编译器没它连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-devCentOS/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接下来就交给makemake -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通常得先装EPELExtra Packages for Enterprise Linuxsudo 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] namenginx stable repo baseurlhttp://nginx.org/packages/centos/7/$basearch/ gpgcheck1 enabled1 gpgkeyhttps://nginx.org/keys/nginx_signing.key module_hotfixestrue EOF sudo yum install -y nginxUbuntu也有类似官方源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/defaultUbuntu系特别注意。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通常是101chown -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进容器reloaddocker exec multi-nginx nginx -t docker exec multi-nginx nginx -s reloadreload是平滑重载配置不中断正在处理的请求适合频繁调整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.1ps看进程在不在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如果放行后恢复正常就是这个原因。生产环境不建议直接关SELinuxsetenforce 0而是用audit2allow生成对应的策略模块或者像上面这样按需设置布尔值。防火墙同理sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --reloadUbuntu上是ufw allow 80/tcp。这三板斧下去绝大多数“装完访问不了”的问题都能定位到原因——端口冲突、SELinux、防火墙顺序也是从内到外排查先本机curl再跨机器telnet最后查安全策略。6.4 查看错误日志遇到问题先看这里很多人一遇问题就百度其实Nginx自己的错误日志已经把原因写得很明白了。默认日志位置根据安装方式不同有区别源码编译/usr/local/nginx/logs/error.log包管理器/var/log/nginx/error.logDocker容器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安装和排查上比之前更从容一点。
做过几年服务器运维和Java后端的人对Nginx应该都不陌生。前一阵同事在给测试环境搭新服务照着网上教程吭哧吭哧装Nginx结果configure那一步就报缺PCRE库装完PCRE又发现没带SSL模块反反复整了半天最后我过去一行命令直接搞定。这件事让我觉得与其让大家继续零散地搜教程不如把Nginx三种主流安装方式——源码编译、包管理器、Docker容器化外加内网常用的离线方案一次讲透。每种的适用场景、操作步骤、常见坑和底层逻辑我都会说清楚新手能照着复现老手也能查漏补缺。1. 三种安装方式分别什么时候用——先搞清场景再动手很多人一上来就问“怎么装”其实更应该先问“在什么环境里装、装来干什么”。选错安装方式后面全是麻烦。1.1 三种方式的脾气秉性完全不同先给一个直观的对比看过之后你就知道为什么不能乱选维度源码编译包管理器yum/aptDocker容器安装速度慢要编译最快秒级快取决于镜像拉取版本自由度完全可控想装哪个版本装哪个受仓库源限制往往偏旧由镜像Tag决定模块扩展编译时自定义模块最灵活依赖官方或第三方源编译过的镜像是死的加模块要换镜像或自己build目录位置自己定默认/usr/local/nginx系统标准目录如/etc/nginx容器内部与宿主机隔离卸载/回滚麻烦要手动清理一行命令删容器就行最干净适合场景定制化要求高、生产环境、学习原理开发环境、快速试用、系统深度绑定多项目隔离、CI/CD、异地迁移这个表格建议收藏后面每次纠结选哪种的时候拿出来扫一眼。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平台为例最常见的是这四个gccC语言编译器没它连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-devCentOS/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接下来就交给makemake -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通常得先装EPELExtra Packages for Enterprise Linuxsudo 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] namenginx stable repo baseurlhttp://nginx.org/packages/centos/7/$basearch/ gpgcheck1 enabled1 gpgkeyhttps://nginx.org/keys/nginx_signing.key module_hotfixestrue EOF sudo yum install -y nginxUbuntu也有类似官方源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/defaultUbuntu系特别注意。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通常是101chown -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进容器reloaddocker exec multi-nginx nginx -t docker exec multi-nginx nginx -s reloadreload是平滑重载配置不中断正在处理的请求适合频繁调整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.1ps看进程在不在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如果放行后恢复正常就是这个原因。生产环境不建议直接关SELinuxsetenforce 0而是用audit2allow生成对应的策略模块或者像上面这样按需设置布尔值。防火墙同理sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --reloadUbuntu上是ufw allow 80/tcp。这三板斧下去绝大多数“装完访问不了”的问题都能定位到原因——端口冲突、SELinux、防火墙顺序也是从内到外排查先本机curl再跨机器telnet最后查安全策略。6.4 查看错误日志遇到问题先看这里很多人一遇问题就百度其实Nginx自己的错误日志已经把原因写得很明白了。默认日志位置根据安装方式不同有区别源码编译/usr/local/nginx/logs/error.log包管理器/var/log/nginx/error.logDocker容器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安装和排查上比之前更从容一点。
