做Web开发和运维这些年我几乎每天都要跟Nginx打交道。不管你是给Spring Boot应用做反向代理还是给前端静态资源做缓存加速Nginx基本都是绕不开的第一选择。身边不少朋友问过我同样的问题Nginx到底怎么装、怎么配、怎么排查网上教程一大堆但要么太散要么只给配置模板不讲为什么。今天这篇就把我这些年实际部署Nginx积累的东西系统梳理一遍从安装选型、核心配置、反向代理、静态缓存、安全加固到平滑升级配合真实场景下的实操细节和踩坑记录。刚接触Web部署的新人、被Nginx配置绕晕的运维、以及想让Web项目上线更稳的开发都可以从里面找到能直接抄作业的东西。1. 先搞清楚Nginx在Web项目里到底扮演什么角色1.1 三个最常见的部署场景先说结论Nginx在Web项目里最常见的工作有三类——静态文件服务、反向代理、负载均衡。静态文件服务是最基础的能力。前端打包出来的HTML、CSS、JS、图片本质上都是静态文件Nginx可以直接把它们高效地吐给浏览器。这个场景你甚至不需要写一行后端代码一个server块就搞定。反向代理是另一个高频场景。你的后端服务跑在8080端口甚至内网的其他机器上用户不可能直接访问这个端口于是Nginx在80/443端口接收请求再把请求转发给后端服务拿到响应后返回给用户。用户看到的是Nginx背后处理的却是Tomcat、Node.js或者Python应用。负载均衡则是项目规模上来之后的必然需求。比如你的后端服务部署了3个实例Nginx作为入口把请求按策略分发给这3个实例既分摊压力又能在一台机器挂掉时自动切换。这三个场景不是互相排斥的。一个生产环境的Nginx配置往往是同时承担静态资源服务、反向代理、负载均衡、HTTPS终结这好几件事。1.2 为什么不用Tomcat直接扛流量很多人刚接触Web部署时会有疑问既然Tomcat能处理动态请求也能返回静态页面为什么还要在前面加一层Nginx我举个实际例子你就明白了。Tomcat是Servlet容器它的设计核心是处理Java的动态逻辑处理高并发连接时每个连接会占用一个线程即使是用NIO模式连接管理和请求处理的模型也比Nginx重。而Nginx基于事件驱动的异步架构在Linux上用epoll模型处理大量并发连接单进程就能扛住数万个空闲连接。用生活化的方式理解Tomcat像是餐厅里的厨师团队擅长做菜处理动态逻辑但如果是门口排队叫号这种纯琐碎的事让厨师干就太浪费了。Nginx就是那个专门负责接待、叫号、引座的迎宾把静态资源和基础请求挡下来只把真正需要做菜的动态请求交给Tomcat。另外还有一层原因安全隔离。如果后端服务直接暴露公网等于把业务逻辑的入口直接摆在攻击者面前。Nginx在前面做了一层缓冲可以统一处理访问控制、请求大小限制、限流、SSL证书后端服务反而可以做更严格的内网访问控制。这也是为什么企业级的Web架构里Nginx几乎成了标配入口。2. 安装Nginx不同环境的选型和避坑2.1 用系统包管理器安装最省心日常部署中我优先推荐用系统的包管理器安装Nginx因为后续升级、卸载、查依赖都省事。CentOS/RHEL/AlmaLinux 9这类系直接sudo dnf install -y nginx sudo systemctl enable --now nginxUbuntu/Debian系则用aptsudo apt update sudo apt install -y nginx sudo systemctl enable --now nginx安装完先做一个最简单的验证访问服务器IP能看到Nginx默认欢迎页就说明基本环境通了。注意AlmaLinux 9上默认仓库里带的Nginx版本可能不是最新的如果想要更新版本需要额外添加官方yum源或者用源码编译这个后文会讲。这里有一个很重要的细节用包管理器安装的Nginx配置文件默认放在/etc/nginx/nginx.conf站点配置放在/etc/nginx/conf.d/目录日志在/var/log/nginx/。很多人看网上的教程直接去改/usr/local/nginx/conf/nginx.conf结果发现改的文件压根不存在因为在编译安装方式下路径才是/usr/local/nginx/。路径搞混是新手最容易踩的坑。2.2 源码编译安装适合定制场景如果需要定制模块比如想启用某些第三方模块、控制安装路径、或者系统仓库里版本太旧那就走源码编译。编译安装在纯内网环境也很常见——先把源码包和数据包准备好拷进去离线编译也能完成。编译前需要确认依赖gcc、make、pcre支持正则、重定向、zlib支持gzip压缩、openssl支持HTTPS。缺少任何一个configure阶段就会报错。sudo dnf groupinstall -y Development Tools sudo dnf install -y pcre pcre-devel zlib zlib-devel openssl openssl-devel下载源码后执行wget https://nginx.org/download/nginx-1.26.2.tar.gz tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-stream make -j$(nproc) sudo make install--prefix指定安装目录--with-http_ssl_module一定要加否则后面配HTTPS会发现没有SSL模块那是真的欲哭无泪。--with-stream是为了支持TCP/UDP四层代理如果你的场景需要代理MySQL、Redis等非HTTP协议这个模块必须启用。编译安装完还要手动做两件事创建软链接把nginx命令放到/usr/bin下以及编写systemd服务文件否则没法用systemctl管理每次都要手动启动进程。我建议直接把编译安装的配置和管理方式写清楚避免后面忘掉。2.3 Windows和Docker场景的特殊处理Windows下安装Nginx很简单去官网下载zip包解压直接双击nginx.exe启动。但要注意Windows版的Nginx没有守护进程也没有systemd进程挂了不会自动拉起生产环境非常不推荐。Windows版主要用来本地调试配置、验证规则。Docker部署则是现在更主流的方案docker run -d --name nginx-web \ -p 80:80 \ -p 443:443 \ -v /opt/nginx/conf.d:/etc/nginx/conf.d \ -v /opt/nginx/html:/usr/share/nginx/html \ -v /opt/nginx/logs:/var/log/nginx \ nginx:1.26-alpine用alpine镜像体积小基础库精简适合生产。挂载配置目录后改配置不用进容器直接改宿主机文件然后docker exec nginx-web nginx -s reload重载即可。这里我强调一点Docker内的Nginx默认不带bash进入容器调试用的是docker exec -it nginx-web /bin/sh别用bash习惯去敲会提示找不到命令。3. 核心配置逐条拆解读懂Nginx的四个层级3.1 配置文件结构从全局到locationNginx的配置是分层的树形结构从外到内依次是main全局块、events事件块、httpHTTP块、server虚拟主机块、location请求匹配块。用盖房子的思路理解全局块决定房子地基用多少材料events块决定门开在哪里http块是整栋楼的水电总管道server块是每一户的装修方案location块是每个房间里家具摆放的位置。一个最精简的结构长这样worker_processes auto; # main全局块 events { worker_connections 10240; # 每个worker能同时处理的连接数 } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; server { listen 80; server_name example.com; location / { root /usr/share/nginx/html; index index.html index.htm; } } }这里有几个关键参数值得展开说。worker_processes auto表示自动匹配CPU核心数。Nginx的worker进程数量一般跟CPU核数一致即可不是越多越好太多反而增加上下文切换的开销。worker_connections决定每个worker进程能同时保持的最大连接数。理论上Nginx能支撑的最大并发连接数大约是worker_processes × worker_connections。如果worker_connections设太小高并发下会出现连接被拒的情况日志里报accept() failed。sendfile on是零拷贝技术的开关启用后静态文件传输不走用户态拷贝直接在内核态完成对文件传输性能提升明显。如果你做的是大量静态文件服务这个开关必须开。3.2 server块和location匹配规则一个server块就是一个虚拟主机通过listen端口和server_name域名来区分。同一台服务器上可以配多个server块让不同的域名访问到不同的项目目录这就是最常见的一台机器挂多个网站方案。location匹配规则是Nginx配置里最容易出Bug的地方。匹配优先级从高到低是前缀精确匹配比如location /login只匹配/login这一个路径^~前缀普通字符前缀匹配匹配后不再检查正则~或~*前缀正则匹配~*忽略大小写普通前缀匹配最长前缀优先我实战中常用的一个配置location /health { return 200 ok; } location ^~ /static/ { alias /data/project/static/; expires 30d; } location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 7d; add_header Cache-Control public, immutable; } location / { proxy_pass http://backend_app; }这个配置分别处理了健康检查、静态资源别名映射、带后缀文件的缓存策略以及其余请求全部转发给后端。每种匹配规则用不同的场景逻辑一目了然。3.3 root与alias的区别这个坑我见过太多次了。root和alias都能指定静态文件目录但行为完全不同。# root方式URI会拼接在root路径后面 location /static/ { root /data/www; # 请求 /static/a.js - 实际找 /data/www/static/a.js } # alias方式alias路径直接替代location匹配的那部分 location /static/ { alias /data/www/static/; # 请求 /static/a.js - 实际找 /data/www/static/a.js }用root时真实路径是root拼接完整URI用alias时真实路径是alias拼接去掉了location前缀之后的URI。如果配置不当最常见的结果就是404。我的经验是location里带了子路径要指向不同目录时用alias更直观如果目录结构和URI完全一致用root更省事。配完后一定要用curl -I http://127.0.0.1/static/a.js验证一下实际返回的状态码别等上线了才发现资源全404。4. 反向代理与负载均衡实战4.1 从单台后端到完整的proxy_pass反向代理的核心指令是proxy_pass用法看起来简单但有一个隐藏的陷阱——URL带不带/行为完全不同。# 带URI形式location匹配部分会被替换 location /api/ { proxy_pass http://192.168.1.10:8080/; } # 请求 /api/user/list - 转发为 http://192.168.1.10:8080/user/list # 不带URI形式原样转发整个URI location /api/ { proxy_pass http://192.168.1.10:8080; } # 请求 /api/user/list - 转发为 http://192.168.1.10:8080/api/user/list这两者的差异是带/会把/api/前缀在转发时剥掉不带/则保留。后端接口如果设计的是带/api前缀的你转发时剥掉就会404反之亦然。这个规则在改配置时极其容易踩到我建议每次配完都抓一下后端日志看看实际收到的请求路径是不是预期的。完整的反向代理配置还应该带上客户端真实信息server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_app; 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_set_header这几行很重要。后端应用拿到请求后能通过这些头部知道用户真实的IP和协议否则后端看到的所有请求都来自Nginx的地址记日志、做限流、判断用户归属全都失真。proxy_read_timeout设短了后端慢接口会报504设太长连接资源被占用。我一般根据业务接口的P95耗时来定大多数项目60秒够了。4.2 upstream负载均衡与健康检查后端服务有多台实例时用upstream定义一组后端再在proxy_pass里引用upstream backend_app { server 192.168.1.11:8080 weight3 max_fails3 fail_timeout10s; server 192.168.1.12:8080 weight1 max_fails3 fail_timeout10s; keepalive 32; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend_app; proxy_http_version 1.1; proxy_set_header Connection ; } }这里解释几个参数。weight是权重默认是1权重越大被分配的请求越多适合做灰度发布时让新实例少接流量。max_fails3和fail_timeout10s组合的意思是10秒内如果连续失败3次就把这台后端标记为不可用10秒后再尝试。这已经是一种基础的被动健康检查机制不用额外装组件。keepalive 32是保持后端长连接池的数量。默认情况下Nginx和后端之间每次请求都新建TCP连接高并发时握手开销很大。启用proxy_http_version 1.1和清空Connection头让Nginx复用和后端的连接性能能提升不少。负载均衡算法除了默认的轮询round-robin外常用的还有ip_hash——根据客户端IP哈希分配保证同一IP的请求总是打到同一台后端适合需要会话保持的场景least_conn——分发给当前连接数最少的那台后端适合请求处理时间差异大的场景。4.3 与Java应用的联动动态和静态分离经典的企业级部署是Nginx Tomcat的动静分离方案。前端资源由Nginx直接服务动态接口转发给Tomcat。假设一个前后端不分离的传统项目部署结构如下server { listen 80; server_name www.example.com; root /data/www/example; index index.html; # 静态资源 location ~* \.(html|css|js|png|jpg|gif|ico|svg|woff2?)$ { expires 7d; access_log off; } # 动态请求交给Tomcat location /web/ { proxy_pass http://tomcat_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 拒绝访问隐藏文件 location ~ /\. { deny all; } }这样配置后图片、样式、脚本全由Nginx高性能返回Tomcat只处理真正需要Java逻辑的接口压力瞬间小一个量级。Java博客、论坛、企业管理系统这类项目的上线部署用的都是这套思路。Spring Boot项目也类似唯一区别是后端端口通常是8080、8081这类内嵌容器端口代理配置完全通用。5. 静态资源、缓存与文件共享5.1 静态资源缓存与gzip压缩Web项目上线后页面加载速度是用户体验的硬指标。Nginx在静态资源加速上有三板斧gzip压缩、expires缓存、CDN回源配合。先看gzipgzip on; gzip_min_length 1k; gzip_comp_level 5; gzip_types text/plain text/css text/javascript application/javascript application/json application/xml image/svgxml; gzip_vary on;gzip_min_length 1k表示小于1KB的文件不压缩因为压缩这些文件省不了多少体积反而增加CPU开销。gzip_comp_level设为5左右在压缩率和CPU消耗之间比较平衡拉满到9会明显增加CPU负担收益却很小。注意gzip_types要写完整有些人开了gzip却发现JSON接口没压缩就是因为缺了application/json类型。再看expires缓存location ~* \.(jpg|jpeg|png|gif|js|css)$ { expires 7d; add_header Cache-Control public, immutable; }expires 7d会给响应加上Expires和Cache-Control: max-age604800头。浏览器在缓存有效期内不会再向服务器发请求直接本地取。对带版本号hash的静态资源加immutable完全没问题如果资源会更新就不要盲目加否则用户看到的永远是旧版本这种问题在生产环境出现频率极高。还有一个实操细节静态资源的access_log建议关掉。图片验证码被刷屏的时候access.log每秒钟写几百行磁盘很快就会被打满。access_log off;一行就能避免这种无意义的IO消耗。5.2 文件共享与目录列表Nginx做文件共享的场景也很常见——内网服务器上放一堆安装包、日志压缩包、离线文档想让同事用浏览器直接下载。用autoindex就能实现一个无界面的简易文件服务器server { listen 8080; server_name files.example.com; location /download/ { alias /data/files/; autoindex on; autoindex_exact_size off; autoindex_localtime on; charset utf-8; } }autoindex on开启目录列表autoindex_exact_size off让文件大小以人类可读的K/M/G显示autoindex_localtime on用本地时间显示文件修改时间。注意目录中文名或中文文件名一定要加charset utf-8;否则浏览器里显示乱码。文件共享场景里Nginx还自带一个实用能力——断点续传。因为静态文件服务默认支持Range请求用wget -c或者下载工具拉大文件中途断了重开能继续下载。配合sendfile on大文件传输效率很不错。5.3 反向代理级别的缓存如果后端接口数据变化不频繁还能在Nginx这一层做代理缓存后端扛不住压力的时候这个方案能救命proxy_cache_path /var/cache/nginx levels1:2 keys_zoneapi_cache:10m max_size10g inactive60m; location /api/ { proxy_pass http://backend_app; proxy_cache api_cache; proxy_cache_key $host$request_uri; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; }proxy_cache_path定义了缓存的存储路径、目录层级、共享内存区大小。keys_zoneapi_cache:10m表示用10MB内存保存缓存元数据key和相关状态实际数据落盘。proxy_cache_valid 200 302 10m表示对于200和302响应缓存10分钟。这里要特别小心缓存机制只对GET请求生效POST默认不会缓存千万别指望着用这个缓存用户提交的表单请求。另一个坑是如果后端返回的是Set-Cookie响应头默认情况下Nginx不会缓存带Cookie的响应这其实是个安全保护机制但如果你没意识到这一点会发现缓存命中率不对劲。6. HTTPS配置与Web安全加固6.1 HTTPS证书配置和强制跳转现在的Web项目HTTPS已经是基础要求不只是为了安全也是因为浏览器和搜索引擎对HTTP站点的打压越来越明显。Nginx配置HTTPS的核心步骤是准备证书和修改server块。假设你已经从证书机构获取了证书文件example.com.crt和example.com.key配置如下server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.crt; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { proxy_pass http://backend_app; } } # HTTP访问强制跳转到HTTPS server { listen 80; server_name example.com; return 301 https://$host$request_uri; }ssl_session_cache和ssl_session_timeout这两个参数很多人会忽略但TLS握手开销大开启会话缓存后同一客户端的后续请求能直接复用会话握手次数大幅减少。实测在大量短连接场景下开启会话缓存对响应速度的提升非常明显。ssl_protocols TLSv1.2 TLSv1.3这一行也很关键。好多老配置里还写着TLSv1 TLSv1.1这两种协议早就被证明不安全主流浏览器也已经禁用。如果你发现网站在Chrome/Firefox上提示此网站无法提供安全连接十有八九是协议配置落后了。6.2 隐藏版本号、限制请求体、防目录遍历安全加固里最基础但最有效的几件事Nginx都能做。隐藏版本号server_tokens off;这个指令会去掉Nginx响应头里的版本号。攻击者知道你的版本后可以直接去搜对应版本的已知漏洞所以要关掉。限制请求体大小client_max_body_size 20m;如果项目里有文件上传功能这个值要根据业务需求设。默认值是1m超过的上传请求直接返回413。很多人部署完上传功能发现大文件传不上去就是卡在这里。防止目录遍历和隐藏文件访问location ~ /\. { deny all; } location ~* \.(?:bak|conf|sql|fla|psd|sh|ini|log)$ { deny all; }第一段禁止访问所有以点开头的隐藏文件和目录比如.git目录泄露是一个很常见的信息泄露漏洞。第二段禁止访问备份文件、配置文件、数据库导出文件这类高危后缀。Web安全里找flag夺旗赛这类CTF训练中最常见的出题点就是.git泄露和备份文件泄露实际生产环境里这些问题同样致命只不过埋得更深。常规的渗透测试思路是先扫目录、找备份文件、看响应头信息、试上传点。所以加固方向也很明确——把这些信息泄露的入口堵死。另外如果后端接口涉及查询参数Nginx层可以用limit_req做基础限流limit_req_zone $binary_remote_addr zoneapi_limit:10m rate10r/s; location /api/ { limit_req zoneapi_limit burst20 nodelay; proxy_pass http://backend_app; }rate10r/s表示每个IP平均每秒最多10个请求burst20允许突发20个请求排队nodelay表示突发时不等待直接处理。这个配置能让恶意刷接口的请求直接被Nginx挡在门外后端压力骤减。但注意别把限流设得太死否则正常用户的并发拉列表接口也会被误伤。6.3 安全响应头给浏览器一层额外防护在Nginx里给所有响应统一加上安全头是我一直推荐的做法add_header X-Frame-Options SAMEORIGIN always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy strict-origin-when-cross-origin always; add_header Content-Security-Policy default-src self; script-src self unsafe-inline unsafe-eval; style-src self unsafe-inline; img-src self data:; connect-src self always;逐个说下作用。X-Frame-Options: SAMEORIGIN防止你的页面被别的网站用iframe嵌入这是防点击劫持的基础手段。X-Content-Type-Options: nosniff告诉浏览器不要猜测响应内容的类型防止MIME嗅探攻击。Referrer-Policy控制页面跳转时Referrer头携带的信息量避免URL里的敏感参数泄露给第三方。Content-Security-PolicyCSP是更强大的浏览器安全机制比如限制脚本只能从本域加载内联脚本如果不必要就坚决不允许。需要提醒的是CSP配置写得太严可能会把正常业务打断——比如开发控制台报Refused to load the script就是被CSP拦了。所以生产环境上线CSP要分级走先从Content-Security-Policy-Report-Only模式观察确认不误伤业务再强制开启。这是我在多个项目里实践出的稳妥路径。7. 平滑升级与常见问题排查实录7.1 Nginx平滑升级不中断服务换版本Nginx还有一个很实用的能力——平滑升级。生产环境的Nginx跑了大半年想升级到新版本又不想中断服务不需要停机只需要编译新版本后发信号切换。前提是你当前Nginx是源码编译安装的。在旧Nginx源码目录下载新版本源码同样configure参数重新编译但不用make install而是# 先用新编译的二进制替换旧二进制备份旧的 cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old cp objs/nginx /usr/local/nginx/sbin/nginx # 发送USR2信号启动新的master进程 kill -USR2 $(cat /usr/local/nginx/nginx.pid) # 发送WINCH信号优雅关闭旧的worker进程 kill -WINCH $(cat /usr/local/nginx/nginx.pid.oldbin) # 确认新版本工作正常后让旧master完全退出 kill -QUIT $(cat /usr/local/nginx/nginx.pid.oldbin)这个过程的原理是Nginx的master进程收到USR2信号后会把pid写到新文件nginx.pid.oldbin然后启动新的master和一套新的worker。新旧两个进程同时工作新连接的请求由新worker处理旧worker在处理完存量请求后由WINCH信号优雅退出。整个切换过程对外服务不中断。升级完别忘了验证/usr/local/nginx/sbin/nginx -v我在做平滑升级时还习惯先留个后手——旧的二进制保留一份万一新版本有严重Bug发送HUP信号给旧master还能回滚。生产环境操作前永远给自己留一条退路。7.2 高频问题速查表这里整理一份Nginx高频问题的排查速查表都是我在实际运维和帮朋友排查时反复遇到的问题现象可能原因排查与解决403 Forbidden目录无权限、index文件不存在、selinux拦截检查目录权限Nginx运行用户如nginx需有读和执行权限确认index文件存在用setenforce 0临时验证selinux因素502 Bad Gateway后端服务挂了、后端端口错、proxy_pass路径不对先curl后端地址确认服务存活看后端日志检查Nginx error.log504 Gateway Timeout后端处理超时调大proxy_read_timeout检查后端是否有慢SQL或阻塞调用404 Not Foundroot/alias路径错误、location匹配不符合预期用curl -I实测检查error.log中open()显示的实际文件路径静态资源不缓存缺少expires指令、响应带Set-Cookie检查响应头确认location规则覆盖到对应后缀修改配置不生效忘了reload每次改完执行nginx -t nginx -s reload前端页面加载报错静态资源路径带错、CSP拦截浏览器F12看Network面板定位被拦资源检查CSP配置局域网无法访问监听地址是127.0.0.1、防火墙拦截确认listen监听0.0.0.0或内网IP检查防火墙放行80/443端口第8条局域网无法访问特别要单独说。开发时我们在本机用opencode web这类工具起服务默认绑定的地址是127.0.0.1那同局域网的其他电脑当然访问不了。把这个服务放到Nginx后面时如果发现只有本机能访问、其他机器打不开先别急着怀疑Nginx配置先确认两件事一是监听地址是不是只绑了回环地址ss -tlnp一看便知二是服务器防火墙有没有放行对应端口。这两个问题占了局域网访问不通案例的八成以上。7.3 日志排障定位四步法遇到线上问题我有一套固定的排障路径分享出来供参考。第一步查nginx -t确认配置语法没问题。这一步5秒搞定能排除一大半改错配置的情况。第二步看/var/log/nginx/error.log。注意error.log是分级记录的error_log指令可以指定级别debug、info、notice、warn、error、crit。默认是error级别排查疑难问题时可以临时把级别调到debug能看到每个请求的详细匹配过程定位location规则问题特别好使。但debug日志量极大排完一定要改回来。第三步看access.log里的状态码。重点关注502、503、504这类5xx以及499——499表示客户端在Nginx等待后端响应时主动断开了连接通常意味着后端处理太慢用户等不及关掉了页面或刷新了。第四步看后端应用日志。Nginx层找不到答案时问题往往在后端。比如后端连接池不够、数据库连接超时、某个接口死锁这些在Nginx的日志里只能看到表象502/504真正的原因还是要回到应用日志里找。我遇到过好几个项目线上隔几天就502一次Nginx日志里偶尔出现upstream timed out最后排查发现是后端数据库连接池满了。如果不看后端日志光调Nginx超时时间永远治标不治本。8. 最后再分享一点部署经验这几年从零搭过的Web环境不下几十套从单台Nginx到多节点集群都折腾过。要说印象最深的教训反而不是那些复杂的负载均衡算法而是最基础的细节配置文件改完有没有-t验证、路径有没有写对、权限有没有给够、防火墙有没有放行。这些小事任何一个出问题线上就是事故。如果你准备给自己的Web项目做网络环境部署我的建议是先照着一台服务器把流程完整走一遍别一上来就上集群。单机版的Nginx 动态后端 HTTPS这套组合能扛住绝大多数中小项目的流量架构简单排障也快。等确实碰到性能瓶颈了再考虑加负载均衡、多节点、缓存分层这些扩展。Nginx的配置其实并不复杂复杂的是你得清楚每一行配置背后的含义以及它会在什么场景下坑你。希望这篇能帮你在部署路上少踩几个我当年踩过的坑。