★ FEATURED ARTICLE 1. 学习Nginx前的目标拆解为什么人人都该啃这块硬骨头Nginx 学习总结拖了很久终于在一堆线上事故的催促下啃完了。早些年我一直觉得 Nginx 就是个“转发请求的工具”配个静态站点、挂个反向代理就算完事。直到某天接口超时、后端服务挂了打开配置文件才发现连 upstream 的 keepalive 都没配才意识到自己从来没真正理解过 Nginx。如果你也是开发或者运维Nginx 可能是你绕不开的坎。它既是 Web 服务器又是反向代理、负载均衡器、缓存层甚至能做安全防护。大部分同学学习 Nginx 最容易掉进的坑就是只搜代码片段复制粘贴一遍能跑就觉得会了。可一旦遇到跨域、WebSocket 断连、502 反复横跳、日志突然不写了这类问题就开始抓瞎。这篇文章不打算逐条翻译官方文档而是按照我自己的踩坑路径把 Nginx 里最核心的“为什么”讲清楚同时给你一套可以直接抄作业的配置思路。适合谁看对 Nginx 有一定了解但没系统性梳理过的人尤其是想搞懂 location 匹配规则、upstream 负载策略、worker 进程模型这些底层逻辑的新手。也适合面试前突击把关键概念串一遍。整个学习过程不需要你背命令重点是把“它怎么工作”想明白剩下的一切自然就顺了。2. 核心功能与基础架构从一张请求处理流程图说起2.1 Nginx 到底是干什么的一台服务器顶多个角色我们先站在高处看一眼 Nginx 的核心功能。它最出名的特性是“高性能高并发”但高性能从来不是凭空来的而是来自于它的事件驱动架构。传统的 Apache 每个连接会占用一个进程或线程连接一多内存就爆。Nginx 则采用异步非阻塞方式一个 worker 进程可以同时处理成千上万个连接这一点是理解之后所有调优的基础。Nginx 实际工作中你离不开这几个角色静态资源服务器直接服务 HTML、CSS、JS、图片配合sendfile、gzip能极大提升静态资源响应速度。反向代理服务器接收客户端请求转发到后端应用如 Java 的 Tomcat、Node.js 服务再把响应返回给客户端。负载均衡器通过upstream把请求分发到多台后端服务器实现水平扩展和高可用。API 网关基于 Nginx 做请求路由、流量控制、鉴权、灰度发布。安全代理层隐藏后端真实 IP过滤恶意请求防御基础的 DDoS 攻击SSL 终端。这五个角色不是互相排斥的一份 Nginx 配置可以同时承担多个角色。比如一个server块中同时配置静态文件别名和/api/反向代理这也就是后来大家常说的“动静分离”。2.2 配置文件的核心骨架events、http、server、location 的四层关系学习 Nginx 的第一道坎就是配置文件。默认的nginx.conf结构不复杂但很多人上来就四处塞配置结果冲突了也不知道从哪查起。Nginx 的配置逻辑是“块嵌套”的最核心的四层关系大概是这样的events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; upstream backend { server 127.0.0.1:8080; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; } location /static/ { alias /var/www/static/; } } }events块设置连接处理相关的全局参数比如worker_connections。http块HTTP 协议的全局配置MIME 类型、日志格式、超时时间以及所有server的父容器。server块相当于一个虚拟主机监听某个端口定义域名和路由规则。location块定义 URL 路径匹配规则是 Nginx 配置中最灵活也最容易出错的部分。理解这个嵌套关系后大部分配置问题都能定位到具体块。比如你想做接口超时设置肯定放在location或server里的proxy_read_timeout而不是放在events里。2.3 事件驱动架构与 worker 进程模型为什么 Nginx 能扛高并发Nginx 启动时会创建 1 个 master 进程和 N 个 worker 进程。master 负责读取配置文件、管理 worker 生命周期、平滑 reloadworker 才真正负责处理连接和请求。每个 worker 内部使用事件循环来处理所有连接。Linux 下基于 epoll 模型一个 worker 可以同时监听很多 socket。当某个请求到达时worker 不是阻塞等待响应而是继续处理其他请求等数据可读或可写时再回来处理。这就是异步非阻塞 I/O 的核心思想。可以类比成咖啡店点单传统方式是每个顾客派一个店员全程等待Apache而 Nginx 的方式是只有一个店员记下所有顾客的需求按顺序轮询处理谁需要咖啡就递过去。店员数量少但效率极高。所以 Nginx 调优的核心不在进程数量上堆而在于找到 CPU 核数与 worker 数的平衡以及给每个 worker 足够的连接额度。3. 虚拟主机与 location 匹配规则最容易被忽视的高频踩坑点3.1 server_name 匹配优先级精确匹配 通配符 正则当你在一台机器上部署多个域名时server_name的匹配规则必须搞清楚。Nginx 收到请求后会先根据端口找到对应的server块然后根据Host头去匹配server_name匹配顺序是精确匹配example.com前缀通配匹配*.example.com后缀通配匹配example.*正则表达式匹配~^www\d\.example\.com$默认 server如果没有匹配到这个顺序最容易踩的坑就是你以为正则写在前面就会被匹配实际上 Nginx 会先尝试所有精确匹配才考虑正则。我当初把正则写在了精确匹配上面结果一直失效后来查文档才发现规则。所以在配置多域名时建议先做好域名规划精确域名尽量写全不要依赖默认。3.2 location 前缀匹配的陷阱/与/api的不可控重叠location的规则比server_name更复杂这里多说几句。常见的 location 匹配规则有精确匹配如location /login^~前缀匹配且不再继续检查正则~/~*正则匹配~*不区分大小写普通前缀匹配如location /apiNginx 的匹配顺序是先检查所有前缀匹配记住最长的那一个如果最长前缀命中了^~直接结束否则继续检查正则正则命中则采用正则正则不命中则使用此前最长前缀。你会觉得绕实际上最典型的坑就是location /api { proxy_pass http://backend; } location / { proxy_pass http://other; }如果请求是/api/user第一个location /api的长度是 4第二个/的长度是 1Nginx 会选更长的/api这没错。但如果你写了location /api/而请求是/api/user开头没有斜杠其实有一般来说没问题。更大的坑在于前缀匹配不会自动加边界/api会匹配/api2这样的路径。所以推荐写法是location ^~ /api/ { proxy_pass http://backend; }加^~表示一旦前缀匹配上就不再继续找正则同时尽量把路径写成/api/这种带斜杠形式规避误匹配。3.3 alias 与 root 的混淆文件路径 404 的常见元凶我在配置静态资源时好几次被root和alias搞晕。基本区别是root /var/www/html;结合location /static/时实际访问路径是/var/www/html/static/xxx。alias /var/www/static/;结合location /static/时实际访问路径是/var/www/static/xxxLocation 前缀会被替换掉。如果你把二者混用最常见的结果就是文件 404。比较简单的记忆方式root会“拼接”完整的 URL 路径alias则是“替换”掉 location 前缀。优先用root只有在需要改变映射目录时用alias。另外alias后面建议带尾斜杠避免文件路径拼接错误。4. 反向代理与负载均衡实操从入门配置到生产级调优4.1 一个最小可用反向代理配置的逐行解读反向代理是 Nginx 最核心的场景之一。最小配置长这样server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:8080; 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; } }这里的每个头都有它的用处。Host必须保留否则后端不认识访问的是哪个域名X-Real-IP和X-Forwarded-For用来传递客户端真实 IP不然后端只能看到 Nginx 的内网 IP日志和风控就废了X-Forwarded-Proto则让后端知道客户端是 HTTP 还是 HTTPS。我见过不少新手只配proxy_pass其他啥都不写。结果后端统计用户来源时全成了 127.0.0.1排查半天才发现是 Nginx 没有转发真实 IP。4.2 upstream 负载均衡的四种策略轮询、权重、IP_HASH、最少连接upstream是负载均衡的核心。先看一段完整配置upstream backend_pool { server 192.168.1.10:8080 weight2; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; keepalive 32; } server { location /api/ { proxy_pass http://backend_pool; } }默认策略是轮询每个请求依次分发到不同后端。weight2表示权重为 2即该服务器承担的请求量是权重 1 的两倍适用于性能不同的机器。backup表示备用服务器其他服务器都挂了才轮到它。ip_hash根据客户端 IP 哈希结果固定分发解决 session 不共享的问题但会导致单机压力集中。least_conn优先分发给连接数最少的后端适合长连接请求。我的建议是如果后端没有特殊状态需求优先用轮询 权重如果有登录态且没有集中式 session再考虑 ip_hash 或使用 Redis 共享 session如果后端处理时间差异大least_conn 的表现会更均衡。4.3 健康检查与失败重试机制为什么 502 一直没有消失Nginx 默认对后端没有主动健康检查只是发现连接失败才把请求转给别的机器。这会导致一个问题某台后端进程僵死但端口还在监听Nginx 依然会把请求打过去然后超时。常用的被动健康参数upstream backend_pool { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; }含义是在 30 秒内失败 3 次就把该服务器标记为不可用30 秒后再尝试恢复。这里的“失败”通常指 Nginx 连接后端失败或超时。如果你使用的 Nginx 版本支持商业版的主动健康检查也可以通过 nginx 的第三方模块实现但更常见的做法是用proxy_next_upstream控制重试。例如location /api/ { proxy_next_upstream error timeout http_502 http_503; }表示后端返回 502/503 或连接错误/超时时自动换下一台上游。这个策略能明显减少用户感知到的故障但要谨慎使用因为如果后端已经处理了请求但响应时连接断开重试可能导致重复写库。4.4 长连接与 keepalive 参数后端性能提升 30% 的小细节很多人忽略了upstream里keepalive参数它表示每个 worker 进程与后端保持的最大空闲长连接数。不配置的话Nginx 与后端的每次请求都会重新建 TCP 连接握手开销巨大。配置方法upstream backend_pool { server 127.0.0.1:8080; keepalive 32; } server { location /api/ { proxy_http_version 1.1; proxy_set_header Connection ; proxy_pass http://backend_pool; } }注意必须把proxy_http_version设为 1.1并且清空Connection头否则 keepalive 可能不生效。我曾在某次压测中发现加上 keepalive 之后QPS 从 2000 提到了 2600虽然和业务有关但说明连接复用带来的收益非常明显。如果你后端是短连接模型或容器快速扩容场景这个参数更要重视。5. 性能调优与安全加固生产环境不容妥协的细节5.1 worker 进程数与连接数不是越多越好配置调优第一步是worker_processes。它表示启动多少个 worker 进程一般设置为 CPU 核心数。可以用lscpu查看核数或者让 Nginx 自动检测worker_processes auto;worker_connections是每个 worker 能同时打开的最大连接数默认 1024。最大并发连接数计算公式是worker_processes * worker_connections但还要考虑反向代理时业务连接会占两个客户端到 Nginx 一个Nginx 到后端一个。一般建议按内存大小调整worker_rlimit_nofile 65535; events { worker_connections 4096; use epoll; }worker_rlimit_nofile表示每个 worker 能打开的文件句柄上限不调大的话即使worker_connections配大了也可能被系统限制。use epoll在 Linux 下是默认的写上也图个明白。这里必须提醒不要盲目把worker_connections调成 65535因为每个连接都会占用内存过大反而导致内存不足Nginx 启动都起不来。调优是一个压测、观察、逐步调整的过程。5.2 传输层优化sendfile、tcp_nopush、tcp_nodelay 的关系在http块中经常看到这几个指令它们合在一起可以提升静态文件和大响应体的传输性能sendfile on; tcp_nopush on; tcp_nodelay on;sendfile on让 Nginx 直接通过内核的 sendfile 系统调用发送文件不再把文件从磁盘读到用户态再写出去减少了数据拷贝。tcp_nopush on在 sendfile 开启时有效会把响应头和数据包攒到一起发送减少网络包数量适合大文件传输。tcp_nodelay on关闭 Nagle 算法让 TCP 不等待捎带确认减少延迟适合交互式请求。很多人以为这三个是同一个意思其实tcp_nopush和tcp_nodelay是相互矛盾的一个攒包一个立刻发。好在 Nginx 内部做了适配当tcp_nodelay on时tcp_nopush只在发送大文件时生效。我的经验是全部打开实测对性能没有坏处。5.3 Gzip 与缓存策略静态资源响应速度的最后一公里接口慢可以加缓存静态资源更得加。先看 Gzipgzip on; gzip_min_length 1k; gzip_comp_level 5; gzip_types text/plain text/css text/javascript application/json application/javascript; gzip_vary on;gzip_min_length设置小于 1KB 的文件不压缩因为压缩对太小的文件没有收益。gzip_comp_level一般 5 左右就够太高压缩耗 CPU收益很小。记得gzip_vary on否则某些缓存服务可能不支持 Vary 头导致缓存错乱。对于静态资源的浏览器缓存Nginx 里可以简单配置location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 7d; add_header Cache-Control public, no-transform; }expires 7d会在响应头生成Cache-Control: max-age604800浏览器就会在本地缓存。但这套逻辑对index.html这类入口文件要格外小心不能设置长缓存否则发版后用户还访问旧的首页建议设置no-cache或者极短过期时间。5.4 安全加固清单隐藏版本号、限制请求体、防任意文件读取安全是生产环境必须考虑的一环。下面列几个我实际用过的配置项不大而全但都是高频需求。隐藏版本号避免泄露 Nginx 具体版本server_tokens off;限制请求体大小防止上传导致内存打满client_max_body_size 10m;限制请求方法只允许需要的if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; }但要谨慎使用ifNginx 官方文档说if是“rewrite 上下文”的指令在 location 中不当使用可能造成意想不到的行为。更稳妥的办法是用limit_exceptlocation /api/ { limit_except GET POST { deny all; } proxy_pass http://backend_pool; }防止/etc/passwd这类敏感文件被读取location ~ \.(ini|sh|conf|log|bak|sql)$ { deny all; }这些规则越多越要注意优先级和冲突。写完配置后建议执行nginx -t验证确保语法正确再 reload。5.5 SSL 配置与 HTTP/2从明文裸奔到 HTTPS 的一步到位如果还没有配置 HTTPS建议尽早提上日程。Nginx 中 SSL 的最小配置server { listen 443 ssl http2; 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 HIGH:!aNULL:!MD5; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; }listen 443 ssl http2;表示同时开启 SSL 和 HTTP/2 协议。HTTP/2 支持多路复用、二进制分帧、头部压缩能明显降低多个并发请求时的延迟。ssl_session_cache用于缓存会话密钥减少重复握手开销在连接多的场景非常有用。另外Nginx 不会自动把 HTTP 请求跳到 HTTPS通常需要在 80 端口的 server 中做跳转server { listen 80; server_name example.com; return 301 https://$host$request_uri; }这块踩坑比较多的就是证书续期。建议用自动续期工具并写一个reload动作否则新证书不会自动生效。6. 日志配置与常见问题排查让问题不再靠猜6.1 access log 与 error log 的正确打开方式Nginx 排障第一步永远是看日志。默认日志在/var/log/nginx/access.log和/var/log/nginx/error.log但实际项目中强烈建议按域名分文件不然排查多站点问题非常痛苦。自定义日志格式log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $request_time $upstream_response_time; access_log /var/log/nginx/example.access.log main; error_log /var/log/nginx/example.error.log warn;$request_time是 Nginx 处理请求的总耗时$upstream_response_time是后端响应耗时。两者一对比你就能判断瓶颈是在 Nginx 本身还是后端服务。比如$request_time很大但$upstream_response_time很小说明 Nginx 层有排队反之则是后端慢。还有个小技巧access_log off;可以关闭不需要的站点日志减少磁盘 I/O只保留error_log。但生产环境建议还是开全量日志最好把日志接入集中式收集系统方便排查。6.2 高频故障一览404、502、504、权限拒绝整理一个我自己整理过的排查速查表基本上覆盖了 80% 的日常故障现象常见原因排查方向404 Not Foundroot/alias 配置错误或 location 匹配不符合预期nginx -T查看实际配置直接 curl 请求后端验证502 Bad Gateway后端未启动、连不上、或者 connect timeout 失败检查后端端口监听telnet 测试看 error.log 里的 upstream 信息504 Gateway Timeout后端处理超时proxy_read_timeout 太短确认后端口响应耗时适当调大proxy_read_timeout403 Forbidden无权限、被 deny 规则拦截、索引文件不存在检查autoindex、目录权限、location 中的 deny 规则请求体过大 413client_max_body_size 太小按业务需求调整该参数注意作用于 server 层连接被重置keepalive 设置冲突、防火墙干预检查 proxy_http_version 和 Connection 头抓包确认我印象最深的一次 502 事故后端服务端口在监听curl 也能通但 Nginx 一直报 502。后来查看 error.log 发现是connect() failed (111: Connection refused)再排查才发现后端绑定的 IP 不是 127.0.0.1而是只监听了内网 IP 的另一个地址。所以排查时不能只看端口要看监听地址和 Nginxproxy_pass里写的地址是否完全一致。6.3 reload 与热更新为什么改了配置但不生效修改配置文件后很多人直接nginx -s reload。reload 会让 master 进程重新加载配置然后启动新的 worker旧 worker 处理完现有连接后退出这是无缝热更新。但如果你改了listen等一些涉及 socket 的配置reload 可能失败或者出现端口冲突。几个常用命令nginx -t # 检查配置语法 nginx -s reload # 平滑重载配置 nginx -s stop # 快速停止 nginx -s quit # 优雅停止处理完现有请求再退出 nginx -T # 输出完整有效配置大括号展开后非常好用如果改了配置后不生效先执行nginx -T检查实际加载的配置是否符合预期。有时候你改的是/etc/nginx/conf.d/下的文件但实际主配置 include 的是/etc/nginx/sites-enabled/两边文件同名后加载的覆盖了前面的。这种情况用nginx -T一眼就能看出来。6.4 使用 Access Log 定位恶意请求与流量异常生产环境时不时会有爬虫、扫描器、重复刷接口的请求。虽然 Nginx 不适合做复杂防火墙但基础拦截是可以的。比如禁止某个 UAif ($http_user_agent ~* (curl|wget|python-requests)) { return 403; }以及限制单个 IP 的并发连接数limit_conn_zone $binary_remote_addr zoneperip:10m; limit_conn perip 20;还有连接速率限制limit_req_zone $binary_remote_addr zoneapi_limit:10m rate10r/s; location /api/ { limit_req zoneapi_limit burst20 nodelay; }rate10r/s表示每秒允许 10 个请求burst20表示允许瞬时 20 个请求排队nodelay表示排队时不延迟这能在限流的同时保证突发流量不被直接拒绝。这块需要经过压测再确定具体数值否则容易误伤正常用户。7. 学习过程中的几个核心心智模型与实操心得7.1 把 Nginx 的配置当成“管道”而不是“配置文件”学完整个 Nginx我最大的体会是不要把 Nginx 配置理解成一段静态文本而要把每个请求想象成流经一组管道。从listen进入经过server_name分流到location匹配再到proxy_pass或者root指向文件最后通过gzip、expires等过滤器返回给用户。理解了这个管道模型你碰到任何新配置都能快速判断它属于哪一阶段该放在哪个块里。比如proxy_set_header属于修改请求头放在location里没问题add_header属于修改响应头虽然也能放在location里但往往放在server中更普适。当你把每个指令按照“请求阶段”归类后整个 Nginx 配置就会显得特别清晰。7.2 小步快跑配置变更必须遵循的流程学习 Nginx 期间我养成了一套习惯每次只改一个目标不要一次塞进一堆参数否则出问题不知道是谁干的。改完必须nginx -t语法检查通过后再 reload。reload 前先备份当前配置出问题能立即回滚。观察 error.log 和 access.log确认没有异常后再继续下一步。涉及线上环境尽量先在一台灰度机器上验证。这套流程看起来简单但能帮你在故障时快速定位。我见过不少人线上用nginx -s stop而不是nginx -s reload结果服务直接中断了一小段时间。记住reload才是热更新stop是止损操作日常几乎用不到。7.3 值得继续深入的方向OpenResty、Lua 扩展与可观测性如果你已经掌握了常规 Nginx 配置下一步可以往两个方向延伸。一个是 OpenResty它把 Lua 嵌入了 Nginx可以在请求的不同阶段执行 Lua 脚本做更灵活的流量编排、限流、鉴权。另一个是可观测性通过vts模块或 Prometheus Exporter 采集 Nginx 指标连接数、请求速率、上游响应时间让 Nginx 的黑盒状态变得透明。从个人经验来看学 Nginx 最大的价值不在于“配通一个场景”而在于建立一套“如何设计高并发系统入口层”的思维。很多业务问题表现得五花八门最后都指向 Nginx 的基础机制。比如跨域问题本质是浏览器的同源策略和 Nginx 的响应头控制WebSocket 掉线本质是代理层的超时和升级头没有做好灰度发布本质是 upstream 里的服务权重调整。最后再分享一个小技巧遇到 Nginx 问题不要急着百度先看error.log再看nginx -T最后用curl -v复现。这三板斧能解决九成问题。如果还不行再去查文档也不迟。就是这样工具本身不难难的是把底层机制吃透后养成的排查直觉。希望这篇 Nginx 学习总结能给你省下几个通宵。
阅读完成 · 觉得有帮助？
