Nginx 启动、重启、基本命令这三件事看起来像是入门第一课但真正在生产环境里跑过几年的人都知道出事故最多的往往就是这几个命令用错了地方。我见过有人直接在线上敲nginx -s stop把几百个长连接全掐断也见过reload敲了七八遍配置就是不生效最后发现改的文件压根没被 include 进去。这篇内容就把 Nginx 的启动、重启和常用命令从头到尾捋一遍重点不是把参数表抄给你而是讲清楚每条命令背后 Nginx 到底干了什么、什么时候该用哪一条、哪些坑绕不开。不管你是刚在测试机上装完 Nginx 的新手还是维护着几十台机器的运维这里面的东西应该都能用得上。1. 先搞懂进程模型命令才不会用错1.1 master 和 worker 到底谁在干活Nginx 启动之后你ps -ef | grep nginx看到的通常不是一个进程而是一组一个 master 进程加上若干个 worker 进程。这个设计是整个命令体系的地基不理解它后面所有关于重启的判断都会失准。master 进程的角色是管理者它自己几乎不处理任何 HTTP 请求主要干三件事读取并解析配置文件、管理 worker 进程的生命周期、监听配置里声明的端口并向 worker 分发新连接。worker 进程才是真正干活的它负责接收连接、解析请求、读取静态文件或者转发给后端、把响应写回去。默认配置下 worker 的数量由worker_processes决定写成auto时 Nginx 会自己探测 CPU 核心数有几个核就起几个 worker。为什么这么设计因为每个 worker 都是独立的单线程事件循环彼此之间不共享连接状态一个 worker 崩了不会带着其他 worker 一起死master 会重新拉一个新的起来。同时 worker 之间没有锁竞争CPU 利用率能做到接近线性扩展。这也是为什么 Nginx 能扛住高并发而一些传统的多进程模型在连接数上去之后就开始互相抢资源。理解这一点的实际意义在于所谓重启 NginxNginx 提供的从来不是杀掉全部再拉起来这种粗暴操作而是让 master 重新读配置、逐步换掉 worker。这是它比很多服务优秀的地方也是你必须区分reload和restart的原因。1.2 信号驱动Nginx 的重启本质是什么Nginx 的启动、停止、重载归根结底都是给 master 进程发信号。命令行里的-s参数只是个便利封装它会去读 pid 文件找到 master 进程号然后调用系统调用发对应的信号。换句话说你完全可以用kill达到同样的效果理解了信号就等于理解了全部命令。信号命令行等价写法行为TERM / INTnginx -s stop立即停止不等待请求处理完QUITnginx -s quit优雅停止等当前请求处理完再退出HUPnginx -s reload重新读取配置平滑替换 workerUSR1nginx -s reopen重新打开日志文件用于日志切割USR2无直接命令平滑升级二进制文件WINCH无直接命令优雅关闭 worker平滑升级时使用这张表建议背下来。线上真正高频的只有三个reload、quit、reopen。stop在测试环境随便用生产环境要慎之又慎因为它对应的是 TERMmaster 收到后会立刻给所有 worker 发终止指令正在传输的响应会直接断掉客户端看到的就是连接重置。用户那边可能正在提交一个订单页面直接白了。reload的完整流程值得单独说一下master 收到 HUP 后先做一次配置语法解析如果解析失败它不会动现有的 worker配置不生效但服务照常运行——这是个非常贴心的设计。解析通过后master 用新配置启动一批新 worker然后给旧 worker 发 QUIT 信号。旧 worker 进入关闭中状态不再接受新连接但会把手头已经建立的连接处理完处理完了自己退出。整个过程用户侧几乎无感知。1.3 为什么平滑这两个字值钱对比一下就明白了。假设你改了proxy_read_timeout想让一个慢接口少报几次超时如果用 restart 的方式会有一个几百毫秒到几秒的窗口这个窗口内所有新连接都被拒绝客户端拿到的是 connection refused。如果你的服务每秒有几万请求这个窗口就是几千个失败请求监控上直接一条尖刺。用 reload 就没有这个窗口。新 worker 起来之后立刻可以接受连接旧 worker 在后台默默收尾两者并存一小段时间。代价是内存会短暂翻倍——新旧两批 worker 同时存在每个 worker 的内存占用乘以 2。如果你的机器内存本来就很紧张reload 的时候要注意观察一下别在内存已经 90% 的时候去做重载。提示reload 是平滑的但不等于零成本。worker 数量多、内存占用大的实例reload 会有一段时间内存和 CPU 的双重波动建议放在业务低峰期做。2. 安装方式决定命令路径这一步别走错2.1 三种安装方式的实际取舍Nginx 在 Linux 上的获取方式大致三种发行版包管理器直接装yum install nginx、apt install nginx、官方预编译包、源码编译。这三种方式装出来的 Nginx 功能上没差但目录结构、命令路径、配置文件位置完全不同很多命令找不到的问题根子就在这里。包管理器安装的好处是省事一条命令搞定还会自动帮你写好 systemd 服务单元和日志轮转配置systemctl start nginx直接就能用。缺点是版本偏旧发行版仓库里的版本可能落后官方好几个大版本一些新特性比如 HTTP/3 支持、新的 stream 模块能力可能用不上。对于内网管理系统、测试环境这类场景包管理器装完全够。源码编译适合两类人需要特定模块的比如要加--with-http_v2_module、--with-stream、或者第三方模块如 lua、nginx-module-vts以及需要在同一台机器上跑多个不同版本 Nginx 做灰度对比的。缺点是升级麻烦得重新编译再平滑替换二进制。官方预编译包介于两者之间版本新但你也得自己配 systemd 单元。我的建议是除非你有明确的模块需求或者版本需求否则优先用包管理器。它的目录约定是事实标准出了问题网上一搜一大把团队里其他人接手也不用重新学一套路径。2.2 源码编译的完整参数和依赖真要走编译这条路先把依赖装上。CentOS / 麒麟这类 RPM 系yum install -y gcc gcc-c make pcre pcre-devel zlib zlib-devel openssl openssl-develDebian / Ubuntu 系换成apt install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev即可。这里有个细节pcre-devel提供正则支持zlib-devel提供 gzip 压缩支持openssl-devel提供 HTTPS 支持。这三个依赖缺哪个编译时不会报错但对应的功能会被静默跳过等你要配 HTTPS 的时候才会发现unknown directive ssl。所以依赖装完./configure的执行结果一定要完整看一遍。配置命令./configure \ --prefix/usr/local/nginx \ --userwww --groupwww \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream \ --with-pcre各个参数的作用值得说清楚--prefix决定了整个安装根目录后面所有路径都以它为基准sbin、conf、logs都在它下面--user和--group指定 worker 进程运行身份编译期指定比运行期用user指令更彻底避免权限配置被遗漏--with-http_realip_module用来从X-Forwarded-For里还原真实客户端 IP前面挂了负载均衡就必须加--with-http_stub_status_module提供一个状态页能看当前连接数、活跃连接、请求数排查问题非常方便--with-stream开启四层代理做数据库、Redis 的 TCP 转发时会用到。跑完./configure后接make make install几分钟就好了。装完验证/usr/local/nginx/sbin/nginx -V这条命令输出的configure arguments必须和你刚才写的一模一样如果少了某个--with-xxx说明那个模块没编进去去翻 configure 的输出找原因。2.3 两种安装方式下命令和目录的差异这是最容易把人绕晕的地方我直接列个对照表项目包管理器安装源码编译prefix/usr/local/nginx可执行文件/usr/sbin/nginx/usr/local/nginx/sbin/nginx主配置/etc/nginx/nginx.conf/usr/local/nginx/conf/nginx.conf子配置目录/etc/nginx/conf.d/需自己创建并 includepid 文件/run/nginx.pid/usr/local/nginx/logs/nginx.pid错误日志/var/log/nginx/error.log/usr/local/nginx/logs/error.log服务管理systemctl xxx nginx需自己写 unit 文件源码编译时如果你直接敲nginx提示 command not found就是因为/usr/local/nginx/sbin不在 PATH 里。临时解决用绝对路径永久解决建个软链接ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx或者写进/etc/profile.d/nginx.sh里加到 PATH。软链接的方式更常见但要注意以后升级 Nginx 时软链接指向别搞错。2.4 交给 systemd 管理顺带解决开机自启源码装的 Nginx 默认不会开机自启而且systemctl也管不了它。写一个 unit 文件就能解决放在/etc/systemd/system/nginx.service[Unit] Descriptionnginx web server Afternetwork.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf ExecStart/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target几个关键点必须注意。Typeforking是因为 Nginx 默认以守护进程方式运行master 起来之后会 fork 然后父进程退出systemd 必须知道这个行为才不会误判服务启动失败配套的PIDFile必须和配置里的pid指令指向同一个文件否则 stop 的时候 systemd 找不到进程。ExecStartPre先跑一次配置检查是个好习惯配置写错了服务直接起不来而不是起来之后才发现行为异常问题暴露得更早。写完文件别忘了systemctl daemon-reload不然 systemd 不认这个新单元。然后systemctl enable nginx # 设置开机自启 systemctl start nginx # 启动 systemctl status nginx # 查看状态enable实质上是在/etc/systemd/system/multi-user.target.wants/下建了一个指向服务文件的软链接systemd 启动到这个 target 时就会带起 Nginx。如果哪天你发现重启机器后 Nginx 没起来第一件事就是systemctl is-enabled nginx看看这个链接还在不在——有些自动化脚本或者人为操作会把它删掉。3. 启动、停止、重启命令逐个拆解3.1 nginx 可执行文件自带的参数清单nginx -h能列出全部参数但真正常用的就那么几个我按使用频率排一下参数用途典型场景-t测试配置文件语法每次改完配置必跑-T测试并打印最终配置排查 include 和变量展开-s发送信号stop/quit/reload/reopen手工管理服务-v显示版本号确认版本-V显示版本号和编译参数排查模块是否编入-c指定配置文件路径多实例、多配置文件-p指定运行前缀目录多实例隔离-g直接指定全局指令临时覆盖配置调试用-T这个参数我想多说两句它是排查配置明明改了却不生效的利器。Nginx 的配置是层层 include 的nginx.conf里 include 了conf.d/*.confconf.d里的文件又可能 include 别的东西你改的文件到底进没进最终配置、有没有被后面的同名 server 覆盖光看单个文件是看不出来的。nginx -T会把所有 include 展开之后的完整配置打印出来搜索你要改的那一行能找到说明生效范围没问题找不到就是 include 链路断了。-g用得少但很有用。比如你想临时以非守护模式启动看一眼日志可以nginx -g daemon off;进程会挂在前台所有输出直接打到终端。做容器化的时候这个是标配Docker 里 Nginx 必须以daemon off跑否则容器主进程一退出容器就结束了。3.2 -s 命令和 systemctl 的对照关系两种管理方式不要混着用这是很多混乱的源头。你用systemctl start nginx起的服务再用nginx -s stop停掉systemd 那边还认为服务在运行状态就错乱了。操作命令式systemd 式启动nginxsystemctl start nginx快速停止nginx -s stopsystemctl stop nginx优雅停止nginx -s quitsystemctl stop nginx取决于 ExecStop 配置重载配置nginx -s reloadsystemctl reload nginx完全重启无systemctl restart nginx查看状态ps -ef | grep nginxsystemctl status nginx开机自启需额外配置systemctl enable nginx这里有个细节systemctl stop nginx到底走快速还是优雅取决于 unit 文件里ExecStop写的是-s stop还是-s quit。默认包管理器的 unit 文件用的是-s quit也就是优雅停止。所以如果你在脚本里依赖stop 之后进程必须马上消失用 systemd 这套可能会等一会儿。systemctl restart nginx才是真正的停掉再起来中间必然有一个短暂的服务不可用窗口。生产环境改配置一定要用reload而不是restart。我个人习惯是只要改动支持热加载绝大多数指令都支持一律 reload只有改动了 listen 端口、user 身份这类启动期就固定的东西才考虑 restart而且必须安排在维护窗口。3.3 什么时候必须用 stop什么时候必须用 quit判断逻辑很简单问自己一句现在还有没有正在处理的请求。测试机、内网工具、纯静态站点并且没人访问stop随便用快。生产环境、有长连接、有上传下载、有 WebSocket一律quit。WebSocket 场景尤其要注意连接可能挂几个小时stop一下所有长连接立刻掉线客户端得走重连逻辑用户体验很差。还有一种情况容易被忽略如果你在用stream模块做四层代理转发的是数据库连接或者消息队列连接那更不能用 stop那些连接一旦断掉可能是事务回滚级别的故障。quit有个特性要记住它是优雅但不是无限等待。如果某个 worker 上有个连接永远不结束比如客户端开了连接不读数据这个 worker 会一直不退出master 也会一直等。遇到quit之后进程半天不消失别慌先看看是不是有异常长连接实在不行再补一个stop收尾。3.4 reopen 和日志切割的配合nginx -s reopen对应 USR1 信号作用是让 Nginx 重新打开日志文件。这个命令平时不用但日志切割时必须用它。原因是 Linux 的文件句柄机制Nginx 启动时打开了/var/log/nginx/access.log这个文件被一个文件描述符指着。你直接mv access.log access.log.20240101文件虽然在目录里改名了但 Nginx 手里的描述符还指着同一个 inode后续日志还是往那个已经被改名的文件里写。必须发个 USR1让 Nginx 关掉旧描述符、按配置里的路径重新打开一个新的 access.log写入才切到新文件。正确顺序是先改名再发信号顺序反了就白切mv /var/log/nginx/access.log /var/log/nginx/access.log.$(date %F) kill -USR1 $(cat /run/nginx.pid)注意这里用的是kill -USR1而不是nginx -s reopen效果一样但在脚本里用 kill 更直接也避免 PATH 问题。如果要长期维护直接用系统的logrotate更省心配置里写postrotate调一下 reopen 就行。3.5 Windows 上的启动和停止虽然生产环境几乎清一色 Linux但 Windows 版 Nginx 在本地开发、内网演示环境里还是有人用热词里也常出现相关问题这里简单带一下。Windows 版没有信号机制-s参数是模拟实现的。启动用start nginx必须用 start直接双击 exe 会弹个黑框关掉黑框进程就没了停止用nginx.exe -s stop或nginx.exe -s quit重载用nginx.exe -s reload。查看进程tasklist /fi imagename eq nginx.exe实在停不掉的时候用taskkill /f /im nginx.exe强杀但这等于 TERM会断连接。Windows 版最容易踩的坑是工作目录。它读配置、写日志、存 pid 都是以当前工作目录为基准的不是以 exe 所在目录。所以你必须先cd到 Nginx 目录再执行命令否则会出现配置改了没生效或者日志写到别处去了的情况。另外 Windows 版不支持--with-stream之类的一些模块能力比 Linux 版弱别指望它在 Windows 上做复杂的四层代理。4. 改完配置怎么验证才算真的改对了4.1 配置的分层结构和最小示例Nginx 配置是树状结构从上到下是 main、events、http、server、location 五层。理解层级关系很重要因为很多指令只能出现在特定层级里写错地方会直接报not allowed here。worker_processes auto; error_log /var/log/nginx/error.log warn; pid /run/nginx.pid; events { worker_connections 10240; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; server { listen 80; server_name example.com; root /data/www/example; index index.html; location /static/ { expires 7d; } } }worker_connections是最需要动手算的参数。单个 worker 能处理的最大连接数由它决定理论上进程总连接上限是worker_processes × worker_connections。但注意一点做反向代理时Nginx 既是客户端连接的服务端又是后端服务的客户端一个用户请求会占用两个连接前后各一个。所以纯静态站点可以按worker_processes × worker_connections估算反向代理场景要打个对折。别只看公式实际还要受worker_rlimit_nofile和系统ulimit -n限制后者不够的话连接数怎么调都上不去。4.2 nginx -t 到底检查什么什么它查不出来nginx -t是最常用的命令但很多人过度信任它。它做的事情很有限把配置文件按 include 展开逐个指令检查语法是否正确、指令是否出现在允许的层级、引用的文件比如证书路径是否存在。通过时输出syntax is ok和test is successful两行。它查不出来的东西至少有这些upstream 里配的后端 IP 是否可达、proxy_pass 指向的服务是否真的在监听、证书内容和域名是否匹配、root 目录的权限 worker 用户能不能读、限流规则会不会把正常用户误伤。这些都得靠实际请求验证。另外nginx -t有个容易忽略的点它默认读的是编译时指定的配置文件路径。如果你用-c指定了别的路径启动测试的时候也必须带上同样的-c不然测的是另一个文件白测。同理用-p指定 prefix 启动的测试时也要给-p。4.3 reload 之后怎么确认真的生效nginx -s reload敲下去没报错不代表配置生效了。完整的验证闭环应该是这样第一步nginx -t通过。第二步reload 之后立刻看一眼错误日志的最后几行tail -20 /var/log/nginx/error.log有emerg级别说明没起来有warn需要注意但通常不影响。第三步ps -ef | grep nginx看进程——reload 成功的瞬间你会短暂看到新旧两批 worker几秒后旧 worker 消失只剩新的一批worker 数量应该和worker_processes对得上。第四步用真实请求打一下改了什么就验证什么改了超时就用慢接口试改了限流就压一下改了代理就发个请求看后端日志有没有收到。如果 reload 没报错但行为没变按这个顺序排查配置是否真的在 include 链路里用nginx -T找你的改动、是否 reload 的是正确的实例有多个 Nginx 时 pid 文件可能指向另一个、客户端是否有缓存CDN、浏览器、DNS 都有可能、连接是否复用了旧 worker 的长连接等连接自然断开或者重启客户端。注意reload 报错时 Nginx 会保留旧配置继续服务这是保护机制。但报错内容必须马上处理因为此时你的新配置完全没生效很容易造成改了配置以为生效了的错觉。5. 反向代理、负载均衡、多站点场景下的命令实践5.1 加一个反向代理并平滑生效反向代理是 Nginx 最主流的用法配置本身不复杂但有几个参数和路径拼接的细节决定成败location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_http_version 1.1; 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; proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_send_timeout 60s; }proxy_pass末尾那个斜杠是最经典的坑。带了斜杠/api/user转发到后端变成/user/api前缀被剥掉不带斜杠转发到后端还是/api/user前缀原样保留。后端服务如果路由是按带前缀设计的你加了斜杠就会全 404反过来也一样。这个细节一定要和后端同学对齐清楚别猜。X-Real-IP和X-Forwarded-For这两个头的作用是把真实客户端 IP 传下去后端做日志、风控、限流都依赖它。但要注意安全如果 Nginx 直接暴露在公网客户端可以伪造这个头。所以只有在你信任的前置代理才设置或者用real_ip_header配合set_real_ip_from限定可信来源再把X-Real-IP从可信来源取。改完这些配置nginx -t加nginx -s reload现有连接不断新请求走新规则。这就是平滑生效的价值。5.2 负载均衡的配置和流量摘除多后端场景用 upstreamupstream backend { least_conn; server 10.0.0.11:8080 weight3 max_fails2 fail_timeout10s; server 10.0.0.12:8080 weight1; keepalive 32; } server { listen 80; location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; } }least_conn是调度算法按当前活跃连接数最少来选后端比默认轮询更适合请求耗时差异大的场景。weight用于权重分配新老机器性能不一致时很有用。max_fails和fail_timeout是健康检查的简化实现10 秒内失败 2 次就把这台摘掉 10 秒不再分发。注意它不是主动探活是被动统计所以后端挂了之后要等失败次数累积够才会摘除。keepalive 32是 Nginx 到后端的连接池大小能显著降低 TCP 握手开销。但它必须配合proxy_http_version 1.1和清空Connection头使用否则不生效——HTTP/1.0 默认是短连接你不显式声明 1.1Nginx 还是每次新建连接。需要临时下线一台后端最干净的做法是改配置把它删掉或者加down标记然后nginx -s reload而不是去后端机器上停服务。用reload下线Nginx 会等这台机器上已有的请求处理完再摘用户完全无感。这个操作在发布、扩缩容时特别常用。5.3 一台机器跑多个 web 项目的目录组织多项目共用一个 Nginx 是常态关键是把配置拆开管理别都堆在nginx.conf里。标准做法是主配置只保留全局部分末尾加一行include /etc/nginx/conf.d/*.conf;然后每个项目一个文件# /etc/nginx/conf.d/site-a.conf server { listen 80; server_name a.example.com; root /data/www/site-a; index index.html; access_log /var/log/nginx/site-a.access.log; }这样带来的好处是改 A 项目的配置不影响 B两个人在同一个 Nginx 上干活不会互相覆盖文件禁用某个项目只需要把对应文件改名加.disabled后缀include 通配符就匹配不到了比注释掉整段配置快得多。命名上建议按业务名而不是端口号半年后你看到site-a.conf能想起来是什么看到8080.conf就懵了。多项目还容易碰到的坑是server_name冲突。两个 server 块写了同一个域名Nginx 会按文件加载顺序取第一个匹配的第二个被静默忽略。排查时用nginx -T | grep -n server_name把所有 server 列出来对比一下一眼就能看出重复。6. 常见故障与排查速查表6.1 启动失败的典型报错启动失败大部分是三类原因端口被占、配置语法错、权限不对。整理成表方便对照报错关键字原因处理方式bind() to 0.0.0.0:80 failed (98: Address already in use)80 端口被别的进程占了ss -lntp | grep :80找到进程停掉或换端口open() /run/nginx.pid failed (2: No such file or directory)pid 文件不存在常见于强杀后残留确认无残留进程后重新启动unknown directive xxx指令拼写错误或模块没编译进去用nginx -V确认模块检查拼写log_format directive is not allowed here指令写错层级把指令移到 http 块内permission denied读取证书或站点目录worker 用户没有读权限chown或chmod注意父目录也要有 x 权限端口占用是最常见的。用过ss -lntp | grep :80就能看到占用进程的 PID 和名字有可能是上次没清干净的 Nginx 残留进程也有可能是别的 web 服务。有个细节如果ss显示端口空闲但 Nginx 还是报占用检查一下是不是有多个 Nginx 实例或者有没有容器在做端口映射。权限问题里最容易忽略的是父目录的执行位。worker 用户对站点目录有读权限但如果它上层的某个目录缺少x权限一样进不去报错会和文件权限问题一模一样。排查时用sudo -u www ls /data/www/site-a模拟一下 worker 用户的视角比逐个ls -l看权限快得多。6.2 reload 不生效的排查顺序按这个顺序往下走基本能在五分钟内定位先确认配置改动在不在最终配置里nginx -T | grep 你改的关键字搜不到就是 include 链路问题。确认nginx -t是否通过不通过的话 reload 是静默保留旧配置的。确认 pid 文件指向的进程是不是你以为的那个实例cat /run/nginx.pid然后ps -p 那个PID。看错误日志尾部有没有emerg。确认客户端侧有没有缓存干扰浏览器强刷、CDN 刷新、DNS 缓存。如果改的是 upstream 且用了长连接等旧连接自然断开或者临时重启客户端。第 3 步最容易被跳过。机器上同时跑着包管理器装的 Nginx 和源码编译的 Nginx 时两个 pid 文件、两条 PATH很容易 reload 错对象。这种环境建议尽早清理掉一个留着就是隐患。6.3 开机自启失效的几种情况重启服务器之后 Nginx 没起来按这个顺序查systemctl is-enabled nginx看自启有没有被关掉返回disabled就补一个enable。systemctl status nginx看上次启动失败的原因如果是配置文件问题可能是有人手动改过配置但没验证。如果用的是源码编译加自定义 unit检查 unit 文件里的绝对路径有没有写错尤其是ExecStartPre里-c指定的配置文件路径。如果用/etc/rc.local方式自启注意现在很多系统默认rc.local没有执行权限需要chmod x /etc/rc.local。依赖网络的话unit 文件里的Afternetwork.target可能不够某些场景需要Afternetwork-online.target并加Wantsnetwork-online.target。我碰到过一次比较隐蔽的机器上有自动化脚本在每次启动时重置/etc/systemd/system/下的部分软链接导致enable创建的链接被清掉。这种环境问题只能靠开机后自动巡检脚本发现靠人肉记忆不现实。6.4 几个不太好复现的坑worker_connections设太小导致间歇性连接失败。现象是高峰期偶尔出现连接被拒绝但日志里没有明显错误只是连接数上不去。判断方法是用 stub_status 模块看active connections是否长期贴着上限。计算上限时别忘了反向代理是双连接。改完worker_processes后旧 worker 不退出。理论上 reload 之后旧 worker 会陆续退出但如果某些 worker 上有 WebSocket 长连接挂着它们会一直等。这时候进程数看起来会超过预期的两倍别急着强杀先看连接情况。日志文件权限变更导致 reload 后写不进日志。有人手动chmod 600了日志文件worker 用户写不进去reload 之后所有访问日志静默丢失站点却是正常的非常隐蔽。定期检查日志文件权限和属主。提示排查 Nginx 问题error.log的 debug 级别日志是终极武器。临时在配置里写error_log /var/log/nginx/error.log debug;然后 reload能看到每一步的详细决策过程。但 debug 日志量极大排查完记得改回warn不然磁盘很快撑满。7. 几个我一直在坚持的操作习惯说说日常运维里我自己固化下来的几条规矩都是踩坑换来的。改配置前先备份用带日期的副本cp nginx.conf nginx.conf.$(date %F_%H%M)。听起来很笨但真出事的时候比 git 快直接覆盖回去再 reload 就行。配合 git 管理更好不过内网机器上不一定有 git server本地副本是最低成本的保险。任何改动走nginx -t加reload两步绝不直接 restart。这个习惯坚持几年下来因为改配置导致的线上中断基本为零。同时把-t和reload写进发布脚本里用工具约束人比靠自觉靠谱。keepalive 和超时参数按实际业务调不抄网上的模板。proxy_read_timeout默认 60 秒如果你的后端有个批量导出接口要跑三分钟这个默认值就会让你收到一堆 504。反过来如果后端全部是快速接口默认 60 秒又太长异常时资源会一直被占着。我的做法是把常用超时值写在注释里标明依据下次改动的人能看懂为什么是这个数。多实例环境里pid 文件和配置文件路径一定要和实例一一对应能在启动命令里显式指定的就别依赖默认值。nginx -p /opt/nginx-a -c /opt/nginx-a/conf/nginx.conf这样写虽然啰嗦但排除了所有歧义出问题时不会被到底 reload 的是哪个浪费半小时。最后一个小技巧把nginx -V的输出存一份到/etc/nginx/version.txt记录当前编入了哪些模块、编译时间、版本号。升级或者换人维护时这份记录能省掉大量这个功能为什么没有的排查时间。机器会漂移文档会过期但一份当时的编译参数是最真实的证据。