装个 Nginx 而已我见过太多人卡在第一步一台刚交付的机器系统装完SSH 进去nginx -v报 command not found然后开始搜nginx 安装教程翻到一篇让下载.tar.gz编译的跟着./configure敲了半小时最后卡在pcre.h not found或者openssl version mismatch上一整天没了。其实绝大多数场景根本用不着编译用系统自带的软件包管理器在线安装就够了——CentOS 系一条yum install nginxUbuntu 系一条apt install nginx两分钟出结果还自带 systemd 单元、日志轮转、默认配置文件卸载也干净。这篇写的就是这条路yum/apt 在线安装 Nginx 的完整过程从仓库来源判断、版本取舍到安装后的验证、端口放行、最小可用配置再到我这些年踩过的坑。适合刚接手服务器的新手也适合那些装了几十次但每次换发行版还得重新查一遍的老手——后半部分的仓库优先级、版本锁定、SELinux 权限这几块估计能帮你省掉一次线上事故。全文以实际能复现为准命令都是可以直接粘贴跑的。1. 在线安装之前先想清楚你要哪个版本的 Nginx很多人跳过这一步直接开装装完发现版本是 1.18 甚至 1.16用不了stream模块的新特性或者某个proxy_cache参数不认回头再折腾升级成本比一开始选对高得多。在线安装的核心分歧不在命令在包从哪个仓库来。1.1 三种安装方式的取舍逻辑先把选项摆开说清楚为什么日常场景我更推荐包管理器。方式典型做法优点代价适用场景发行版仓库yum install nginx/apt install nginx一条命令、依赖自动处理、systemd 集成、卸载干净版本偏旧模块固定绝大多数业务前置、内网服务、测试环境官方仓库添加 nginx.org 的 repo 后安装版本新、可选 stable/mainline、编译选项官方调好需手动加源和签名 key存在与系统包冲突风险需要较新特性、需要官方编译参数一致源码编译./configure make完全可控可裁剪模块、指定路径依赖手工解决、升级要重来、无包管理记录需要第三方模块、定制编译参数选包管理器的核心理由很实在运维的可维护性。一年后你或者接手的人想知道这台机器装了什么、版本多少、配置在哪、怎么升rpm -qi nginx或dpkg -l | grep nginx一行就出来了。源码编译装的东西全靠当时那个人留下的笔记人一走就成了黑盒。那什么时候必须走官方仓库我的判断线是发行版自带版本落后超过两个大版本且你确实要用到新版本才有的指令。比如 Ubuntu 22.04 自带的是 1.18.x而你配置里要用http2 on;这种 1.25.1 之后才支持的写法那就得加官方源。反之只是做反向代理、静态资源、常规 HTTPS1.18 完全够用没必要为了版本号折腾。提示不要为了版本新而升级生产环境的 Nginx。包管理器升级是原地替换二进制配置文件不兼容时的报错往往在重启那一刻才暴露。1.2 在线安装真正解决的三个问题第一是依赖地狱。Nginx 依赖 PCRE正则、zlibgzip、OpenSSLHTTPS源码编译最烦的就是这几个库的版本匹配尤其 OpenSSL 1.1 和 3.x 混装的环境。包管理器里这些是声明式依赖装 Nginx 的时候自动带上版本一定是这套系统验证过的组合。第二是服务集成。在线安装会自动创建nginx用户Ubuntu 系是www-data、生成/usr/lib/systemd/system/nginx.service、配置/etc/logrotate.d/nginx日志切割。这些看起来是小事但日志不切割的机器半年后/var/log/nginx/access.log涨到几个 G磁盘告警的时候你就知道痛了。第三是升级路径。yum update nginx或apt upgrade就能拿到安全补丁配合版本锁定还能精确控制。源码编译的升级等于重装一遍还得祈祷新的编译参数和旧的配置文件对得上。1.3 装机前的三项体检动手之前花三十秒确认三件事能避开后面 80% 的意外。# 1. 确认发行版和版本号 cat /etc/os-release # 2. 确认 80/443 端口没被占用 ss -lntp | grep -E :(80|443)\s # 3. 确认是否已经装过 nginx哪怕是别的途径装的 which nginx; nginx -v 21; rpm -q nginx 2/dev/null; dpkg -l | grep -w nginx端口占用这条最容易忽略。我遇到过一次机器上预装了某个面板自带的 Web 服务占着 80yum install nginx装完systemctl start nginx直接失败报Address already in use日志里一行bind() to 0.0.0.0:80 failed。新手看到这个第一反应是重装 Nginx其实跟 Nginx 一点关系没有。体检里第三条也有价值如果which nginx有输出但rpm -q nginx查不到说明是源码装的。这时候再走包管理器安装两套文件会打架——包管理器把二进制放到/usr/sbin/nginx而你 PATH 里优先命中的可能是/usr/local/nginx/sbin/nginx你以为重启生效了其实跑的还是老进程。2. 两套包管理体系的差异决定了命令怎么写CentOS 和 Ubuntu 的安装命令长得像底层模型完全不同。搞清楚这个遇到报错才不会瞎猜。2.1 yum/dnf 与 apt 的仓库模型对比维度CentOS / RHEL 系Ubuntu / Debian 系包格式.rpm.deb包管理器yumCentOS 7/ dnf8 及以上apt / apt-get仓库定义位置/etc/yum.repos.d/*.repo/etc/apt/sources.list与/etc/apt/sources.list.d/*.list元数据缓存/var/cache/dnf/默认过期时间较短/var/lib/apt/lists/需手动apt update签名校验gpgcheck1gpgkeysigned-by指向 keyring 文件查询已装包rpm -q nginx、dnf list installed nginxdpkg -l nginx、apt list --installed文件归属查询rpm -ql nginxdpkg -L nginx仓库优先级priority插件 /--enablerepo/etc/apt/preferences.d/里的 Pin两套体系最本质的区别是元数据的刷新时机。yum/dnf 每次执行命令前会检查缓存是否过期过期就自动拉取apt 不是apt install用的是上次apt update时的索引如果源地址改过但没更新会直接报Unable to locate package。这是从 CentOS 转 Ubuntu 的人最常踩的第一坑。2.2 版本来源的三层结构不管哪套系统Nginx 的包都可能有三个来源装之前必须知道自己拿到的是哪一层。第一层系统基础仓库。CentOS 7 的基础仓库里没有 nginx得开 EPELCentOS 8 及之后的 Stream 版本nginx 在 AppStream 仓库里开箱即用。Ubuntu 的universe组件里有 nginx但默认镜像的精简安装可能没启用 universe需要先add-apt-repository universe或确认 sources 里有这一项。第二层第三方扩展仓库。CentOS 7 时代 EPEL 是标配yum install epel-release之后才有 nginx。EPEL 里的版本通常是够用但不新好处是经过大量验证。第三层软件官方仓库。提供 stable 和 mainline 两条线。stable 是偶数版本号1.24.x、1.26.x只修 bug 不加功能mainline 是奇数版本号1.25.x、1.27.x新功能先进这里。生产环境我一般选 stable除非需要某个只有 mainline 才有的模块。注意同一台机器上不要混用多层来源。系统仓库装过 nginx再加官方仓库装一次会出现两个包都认为自己是nginx的尴尬局面dnf 会报冲突或者更糟——静默替换掉二进制但配置文件路径没变。2.3 网络不通时的仓库排查顺序国内环境拉取海外源经常超时报错形式五花八门按这个顺序查基本都能定位。# 第一步DNS 能不能解析 getent hosts nginx.org # 或 dig short nginx.org # 第二步HTTP 层能不能通注意有些源只开 https curl -I --connect-timeout 5 https://nginx.org/packages/ # 第三步仓库配置里的 baseurl 是否拼错 dnf repolist -v 2/dev/null | head -40 grep -r baseurl\|deb /etc/yum.repos.d/ /etc/apt/sources.list.d/ 2/dev/null # 第四步清缓存重来 dnf clean all dnf makecache apt clean apt update如果确认是网络慢可以把源地址换成国内公共镜像站提供的同路径镜像。判断标准很简单镜像站上必须能访问到与原站完全一致的目录结构和签名 key否则不要换——只改 baseurl 不换 keygpgcheck一定失败。3. CentOS 系yum/dnf 安装的完整流程分三种情况写对照自己的系统版本选一条走。3.1 CentOS 7EPEL 是绕不开的前置CentOS 7 基础仓库确实没有 nginx必须开 EPEL。标准动作是两步# 安装 EPEL 仓库配置包 yum install -y epel-release # 装 nginx yum install -y nginx-y的意思是所有确认自动回答 yes批量脚本里必带手工操作时建议第一遍不加看清楚它准备装哪些包、占多少空间心里有数再确认。我第一次装的时候没看结果发现它顺带装了一堆gd、GeoIP之类的东西磁盘小的机器上值得留意。装完验证rpm -qi nginx | head -20 nginx -v systemctl enable --now nginx systemctl status nginx --no-pagersystemctl enable --now这一条同时做了开机自启和立即启动比先enable再start少敲一次。CentOS 7 上如果status显示active (running)但curl不通八成是 firewalld 拦着后面第 5 章细说。值得单独提一句 CentOS 7 的现状这个版本已经停止维护官方仓库地址迁移到了归档源。新机器上直接用yum install epel-release大概率报Could not resolve host或 404。真要在这种机器上装得先把/etc/yum.repos.d/里的 baseurl 全部改成归档地址。这是个临时方案长期看还是建议迁移系统版本别在生产上硬撑。3.2 CentOS 8 / StreamAppStream 直装CentOS 8 及之后的版本nginx 在 AppStream 仓库里不需要 EPEL一条命令dnf install -y nginx # CentOS 8 早期也可以继续用 yum它是 dnf 的软链想确认包来自哪个仓库装之前先查dnf info nginx # 输出里 Repository 一行会写 AppStream dnf repoquery --location nginxAppStream 的模块化机制有个坑某些版本里 nginx 是以 module 形式提供的多版本共存时需要用dnf module list nginx看有哪些流可用。如果你需要特定小版本可能要dnf module enable nginx:1.20先切流再装。模块化这套东西设计初衷是好的实际用起来容易糊我一般直接dnf module list nginx看清楚当前启用的是哪个流避免装出来和预期不符。dnf module list nginx # 输出里 [e] 表示已启用[d] 是默认[x] 是禁用3.3 需要新版本时加官方仓库要 1.24 以上或者要用 stable 主线就得加官方仓库。整个流程四个动作写 repo 文件、导入 key、验证、安装。# 1. 写入仓库配置stable 线 cat /etc/yum.repos.d/nginx.repo EOF [nginx-stable] namenginx stable repo baseurlhttp://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck1 enabled1 gpgkeyhttps://nginx.org/keys/nginx_signing.key module_hotfixestrue EOF # 2. 导入签名 key部分版本需要手动导入 rpm --import https://nginx.org/keys/nginx_signing.key # 3. 验证仓库可用且签名正常 dnf repolist | grep nginx dnf info nginx # 4. 安装 dnf install -y nginx几个细节值得展开。$releasever和$basearch是 yum 的内置变量分别代表系统主版本号和 CPU 架构写成变量而不是写死8或x86_64好处是同一份配置文件能跨机器复用升级系统大版本时不用改。module_hotfixestrue这个是给 CentOS 8 及以上用的。原因是模块化仓库里也有一个 nginx 的 module加了这行才能让官方仓库的包优先否则 dnf 会坚持用 AppStream 的 module 版本你加了源也没用装出来还是老版本。这个坑我踩过一次dnf info nginx明明显示官方仓库有 1.26装完nginx -v还是 1.20查了半天才发现是 module 的锅。gpgcheck1千万别图省事改成 0。签名校验是软件包完整性的最后一道防线关掉它等于允许任何人往仓库里塞一个改过的包。真遇到 key 过期之类的报错正确做法是更新 key 或者联系镜像站不是关校验。要 mainline 线把上面文件里的[nginx-stable]改成[nginx-mainline]baseurl 里的路径一样只是包的内容不同。两条线可以配在同一个 repo 文件里靠enabled控制启用哪条但同时启用会冲突只能留一个。3.4 装完发现缺 module三种补救方式在线安装的包是按官方默认参数编译的绝大多数模块都带但少数需要额外装包。比如你要做 HTTPS 的证书动态加载或者地理信息判断可能需要# 查当前编译带了哪些模块 nginx -V 21 | tr \n | grep with- # 常见的补充包视版本而定 dnf install -y nginx-mod-stream dnf install -y nginx-mod-http-perl如果需要的模块在仓库里压根没有只剩两条路换官方 mainline 仓库看看有没有或者源码编译。这就是第 1 章说的取舍点——只有在模块层面无解的时候才值得付出源码编译的代价。4. Ubuntu / Debian 系apt 安装的完整流程apt 这边整体更顺但仓库和版本控制的细节比 yum 多。4.1 universe 源与默认版本Ubuntu 的标准安装默认启用了main和universenginx 就在 universe 里直接装apt update apt install -y nginxapt update不能省。这不是习惯问题apt 的包索引是本地文件源列表变了、镜像站换了、甚至隔了几天没用索引都可能和实际不同步不 update 直接 install轻则装到旧版本重则Unable to locate package nginx。装完看版本dpkg -l | grep -w nginx nginx -v apt-cache policy nginxapt-cache policy这条命令输出信息量最大会列出已装版本、候选版本以及每个候选来自哪个源。判断我装的到底是不是官方仓库的包看这里最准nginx: Installed: 1.18.0-6ubuntu14.4 Candidate: 1.18.0-6ubuntu14.4 Version table: *** 1.18.0-6ubuntu14.4 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 100 /var/lib/dpkg/status500那个数字是优先级来自哪个源一眼看穿。4.2 加官方仓库拿新版本Ubuntu 上加官方源比 CentOS 多几步核心是 keyring 的处理。现代 apt 要求用signed-by显式指定 key 文件不再往全局 keyring 里塞。# 1. 准备工具精简系统可能缺 gnupg apt install -y curl gnupg2 ca-certificates lsb-release # 2. 下载签名 key 并转成二进制 keyring 格式 curl -fsSL https://nginx.org/keys/nginx_signing.key \ | gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg # 3. 写入源配置注意用 signed-by 指向上面的文件 echo deb [signed-by/usr/share/keyrings/nginx-archive-keyring.gpg] \ http://nginx.org/packages/ubuntu $(lsb_release -cs) nginx \ /etc/apt/sources.list.d/nginx.list # 4. 更新并安装 apt update apt install -y nginxgpg --dearmor这一步是关键。下载下来的 key 是 ASCII armor 格式-----BEGIN PGP PUBLIC KEY BLOCK-----开头apt 需要的是二进制格式。忘了这一步apt update会报NO_PUBKEY或者 key 格式无效。我自己习惯把 key 放在/usr/share/keyrings/这是约定的系统级位置比放/etc/apt/keyrings/兼容性更好老版本 apt 也认。$(lsb_release -cs)返回的是发行版代号22.04 是jammy24.04 是noble20.04 是focal。用命令替换而不是写死代号脚本换个系统也能跑。但要注意官方仓库不一定支持所有代号比如刚发布的新版本官方源可能还没跟上这时apt update会报 404先去仓库目录看一眼有没有对应的子目录别硬写。4.3 版本锁定防止一次 upgrade 打回原形这是 apt 一个非常实际的问题。你千辛万苦加了官方源装上了 1.26某天例行apt upgrade系统仓库里更新了一个1.18.0-6ubuntu14.5的安全补丁apt 一比较觉得版本号变了该升于是把 1.26 降回了 1.18。业务配置里用着 1.25 的语法重启直接报错。解决办法是 apt pinning告诉 apt这个包只从指定源来。cat /etc/apt/preferences.d/99nginx EOF Package: * Pin: origin nginx.org Pin-Priority: 900 EOFPin-Priority的规则是数字越大优先级越高系统默认源一般是 500。设成 900官方源就永远压过系统源。如果只想锁版本不换源apt-mark hold nginx nginx-common nginx-core apt-mark showhold # 解锁用 apt-mark unhold nginxhold更粗暴连官方源的更新也不装适合这个版本很稳别动它的场景。两种方式可以叠加用。CentOS 那边对应的工具是dnf versionlock插件dnf install -y dnf-command(versionlock) dnf versionlock add nginx dnf versionlock list4.4 目录结构差异从 CentOS 转过来最容易晕的地方Ubuntu 系的文件布局和 CentOS 不一样配置写错位置是高频事故。项目CentOS 系Ubuntu 系主配置/etc/nginx/nginx.conf/etc/nginx/nginx.conf站点配置目录/etc/nginx/conf.d/*.conf/etc/nginx/sites-available/sites-enabled/软链默认站点根目录/usr/share/nginx/html/var/www/html运行用户nginxwww-data默认日志/var/log/nginx/access.log/var/log/nginx/access.log同名二进制路径/usr/sbin/nginx/usr/sbin/nginx关键在站点配置。CentOS 的nginx.conf里有一行include /etc/nginx/conf.d/*.conf;所以你往conf.d/丢.conf文件就生效。Ubuntu 的nginx.conf里是include /etc/nginx/sites-enabled/*;而sites-enabled/里放的是指向sites-available/的软链接。有人从 CentOS 拷了一份conf.d/xxx.conf到 Ubuntu发现不生效因为 Ubuntu 默认不 includeconf.d。要么在nginx.conf的http{}块里补一行include /etc/nginx/conf.d/*.conf;要么老实按 Ubuntu 的规矩放sites-available再ln -s。这两种做法都行但一个环境下最好统一别一半一半后面排查起来找文件都找不到。提示改完配置务必先nginx -t再systemctl reload nginx。-t只检查语法不加载reload才是平滑生效。顺序反了配置有错的情况下 reload 会失败但老进程还在跑你可能以为已经生效了。5. 装完不是结束验证、放行与最小可用配置systemctl status显示 running不代表外网能访问。这一段是做完整安装的收尾也是新手最常断链的地方。5.1 五步验证法按这个顺序查每一步失败都能精确定位到层次。# 第一步二进制在不在版本对不对 nginx -v nginx -V 21 | head -3 # 第二步配置语法有没有问题 nginx -t # 第三步进程在不在谁在监听 systemctl is-active nginx ss -lntp | grep :80 # 第四步本机能不能通绕过防火墙 curl -I http://127.0.0.1 # 第五步本机 IP 能不能通验证监听地址 curl -I http://$(hostname -I | awk {print $1})第三步如果ss输出里监听的是127.0.0.1:80而不是0.0.0.0:80说明配置里listen写成了本地回环外部当然访问不了。第四步通、第五步不通问题在防火墙或者listen地址第四步就不通问题在 Nginx 本身或者配置。nginx -V的输出值得留意里面包含编译参数和--with-开头的模块列表。判断某个功能能不能用看这个比查文档快。5.2 防火墙与 SELinux 放行CentOS 系默认开 firewalldfirewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --reload firewall-cmd --list-servicesUbuntu 系默认是 ufw但很多云镜像没启用先看状态ufw status verbose # 如果是 inactive说明防火墙没开可以跳过 # 如果 active放行 ufw allow 80/tcp ufw allow 443/tcp ufw reloadCentOS 上还有 SELinux 这个隐形杀手。默认策略下Nginx 只能读/usr/share/nginx/html和/var/www这类标记为httpd_sys_content_t的目录。你把站点根目录改成/data/www浏览器直接 403error.log里一行Permission denied: [client ...] AH00035/nginx: access forbidden by rule或者/var/log/nginx/error.log里什么都没有只有403 Forbidden。这时候查 SELinuxgetenforce # Enforcing 就说明是它 # 让新目录获得正确的安全上下文 semanage fcontext -a -t httpd_sys_content_t /data/www(/.*)? restorecon -Rv /data/www # 如果 Nginx 要反向代理到后端需要主动发起连接 setsebool -P httpd_can_network_connect 1 # 临时验证是不是 SELinux 的锅不建议长期关 setenforce 0semanage命令来自policycoreutils-python-utils包精简系统可能没装先dnf install -y policycoreutils-python-utils。restorecon是让之前的 fcontext 规则生效两个命令要配对用只跑第一个不跑第二个权限不会变。注意setenforce 0只是把当前状态切到宽容模式重启后恢复。它适合用来确认问题根源不适合当解决方案。生产上关 SELinux 是在给自己埋雷正确的做法是打标签。5.3 一份可以直接抄的最小可用配置装完之后系统会带一个默认站点指向默认目录。想换成自己的按下面这套来CentOS 和 Ubuntu 都能用区别只在运行用户。# 1. 建目录和测试页 mkdir -p /var/www/demo cat /var/www/demo/index.html EOF !DOCTYPE html htmlheadmeta charsetutf-8titledemo/title/head bodyh1nginx is running/h1/body/html EOF # 2. 权限CentOS 用 nginx 用户Ubuntu 用 www-data chown -R nginx:nginx /var/www/demo # Ubuntu 改成 www-data:www-data chmod 755 /var/www/demo chmod 644 /var/www/demo/index.html配置文件放的位置按发行版来CentOS 写/etc/nginx/conf.d/demo.confUbuntu 写/etc/nginx/sites-available/demo然后ln -s到sites-enabled/。server { listen 80; server_name _; root /var/www/demo; index index.html; access_log /var/log/nginx/demo.access.log; error_log /var/log/nginx/demo.error.log warn; location / { try_files $uri $uri/ 404; } location /healthz { access_log off; return 200 ok\n; add_header Content-Type text/plain; } }几个参数的必要性说清楚。server_name _是通配写法匹配所有未命中的 Host做单站点或者测试环境足够正式环境应该换成真实域名。try_files $uri $uri/ 404是静态站点的标准写法先找文件再找目录都没有就 404比直接root少很多奇怪行为。location /healthz是给负载均衡或者监控探活用的access_log off避免探活请求把日志刷满——这个细节很多人不做结果健康检查每 5 秒一次一天写几万行日志。生效流程固定三步nginx -t systemctl reload nginx curl -I http://127.0.0.1/healthz5.4 worker 参数怎么估别抄网上的数字默认配置文件里的worker_connections 1024是老值很多人直接照抄机器配置高也用不上。这里给一个能算的说法。worker_processes auto; events { worker_connections 4096; }worker_processes auto让 Nginx 按 CPU 核数自动设4 核就是 4 个 worker这是推荐值不用手写。worker_connections是单个 worker 能同时处理的最大连接数理论最大并发是两者相乘4 核 × 4096 16384 个连接如果做反向代理一个客户端请求会占用两条连接客户端侧 后端侧实际能承载的客户端约 16384 / 2 8192但有个硬约束在操作系统层面每个连接占一个文件描述符worker 进程的 fd 上限必须大于worker_connections。查当前限制ulimit -n # 当前 shell 的限制 cat /proc/$(pgrep -o nginx)/limits | grep open files如果显示 1024那worker_connections 4096毫无意义跑到 1023 个就Too many open files了。调高需要同时改systemd单元mkdir -p /etc/systemd/system/nginx.service.d cat /etc/systemd/system/nginx.service.d/limits.conf EOF [Service] LimitNOFILE65535 EOF systemctl daemon-reload systemctl restart nginx经验值是LimitNOFILE设成worker_connections的 2 到 4 倍留足余量给日志文件、临时文件、上游连接。别设成无穷大系统级 fd 是共享资源一个进程吃光会影响整机。6. 踩坑实录在线安装最常遇到的 10 个问题这一节按问题类型整理配上排查命令和原因说明可以当速查表用。6.1 仓库与安装类问题报错/现象大概率原因排查与解决Unable to locate package nginxapt索引没更新或 universe 未启用apt updategrep universe /etc/apt/sources.listNo package nginx availableyum仓库里确实没有CentOS 7 缺 EPELyum install epel-release后重试Could not resolve hostDNS 问题或网络不通getent hosts nginx.org检查/etc/resolv.confNO_PUBKEY xxxxxxxx签名 key 没导入按 4.2 的方式重新下载并 dearmorGPG key retrieval failedkey 地址不可达或系统时间错误date看时间是否偏差过大校正后重试Error: Transaction check error ... conflicts系统包与官方仓库包冲突先卸载系统包dnf remove nginx再加官方源重装装完版本还是旧的官方源被 module 或 pin 压制CentOS 加module_hotfixestrueUbuntu 检查apt-cache policy时间偏差那条特别隐蔽。系统时钟如果落后或者超前几年TLS 握手和 GPG 验签都会失败但报错信息完全看不出是时间问题。我遇到过一次容器环境宿主机时间正常容器里时间差了三个月apt update一直报验签失败查了半小时才想到date。校正用timedatectl set-ntp true。6.2 服务启动类问题现象一Job for nginx.service failed because the control process exited with error code。这个报错本身没信息必须看详细日志systemctl status nginx -l --no-pager journalctl -u nginx -n 50 --no-pager nginx -t九成是配置语法错误nginx -t会直接指出来哪一行。现象二bind() to 0.0.0.0:80 failed (98: Address already in use)。端口被占找出是谁ss -lntp | grep :80 fuser -n tcp 80常见占用者包括预装的 Apache、某些面板自带的服务、上一次没杀干净的 Nginx 进程。确认后停掉对方或者改 Nginx 的监听端口。现象三启动成功但访问 403。按这个顺序查目录权限其他人有没有读和执行权限、SELinuxgetenforce、index文件是否存在、nginx.conf里的user指令和目录属主是否匹配。Ubuntu 上特别容易犯的错是把目录 chown 给了nginx用户但 Ubuntu 的 Nginx 跑在www-data下读不了。现象四改了配置但行为没变。检查是不是改了sites-available里的文件却没建软链或者同一个location在别的配置文件里被覆盖了。查完整生效配置nginx -T | grep -n listen\|server_name\|root-T会把所有 include 的文件合并输出比一个个翻文件快得多。6.3 我自己的三条避坑心得第一条新机器先跑一遍体检再动手。第 1.3 节那三条命令我现在写在批量脚本的最前面尤其是端口占用检查。曾经有一次在客户现场装完发现 80 被占排查占用进程花的时间比装 Nginx 多十倍。第二条仓库优先级一定要显式配置不要依赖默认行为。Ubuntu 上加了官方源却不配 pin迟早被apt upgrade打回原形CentOS 8 上不加module_hotfixes官方源等于白加。这两个都是不报错但结果不对的类型最难发现。第三条升级前先备份/etc/nginx整个目录。包管理器升级大概率会问你配置文件怎么处理选保留旧的还是用新的一旦选错自定义的location就没了。tar czf /root/nginx-conf-$(date %F).tar.gz /etc/nginx就一条命令三十秒的事能救回来一整天的配置重建。我现在的习惯是每次改配置前先打一个包攒几天再清理比记在脑子里靠谱。另外提一个容易被忽略的点systemctl reload nginx和restart的区别。reload是平滑重载老 worker 处理完手头请求再退出连接不断restart是直接停再起有几百毫秒的中断。生产环境改配置只要没动监听端口、没换二进制一律用reload。但如果换了worker_processes或者改了user指令reload可能不生效必须restart。最后说个我自己的习惯每台机器装完 Nginx我会在/root/下留一个nginx-install-note.md写清楚装的是什么版本、来自哪个仓库、加了哪些非默认配置、站点根目录在哪。这东西看着多余但半年后你或者别人登上来看一眼就全明白了比翻 history 强太多。装软件这件事本身不复杂复杂的是三个月后还能不能记得当时为什么这么装。