搭一次 Nginx从装到跑通快的话一个小时就能收工真正耗时间的是搞明白它为什么要这么配。这篇就把 Nginx 的简介、安装、工作原理、工作方式以及配置文件从头到尾拆一遍全部是我自己在几台测试机和线上服务器上摸出来的东西。新手照着敲能跑起来有经验的朋友也能在 location 匹配顺序、worker 参数换算、反向代理透传真实 IP 这几块捡到点细节。整篇不依赖任何特定发行版CentOS、Ubuntu、麒麟信创环境都能对号入座离线内网机器我也单独给了一条路。读完你应该能做到三件事说清一个请求从进来到出去经过了几道手、看懂一份别人写的 nginx.conf、自己动手把静态站加反向代理配出来并排掉常见的 502 和 403。1. 先弄明白 Nginx 到底在解决什么问题很多人学 Nginx 是从抄配置文件开始的抄完能跑一旦出问题就两眼一抹黑。我更建议先花十分钟把它存在的理由想清楚后面看那些指令会顺很多因为每条指令背后都对应着一个具体的现实麻烦。1.1 一台机器扛不住的第一天设想你写了个 Web 应用一开始让它自己监听 80 端口用户直接访问它跑得挺顺。等到访问量上来你会发现几个问题同时冒出来静态图片和 CSS 全由应用进程去读盘、去拼响应白白吃掉 CPU 和内存应用一重启整个站点就 502 或者连接被拒想上 HTTPS得在应用代码里塞一堆和业务毫无关系的证书逻辑某天需要灰度上线一个新版本只能停机切。这些麻烦的共性是“业务逻辑”和“对外接入”被混在了一个进程里。Nginx 就是插在用户和你的应用中间的那一层。它站在最外面负责建立连接、收字节、发字节、管证书、限速、压缩、缓存、把请求转给后面的应用然后把应用吐出来的结果再送回去。你的应用从此只需要监听一个内网地址不用管公网、不用管 TLS、不用管并发连接的维护开销。这个位置在业界常被叫做“接入层”或者“七层网关”它不需要懂你的业务只需要把流量稳稳地送到位。1.2 反向代理、负载均衡、静态资源三张底牌反向代理是 Nginx 最核心的能力也是我日常用得最多的一项。所谓“反向”是相对于正向代理而言的正向代理是替客户端出去访问别人反向代理是替服务器接住客户端的请求。用户以为自己在跟一台服务器说话其实他在跟 Nginx 说话Nginx 再去问后面的应用。这个“中间人”身份带来了极大的自由度后端换 IP、换端口、加机器对用户完全透明。负载均衡是反代的自然延伸。既然请求都要经我手那我分给谁就由我说了算。默认的轮询、按权重分、按源 IP 哈希、按响应时间选择几种策略覆盖了绝大多数场景。上游某台机器挂了被动健康检查会在几次失败后把它暂时踢出列表这就是所谓的“摘除”。静态资源服务看起来朴素实际上是被严重低估的一块。Nginx 用 sendfile 直接在内核态把文件送到网卡零拷贝性能非常夸张。我们做过对比同样一张 200KB 的图走应用进程输出和走 Nginx 输出QPS 差了一个数量级CPU 占用也差得远。所以我的习惯是所有 JS、CSS、图片、字体、视频切片、前端打包产物一律交给 Nginx应用只处理真正需要计算的接口。注意不要把“反向代理”和“转发”混为一谈。反代是 Nginx 主动发起一个新连接到后端客户端的 TCP 连接和后端的 TCP 连接是两条完全独立的连接所以真实客户端 IP 默认会丢必须靠头部手工透传这一点后面会详细讲。1.3 和 Apache 的取舍不用非此即彼老生常谈的话题但网上很多说法已经不适用于现在的版本了我按自己的理解给个更实在的判断。Apache 的 prefork/worker 是“一个连接一个进程或线程”的模型连接数一高内存和上下文切换就成了瓶颈Nginx 是事件驱动一个 worker 用 epoll 同时盯住成千上万个连接空闲连接几乎不占额外资源。所以在高并发、大量慢连接、长轮询、静态资源这些场景Nginx 的优势非常直观。但 Apache 也不是没有优势。它支持 .htaccess 目录级配置共享主机、老 PHP 项目里大量依赖这个模块生态在某些特定需求上更齐全配置写法和生命周期也更容易理解。真实工作中我见到的组合比对立多得多Nginx 在前面做反代和静态Apache 或 PHP-FPM 在后面跑业务两边各干擅长的事。所以选型的时候别问“哪个更好”问“这个位置谁更合适”。2. 安装这件事方法选对比敲得快装 Nginx 有三条常见路径各有各的适用场景。选错了不一定报错但会在后面维护时给你添乱比如升级时覆盖配置、编译缺模块导致某个功能加不上。2.1 三种安装方式的取舍逻辑包管理器安装最省事yum install nginx或者apt install nginx一条命令完事服务脚本、日志轮转、默认目录全都给你配好。它的短板是版本偏旧而且模块是固定编进去的想加个第三方模块就得重来。官方源安装是折中方案加一个仓库地址能拿到比较新的稳定版本同时保留包管理的便利。缺点是要联网内网机器走不通。编译安装最灵活可以选择性编译模块、指定路径、指定依赖版本也是内网离线场景的唯一选择。代价是要自己处理依赖、自己写服务脚本、升级时得重新编译。我的建议是能联网的常规业务机走官方源稳定又省心内网信创机器走编译临时验证、容器镜像里跑用包管理器最快。# CentOS / RHEL / 麒麟系 sudo yum install -y epel-release sudo yum install -y nginx # Debian / Ubuntu 系 sudo apt update sudo apt install -y nginx # 装完立刻确认版本和编译参数 nginx -v nginx -V2.2 内网离线环境怎么把 Nginx 装上内网机器不能联网的时候思路就是把源码包和依赖一起搬进去。需要准备的通常是四样东西Nginx 源码、PCRE、zlib、OpenSSL。前两个几乎是必须的PCRE 用于 location 里的正则匹配zlib 用于 gzip 压缩OpenSSL 在你需要 HTTPS 时必须有。依赖库建议一起编译进 Nginx做成静态链接这样目标机器上不用再安装运行时库移植性最好。# 把离线包拷到 /opt/src 后解压 tar -zxvf nginx-1.24.0.tar.gz tar -zxvf pcre-8.45.tar.gz tar -zxvf zlib-1.3.tar.gz cd nginx-1.24.0 ./configure \ --prefix/usr/local/nginx \ --with-pcre/opt/src/pcre-8.45 \ --with-zlib/opt/src/zlib-1.3 \ --with-http_ssl_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-http_realip_module make -j$(nproc) sudo make install--prefix决定了安装根目录日志、配置、临时文件都挂在这下面。--with-http_realip_module是很多人会漏的一个当你的 Nginx 前面还有一层代理或负载均衡时没有它就拿不到真实客户端 IP。编译前记得装好gcc、make、pcre-devel、zlib-devel、openssl-devel这些基础工具否则./configure会在检查阶段直接失败。提示如果是在麒麟、统信这类国产系统上装包名可能带版本后缀用yum provides */xxx.h反查一下头文件属于哪个包比盲猜快得多。编译完成后务必把/usr/local/nginx/sbin加进 PATH或者做个软链到/usr/sbin/nginx负责运维的同事会感谢你。2.3 装完先别急着配业务先跑通这几个验证顺序很重要先验证进程能起再看端口能通最后才动业务配置。跳过前面两步直接改配置出问题时你分不清是装坏了还是配错了。# 1. 检查配置语法任何改动都先跑这个 nginx -t # 2. 查看完整生效配置包含 include 进来的所有片段 nginx -T # 3. 启动 / 重载 / 停止 nginx # 启动 nginx -s reload # 重载不中断已有连接 nginx -s quit # 优雅退出 nginx -s stop # 强杀 # 4. 确认端口和进程 ss -lntp | grep nginx ps -ef | grep nginx | grep -v grep外网访问不通的时候先别怀疑 Nginx八成是防火墙。CentOS 系默认是 firewalld放行方式如下sudo firewall-cmd --zonepublic --add-port80/tcp --permanent sudo firewall-cmd --zonepublic --add-port443/tcp --permanent sudo firewall-cmd --reload sudo firewall-cmd --list-portsUbuntu 系则是 ufwsudo ufw allow 80/tcp就行。还有一层容易被忽略的是 SELinux它在 enforcing 模式下会拦住 Nginx 对外发起连接和读取非标准目录getenforce看状态setsebool -P httpd_can_network_connect 1放开网络连接权限读取自定义目录要么改安全上下文chcon要么加策略。这个坑我在反代场景里踩过不止一次表现是 502但后端明明是活的。3. 工作方式master、worker 和那个叫 epoll 的东西配置文件看懂了但不知道为什么这么设计遇到“worker 数量到底填几”“连接数怎么算”就只能照抄别人的博客。把进程模型和事件模型理顺这些参数你会自己推。3.1 master 和 worker 的分工Nginx 启动后会有一个 master 进程和若干个 worker 进程。master 不处理任何请求它的活是读配置、创建监听套接字、fork 出 worker、监控 worker 状态以及在收到 reload 信号时用新配置拉起一批 worker 再让老的优雅退出。这个设计带来的最大好处是热重载用户连接不会断配置就换好了。worker 才是真正干活的每个 worker 都是独立的进程互不干扰一个 worker 崩了不影响其他 workermaster 会立刻补一个上来。由此带来两个实际结论。第一worker 之间不需要锁来争抢连接省掉了大量同步开销。第二多核机器上只要 worker 数量和核心数匹配就能把 CPU 吃满。这也是为什么worker_processes auto;在绝大多数情况下是正确选择它会自己读 CPU 核心数。3.2 异步非阻塞到底解决了什么这是 Nginx 原理里最值得讲清楚的一点。传统的每连接一线程模型一个连接如果暂时没有数据对应的线程就只能阻塞等着线程资源被白白占住。假设一台机器能开 2000 个线程那并发上限就被钉死在 2000 附近而且线程切换本身就消耗 CPU。Nginx 换了个思路worker 不阻塞在任何单个连接上。它把所有连接注册到一个事件通知机制里这个机制在 Linux 上就是 epoll。epoll 的职责是告诉 worker“哪些连接现在有数据可读、哪些可写”worker 只处理有事件的连接处理完立刻返回继续等。这样一来一个 worker 盯住几万个连接其中大部分处在空闲等待状态几乎不占资源。这种模式叫事件驱动或者叫 IO 多路复用。生活化的类比阻塞模型像是给每个客人配一个服务员客人不吃你就站着等epoll 像是大厅里一个服务员来回巡场谁的杯子空了就去倒一个服务员能照顾几十桌。前者人数多了成本爆炸后者人少但效率极高。3.3 worker 数量和最大连接数的换算有了上面的模型参数就好推了。worker_processes一般等于 CPU 核心数worker_connections表示单个 worker 能同时处理多少个连接。理论上限是二者相乘max_connections worker_processes × worker_connections但实际能服务的客户端数要比这个数字小原因有两个。一是 Nginx 自身要用掉几个连接比如和上游通信、内部通信。二是在反向代理场景下一个客户端请求会占用两个连接客户端到 Nginx 一条Nginx 到后端一条。所以经验公式是max_clients ≈ worker_processes × worker_connections / 2举个具体例子。一台 4 核机器worker_processes 4worker_connections 10240那么总连接数是 40960反代场景下大概能同时服务 2 万左右的客户端。如果系统还有限制就要一起调大# 查看和调整系统级限制 ulimit -n sudo vim /etc/security/limits.conf # 追加 # * soft nofile 65535 # * hard nofile 65535 # 内核层面 sudo sysctl -w net.core.somaxconn65535 sudo sysctl -w net.ipv4.tcp_max_syn_backlog65535注意worker_connections调大之后如果系统的文件描述符上限没跟着调Nginx 会在日志里刷 “too many open files”然后开始拒绝连接。这个报错很典型见到它先查 ulimit别急着改配置。3.4 惊群、accept_mutex 和 reuseport早期多进程模型有个经典问题叫惊群内核把新连接通知给所有正在等待的 worker结果一群 worker 同时被唤醒去抢最后只有一个抢到其余的又回去睡白白浪费 CPU。Nginx 早期的做法是用accept_mutex on;加一把锁同一时刻只让一个 worker 去 accept拿到连接后再决定是自己处理还是转交。这个方案有效但锁本身也有开销并且在高并发下会降低多核的扩展性。新版本 Linux 提供了SO_REUSEPORT让每个 worker 自己持有一个独立的监听套接字内核做负载均衡从根上避免了争抢。配置里对应的就是listen 80 reuseport;。我的实测感受是开启 reuseport 后Nginx 8 核以上机器的 CPU 分布明显更均匀长连接场景的抖动也更小。如果内核版本在 3.9 以上建议直接开。4. 配置文件从整体结构到每一条指令配置文件是 Nginx 学习里信息密度最高的一块也是最多人卡住的地方。我的方法是先记层次再记语法最后才是具体指令顺序反过来会越看越乱。4.1 五层结构先建骨架Nginx 的配置文件是分层的外层叫上下文内层叫块。层次感一旦建立看到陌生配置你也能一眼定位它属于哪一层从而判断它的作用范围。层级位置作用范围main最外层全局影响所有 workereventsmain 内部连接处理模型相关httpmain 内部所有 HTTP 服务serverhttp 内部一个虚拟主机对应一组域名和端口locationserver 内部一个 URL 路径的匹配规则规则很简单内层继承外层的配置内层可以覆盖外层但不同层支持的指令是有约束的把 server 块的指令写到 http 块会直接报语法错误。nginx -t就是帮你查这个的。4.2 一份逐行注释过的 nginx.conf下面这份我会把每条常用指令的用途都标上你直接对照着自己机器上的文件看会快很多。user nginx; # worker 运行身份别用 root worker_processes auto; # 自动匹配 CPU 核心数 error_log /var/log/nginx/error.log warn; # 错误日志warn 级别够日常用 pid /var/run/nginx.pid; events { use epoll; # Linux 上显式指定 worker_connections 10240; # 单 worker 最大连接数 multi_accept on; # 一次事件尽量多接受连接 } http { include mime.types; # 扩展名到 Content-Type 的映射 default_type application/octet-stream; log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log main; sendfile on; # 零拷贝静态文件必开 tcp_nopush on; # 配合 sendfile 一起发头和数据 tcp_nodelay on; # 小包立即发降低延迟 keepalive_timeout 65; # 长连接保留时间 gzip on; # 开启压缩 gzip_min_length 1k; # 太小不压压缩比不划算 gzip_comp_level 5; # 4~6 是性价比区间 gzip_types text/plain text/css application/json application/javascript text/xml application/xml; include /etc/nginx/conf.d/*.conf; # 子配置业务都写这里 }几个点值得单独说。user指令决定 worker 以什么身份跑用 root 会让 Nginx 进程拥有过高权限一旦有漏洞后果很严重所以主进程虽然是 root 起的为了绑 80 端口worker 一定要降权。sendfile on是静态文件性能的关键它把数据从文件直接送到网卡绕过用户态内存拷贝。gzip_comp_level不建议拉到 9压缩率提升很有限但 CPU 开销翻倍5 左右是比较平衡的位置。4.3 location 匹配顺序这是踩坑最多的地方Nginx 的 location 匹配有一套明确的优先级不搞清楚会写出“明明有这条规则却没命中”的配置。规则按优先级从高到低优先级写法含义1location /path精确匹配命中即止2location ^~ /path前缀匹配且不继续匹配正则3location ~ \.php$正则匹配区分大小写按书写顺序4location ~* \.jpg$正则匹配不区分大小写5location /path普通前缀匹配取最长的那条实际执行流程是这样的先看有没有精确匹配有就直接用没有就找出最长的普通前缀匹配如果这条带^~直接用不再看正则否则按文件里书写的顺序去试正则第一个命中的就用如果正则都没命中才回退到刚才那条最长前缀。server { listen 80; server_name example.com; location /health { return 200 ok; } location ^~ /static/ { root /data/www; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; } location / { proxy_pass http://127.0.0.1:8080; } }这份配置的意图是健康检查直接返回、静态目录不进入正则匹配省掉不必要的正则开销、PHP 走 FastCGI、其余全部转给后端应用。顺序清晰各管一段实际项目里很好维护。4.4 root 和 alias 的差别一不留神就 404这两个指令功能相近效果差别很大是新手最容易搞混的一对。# root最终路径 root 值 location 路径 location /img/ { root /data/www; } # 访问 /img/a.png - /data/www/img/a.png # alias最终路径 alias 值location 路径被替换掉 location /img/ { alias /data/www/pics/; } # 访问 /img/a.png - /data/www/pics/a.png记法root 是“拼”alias 是“替”。用 alias 的时候location 的结尾有没有斜杠、alias 的结尾有没有斜杠都会影响最终路径写错就是 404 或者 403。我的做法是统一用 root把目录结构设计得和 URL 一致只有在 URL 和磁盘目录确实对不上时才用 alias。另外try_files也是高频指令用于单页应用的 history 路由location / { root /data/www/dist; try_files $uri $uri/ /index.html; }它的含义是按顺序找文件$uri找不到就找$uri/目录都找不到就返回 index.html交给前端路由处理。这是 Vue、React 项目部署的标准写法。5. 几个高频场景的完整配置原理和语法讲完落到最常用的几类配置上。这些都是我实际生产里跑过的版本你可以直接拿去改。5.1 反向代理顺带把真实 IP 传下去反代本身很简单难的是让后端应用到真实客户端 IP以及让应用知道自己被代理了。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_send_timeout 60s; proxy_read_timeout 60s; proxy_next_upstream error timeout http_502 http_504; }proxy_pass末尾那个斜杠非常关键。写法是http://127.0.0.1:8080/时/api/user会被转发成/userlocation 前缀被剥掉写法是http://127.0.0.1:8080时转发后仍然是/api/user。这个差异我在联调时被坑过后端同事说接口 404查了半天是斜杠多了一个。X-Forwarded-For是一个追加型的头配合proxy_add_x_forwarded_for每经过一层代理就会在后面追加一个 IP形成链路。后端取值的时候要取第一个注意这是可以从客户端伪造的真正可信的做法是在最外层把客户端传来的这个头清掉再自己写proxy_set_header X-Forwarded-For $remote_addr;。超时三个参数各有分工connect_timeout是 Nginx 连后端的时间一般给很短的 3 到 5 秒read_timeout是等后端响应的间隔时间注意它是两次数据之间的间隔不是总时长send_timeout是往后端发数据的时间。这三个值设太短会导致 504太长会让慢请求堆积占用 worker 连接。5.2 一台机器部署多个 Web 项目这个需求太常见了一台服务器上跑三四个项目。两种分法按域名分和按路径分。按域名分最干净每个项目一个 server 块server { listen 80; server_name shop.example.com; root /data/www/shop/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; } } server { listen 80; server_name admin.example.com; root /data/www/admin/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8082; } }按路径分适合没有多余域名的情况用 location 前缀区分server { listen 80; server_name example.com; location /shop/ { alias /data/www/shop/dist/; index index.html; try_files $uri $uri/ /shop/index.html; } location /admin/ { alias /data/www/admin/dist/; index index.html; try_files $uri $uri/ /admin/index.html; } }按路径分有个容易被忽略的坑前端打包时的publicPath必须和 location 前缀一致。如果前端是按根路径/打包的资源引用全是/assets/xxx.js而 location 挂在/shop/下加载就会 404。解决办法是在前端构建配置里把基础路径改成/shop/重新打包而不是在 Nginx 里绕。提示多个项目共用 80 端口时server_name相同会导致只有第一个 server 生效Nginx 会警告conflicting server name。出现这种情况用nginx -T搜一下重复的 server_name通常是从别处复制的配置忘了改。5.3 静态资源缓存与压缩策略缓存配置直接决定用户第二次访问的速度配得好带宽能省一大半。location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?)$ { root /data/www/dist; expires 30d; add_header Cache-Control public, max-age2592000, immutable; access_log off; } location ~* \.html$ { add_header Cache-Control no-cache, must-revalidate; }思路是带内容哈希的静态资源webpack 打包出来的文件名里带 hash可以放心长期缓存设 30 天甚至一年都行因为文件内容变了文件名也会变HTML 入口文件绝对不能长期缓存否则用户永远拿到旧版本必须每次校验。immutable告诉浏览器在这个期限内不用发校验请求进一步减少往返。access_log off是给静态资源关日志图片视频类的访问日志量大且没什么分析价值关掉能明显减少磁盘 IO。但注意业务接口的日志一定要开出问题时那是唯一的线索。5.4 HTTPS 配置和证书注意事项HTTPS 现在基本是标配配置本身不复杂重点在两个地方协议版本和证书链完整性。server { listen 443 ssl; http2 on; server_name example.com; ssl_certificate /etc/nginx/cert/fullchain.pem; ssl_certificate_key /etc/nginx/cert/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { root /data/www/dist; try_files $uri $uri/ /index.html; } } server { listen 80; server_name example.com; return 301 https://$host$request_uri; }证书文件要放对ssl_certificate应该是包含完整链路的文件服务端证书加中间证书拼在一起顺序是服务端在前。如果只放了服务端证书电脑浏览器可能正常但部分手机 App 和小程序会报证书错误因为它们的校验更严格。测试证书链是否完整用openssl s_client -connect example.com:443 -servername example.com看输出里有没有Verify return code: 0。私钥文件的权限也要处理一般设成 600 并且属主是 root因为 master 进程以 root 运行能读到worker 不需要读私钥。6. 排障实录那些报错到底在说什么Nginx 的报错信息其实挺直白难的是不知道自己该看哪个文件。这一节我按实际遇到的频率整理配上一套排查顺序。6.1 四个高频错误码的速查表错误码典型原因排查方向502 Bad Gateway后端没起、端口写错、SELinux 拦截、后端崩溃curl直连后端、看 error.log、查 SELinux504 Gateway Timeout后端处理慢、超时值太小、后端死锁加大 proxy_read_timeout、看后端日志403 Forbidden目录权限、index 缺失、autoindex 关闭检查目录 x 权限和属主、确认 index 文件存在404 Not Foundroot/alias 路径错、location 没命中用nginx -T确认生效配置、逐层推路径502 是最常见的我给个固定的排查顺序先在后端机器上curl -I http://127.0.0.1:8080确认后端本身是活的然后在 Nginx 机器上curl -I http://127.0.0.1:8080确认网络通最后看 error.log 里的具体行它通常会写connect() failed (111: Connection refused)或者(13: Permission denied)前者是没起来后者基本就是 SELinux 或防火墙。403 里有一个特别隐蔽的情况目录权限。Nginx 读取一个文件需要路径上每一级目录都有 x 权限。曾经有一次我把静态目录设成 700属主是 rootNginx worker 是 nginx 用户结果图片全都 403文件本身权限没问题卡在上层目录。命令namei -l /data/www/dist/index.html能把每一级权限列出来比手工一层层看快。6.2 把日志用起来默认的日志配置够用但稍微改一下会舒服很多。error.log 里的级别从低到高是 debug、info、notice、warn、error、crit日常用 warn排查问题临时调到 info 甚至 debugdebug 需要编译时带--with-debug。调完记得 reload而且调完要记得调回来debug 级别的日志量非常恐怖磁盘会被迅速写满。访问日志想抓慢请求可以自定义 log_format 加上$request_time和$upstream_response_time。前者是从客户端收完请求到发完响应的总耗时后者是后端处理的耗时。两个一对比就能立刻判断慢是慢在 Nginx 这边还是后端那边。log_format timing $remote_addr $request $status req$request_time up$upstream_response_time; access_log /var/log/nginx/timing.log timing;日志切割不要用mv完事那样正在写的文件句柄还指向旧文件新日志会继续写进被移走的文件。正确做法是配合信号mv access.log access.log.$(date %F) nginx -s reopen # 或者 kill -USR1 $(cat /var/run/nginx.pid)reopen会让 Nginx 用新配置重新打开日志文件。当然更省心的做法是配一条 logrotate 规则让它每天自动做这件事保留 14 天历史文件压缩。6.3 几个我自己踩过的坑reload 之后配置没生效。最常见的原因是改了conf.d下的文件但文件名不是.conf结尾include语句匹配不到它。另一个原因是写在了http块里但期望它是server级别生效范围不对。养成习惯改完先nginx -t再nginx -T | grep关键指令确认它真的在生效配置里。目录权限正确但依然 403。先查 SELinux 状态再看是不是挂载了带noexec或者特定安全标签的分区。有些云主机的数据盘默认挂载参数会影响读取mount | grep 数据盘路径看一眼。长连接不生效。检查Connection头是不是被上游设成了close以及keepalive_requests有没有被设得很小。前端如果走 CDN还要确认 CDN 那侧的连接复用策略光调 Nginx 是没用的。改了 worker_connections 但连接数上不去。回到第 3.3 节系统级的ulimit -n必须大于等于worker_connections否则配置是摆设。改 limits.conf 之后要重新登录 shell 才生效光 reload Nginx 没用。时间不对导致的诡异问题。证书校验失败、签名过期、JWT 校验不过很多时候只是服务器时间偏移了。部署完第一件事就是timedatectl看一眼有 NTP 就同步一下这种问题排查起来特别浪费时间。注意任何时候改配置之前先备份一份cp nginx.conf nginx.conf.bak.$(date %F)Ubuntu 系可以配nginx -t通过后自动重载的钩子但生产环境我还是建议手动确认一步多花十秒换来的是不会因为一次手抖把线上搞挂。我个人在带新人的时候从来不要求他们背指令只要求三件事做熟知道nginx -t和nginx -T是干什么的、能说清一个请求从进来到出去经过了哪些环节、能在 502 出现时按顺序定位到到底是后端没起还是权限拦住了。这三件事做到了配置里剩下的东西都是查文档就能补上的。至于更进阶的限流、灰度、Lua 扩展、OpenResty等业务真的需要了再学那时候你会发现自己缺的从来不是那些花哨功能而是对上面这些基础环节的确定感。