1. 先想清楚 Nginx 在你的架构里该站哪个位置
1.1 从一次流量突增的真实困境说起
去年帮一个朋友的项目做性能复盘，情况很有代表性。他们做的是一个内容型站点，早期架构特别朴素：一台机器上跑应用服务，静态资源（图片、CSS、JS）也塞在同一个进程里，前端页面由应用层动态渲染。日活几千的时候完全没问题，后来被一个活动带了一波流量，问题一次性全爆出来了——图片请求把应用进程的工作线程占满，动态接口响应从 80ms 涨到 3 秒，紧接着超时、重试、雪崩，最后整站不可用。
复盘的时候发现，他们并不是缺机器，而是缺一层"分工"。图片请求根本不需要经过应用逻辑，动态接口也不该和静态文件抢同一个进程的处理能力。这时候 Nginx 就该出场了：它把静态资源接过去，把动态请求反向代理给后端的应用服务，后端有多台机器时再顺手做负载均衡。这三件事就是标题里说的"网站服务"的全部内涵——它不是某一个功能，而是一套请求分层的职责划分。
我把这套东西完整落地了一遍，从配置文件第一行写起，到压测、调参、上线观察，中间踩了不少坑。下面就把整个过程拆开讲，包括每一行配置为什么这么写、参数为什么取这个值、哪些坑是踩过之后才知道的。
1.2 静态托管、反向代理、负载均衡，三件事别混在一起想
很多人一开始就把 Nginx 的配置当成"抄一段能跑就行"，结果后期改动一处崩一片。根源在于没有把三块职责在脑子里分开。
静态资源托管是 Nginx 最原始的能力。它直接读磁盘文件返回，不经过任何应用逻辑，能扛的并发远高于应用服务。这一层的关键在于路径映射、缓存头、压缩策略，以及不要让它去碰本该由后端处理的路径。
反向代理解决的是"外部请求怎么安全地交给内部服务"。它涉及的是一组转发头、超时参数、缓冲策略。这里最容易出错的地方是：代理不是简单的转发，它还要让后端知道真实客户端是谁、请求走的是什么协议、客户端期望的 Host 是什么。这些信息丢了，后端的日志、限流、鉴权、跳转全都会出问题。
负载均衡是反向代理的延伸。当后端从一台变多台，就需要一套调度策略和故障摘除机制。这一层的难点不在配置本身，而在于"故障判定"——什么时候认为一台后端挂了、挂多久、挂了之后请求怎么分配。
把这三层分清楚之后，配置文件的结构自然就出来了：http块里定义通用的日志、压缩、超时；upstream块定义后端集群；server块按域名和端口分流；location块按路径决定走静态还是走代理。每一层各管一摊，改一处不至于影响全局。
1.3 同类方案横向对比：为什么最后还是选了它
选型阶段我把几个常见方案都过了一遍，这里把结论整理成表，方便你按自己的场景对号入座。
| 方案 | 擅长的事 | 短板 | 适合的场景 |
|---|---|---|---|
| Nginx | 静态资源、反向代理、负载均衡、TLS 终结一体化 | 动态脚本处理能力弱，模块需编译 | 绝大多数 Web 站点的入口层 |
| 传统多进程 Web 服务 | 与应用同语言、生态打通 | 高并发下内存占用高，静态资源效率一般 | 中小流量、以动态页面为主 |
| 专业四层/七层代理 | 纯转发性能强、健康检查丰富 | 静态资源、缓存、压缩要另配 | 纯流量入口、微服务网关 |
| 云厂商负载均衡 | 免运维、弹性扩容 | 成本随流量线性增长，策略定制受限 | 流量波动大、团队无运维人力 |
对一个自建、流量中等、需要精细控制缓存的站点来说，Nginx 的优势在于"一层搞定四件事"：TLS 终结、静态资源、反向代理、负载均衡都在同一个进程里，不用在多个组件之间来回跳。代价是它的配置语法偏底层，参数需要自己算，不能指望默认值。
注意：选型不要只看性能数字。真正决定长期成本的是"出问题时你能不能快速定位"。Nginx 的错误日志和 access 日志格式可以完全自定义，这一点在后期的价值远超那点性能差异。
2. 静态站点托管与 HTTPS 落地：先把地基打稳
2.1 root 与 alias 的差别，能坑掉一整个下午
root和alias这两个指令长得像，行为完全不同，我见过至少三个项目在这上面翻车。
root的语义是"把 location 匹配到的完整路径拼在指定目录后面"。比如：
location /static/ { root /data/www; }请求/static/logo.png，实际读取的是/data/www/static/logo.png。注意static这一层目录还在。
alias的语义是"用指定目录替换掉 location 匹配的部分"：
location /static/ { alias /data/www/assets/; }同样请求/static/logo.png，实际读取/data/www/assets/logo.png，static这一层被替换掉了。
两者最容易出错的地方是结尾斜杠。用alias时，location 以/结尾，alias 的目标路径也必须以/结尾，否则路径会拼错。用root时则没有这个要求。我的习惯是：静态目录结构规整、和 URL 路径能对上的，一律用root；URL 路径和磁盘目录刻意解耦的（比如把/img/映射到/data/uploads/2024/），才用alias，并且在注释里写清楚映射关系。
2.2 location 匹配优先级：写错顺序等于白写
Nginx 的 location 匹配有一套明确的优先级规则，不搞清楚就会出现"我明明写了这条规则，为什么没生效"。
规则从高到低大致是：=精确匹配 >^~前缀匹配且不再检查正则 > 正则匹配（按配置中出现的顺序，第一个匹配的生效）> 普通前缀匹配（取最长的那条）。
我实际项目里常用的组合是这样：
# 精确匹配，只处理这一个路径 location = /health { return 200 "ok"; } # 前缀匹配且跳过正则，静态目录专用 location ^~ /static/ { root /data/www; expires 30d; } # 正则匹配，处理图片后缀 location ~* \.(jpg|jpeg|png|webp|gif|svg)$ { root /data/www/uploads; expires 7d; } # 兜底，所有动态请求走代理 location / { proxy_pass http://app_backend; }这里有个细节值得说：^~的意义在于"一旦这条前缀匹配上了，就不要再拿正则去试"。为什么需要它？因为如果你有一条~* \.(png)$的正则规则，而静态目录里恰好有.png文件，不加^~的话，请求会被正则规则抢走，走到错误的 root 目录去。这个坑我在一次图片 404 排查里花了两个小时才定位到。
另外，location /放最后不是强制的，但把最宽泛的规则写在最后，读起来最顺，维护成本最低。
2.3 证书链和协议版本，比想象中更容易配错
HTTPS 配置本身的语法不复杂：
server { listen 443 ssl; http2 on; server_name example.internal; ssl_certificate /etc/nginx/certs/site.fullchain.pem; ssl_certificate_key /etc/nginx/certs/site.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1h; }真正容易出问题的是证书文件本身。ssl_certificate指向的文件必须是"服务器证书 + 中间证书"拼在一起的完整链，只放服务器证书的话，部分客户端会因为找不到中间证书而校验失败。判断方法很简单：用openssl s_client -connect host:443 -servername example.internal连一下，看返回的证书链里有几段。只有一段就是缺中间证书。
ssl_session_cache shared:SSL:10m这个值也值得算一下。共享内存里大约每 1MB 能存 4000 个会话，10MB 就是 4 万个，对一个中等流量站点够用。会话复用的意义在于省掉完整握手的往返，对移动端弱网用户体感提升明显。
ssl_prefer_server_ciphers off是刻意的选择：现代客户端（尤其 TLS 1.3）的密码套件排序通常比服务端更合理，交给客户端挑反而更快。这个和很多老教程里的写法相反，但实测下来握手时间确实更短。
2.4 缓存头与压缩：让回源请求少一半
静态资源的性能优化，一半靠缓存头，一半靠压缩。缓存头的写法要和文件名策略配套：
location ^~ /static/ { root /data/www; expires 365d; add_header Cache-Control "public, immutable"; }immutable这个指令的含义是"这个资源在有效期内绝对不会变，浏览器不用再发条件请求验证"。它的前提是文件名带内容哈希，比如app.3f9a2c.js。构建产物一变，文件名就变，旧文件的 URL 自然没人访问，所以可以放心设长缓存。
反过来，index.html这种入口文件绝对不能设长缓存，否则用户拿到的永远是旧版本，新资源加载不出来。我的做法是给 HTML 单独一条规则：
location ~* \.html$ { root /data/www; add_header Cache-Control "no-cache"; }压缩这块，只压文本类资源，别去压图片和字体（它们本身已经是压缩格式，再压只会浪费 CPU）：
gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_vary on; gzip_types text/plain text/css application/javascript application/json image/svg+xml;gzip_comp_level取 5 是我反复权衡的结果。1 到 9 里，5 的压缩率已经接近 6 到 7 的水平，但 CPU 开销明显更低。取 9 的话，压缩率可能只多 1% 到 2%，CPU 却要多吃一大截，在流量高峰期很不划算。gzip_min_length 1k是为了避免小文件压缩后反而变大——HTTP 响应头的额外开销可能超过压缩收益。
提示：如果前端构建时已经生成了
.gz文件，可以开gzip_static on;，Nginx 会优先返回预压缩文件，连压缩的 CPU 都省了。这个模块需要编译时带上，先确认一下。
3. 反向代理：那些默认配置不会告诉你的细节
3.1 一段最小可用配置，逐行拆开看
先看一段我在多个项目里复用的基础配置：
upstream app_backend { server 10.0.1.11:8080 max_fails=3 fail_timeout=10s; server 10.0.1.12:8080 max_fails=3 fail_timeout=10s; keepalive 32; } server { listen 80; server_name example.internal; location / { proxy_pass http://app_backend; proxy_http_version 1.1; proxy_set_header Connection ""; 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_503 http_504; proxy_next_upstream_tries 2; } }proxy_pass http://app_backend后面不带路径，意味着把原始请求 URI 原样转发给后端。如果写成proxy_pass http://app_backend/api/，Nginx 会把 location 匹配到的部分替换成/api/再转发。这个差异导致的接口 404 我见过太多次，记住一句话：带路径就是重写，不带路径就是透传。
proxy_http_version 1.1配合proxy_set_header Connection ""是开启长连接的必要条件。默认是 HTTP/1.0 且带Connection: close，每次请求都要新建 TCP 连接，后端连接数会非常高。清空Connection头之后，配合upstream里的keepalive 32，Nginx 会维护一个到每台后端的连接池，复用连接。
keepalive 32这个数字怎么定？它表示每台后端最多保留的空闲连接数，不是并发上限。经验值是单个后端并发峰值的 1/4 到 1/2，取 32 到 64 覆盖大部分场景。设太大只会占内存，收益递减。
3.2 四个转发头，少一个都可能出事
上面配置里的四个proxy_set_header，每一个都对应一类真实故障。
Host $host决定后端看到的 Host 是什么。不设的话，Nginx 默认传的是proxy_pass里的主机名（也就是app_backend），后端的路由、绝对 URL 拼接、跨域判断全都会错。
X-Real-IP $remote_addr传的是直连客户端 IP。注意$remote_addr是 TCP 层的对端地址，如果 Nginx 前面还有一层代理，这里拿到的是那层代理的 IP，需要在前面用set_real_ip_from和real_ip_header做还原。
X-Forwarded-For $proxy_add_x_forwarded_for是一个追加而非覆盖的头。它的行为是"取请求里已有的 XFF，末尾追加当前$remote_addr"。这样后端能拿到完整的链路，但要注意：这个头可以被客户端伪造，如果用它做 IP 白名单或限流，必须从右往左取可信的那一段，不能直接取第一个。
X-Forwarded-Proto $scheme告诉后端原始请求是 HTTP 还是 HTTPS。这个头丢了，后端生成的跳转链接、Cookie 的Secure属性、回调地址全都会变成 http，用户就会被反复跳转或者登录态失效。这个问题在"加了 HTTPS 之后登录一直掉"的排查里出现过很多次。
注意：如果后端框架依赖
X-Forwarded-Prefix或者类似的路径前缀头，也要一起设。应用部署在子路径下时，缺这个头会导致生成的静态资源链接全部 404。
3.3 超时参数的取值逻辑：不是随便填个 60
三个超时参数的语义要分清：
proxy_connect_timeout是与后端建立 TCP 连接的超时。内网环境通常几毫秒就完成，设 5s 已经非常宽松。设太大没有意义——如果 5 秒还连不上，后端大概率是真的出问题了，早点失败早点重试反而更好。
proxy_send_timeout是向后端发送请求体的超时。它约束的是两次写操作之间的间隔，不是整个请求的总时长。有大文件上传接口的话要考虑调大。
proxy_read_timeout是等待后端响应的超时，从连接建立（或上次读成功）开始算，到收到数据为止。这个参数最容易设错。我见过一个报表导出接口，后端要跑 90 秒，但 Nginx 默认 60s，结果每次都返回 504。当时的处理不是无脑把它调到 300s，而是分路径设置：
location /api/report/export { proxy_pass http://app_backend; proxy_read_timeout 180s; proxy_buffering off; } location /api/ { proxy_pass http://app_backend; proxy_read_timeout 30s; }为什么全局只给 30s？因为绝大多数接口都该在 30 秒内返回，一旦超过说明有问题，早点断开能让上游的限流和告警更早触发。只有明确知道会慢的接口才单独放宽。用全局大超时去盖所有问题，等于把所有慢查询都藏起来了。
proxy_buffering off出现在导出接口上是有原因的：导出通常是流式输出，如果开启缓冲，Nginx 会先把整个响应攒在内存或临时文件里再发给客户端，大文件会撑爆proxy_buffers并落盘。关掉缓冲让数据边生成边下发，内存稳、首字节也更快。
3.4 WebSocket 与长连接场景，别照抄普通代理配置
普通 HTTP 代理配置直接套到 WebSocket 上是不通的，连接会在握手阶段断掉。原因在于 WebSocket 依赖Upgrade和Connection头，而这两个头默认不会被转发。
location /ws/ { proxy_pass http://app_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }$connection_upgrade不是内置变量，需要在http块里用map定义：
map $http_upgrade $connection_upgrade { default upgrade; '' close; }这个map的作用是：如果客户端带了Upgrade头，就传upgrade；没带就传close，让普通请求正常关闭连接。比写死Connection "upgrade"要稳妥，因为写死会让所有走这条 location 的普通请求也带上 upgrade 语义。
超时设 3600s 是因为 WebSocket 是长连接，空闲但不断开是常态。如果沿用 60s，用户静置一分钟连接就断了，前端要不停重连，体验和日志都很糟糕。更稳妥的做法是让应用层定期发心跳，Nginx 侧只做兜底的超时保护。
3.5 请求体大小与缓冲，两个容易被忽略的隐形限制
client_max_body_size默认只有 1MB。这个默认值在文件上传场景下就是灾难，用户传一张手机原图就报 413。按业务定：
location /api/upload { client_max_body_size 50m; client_body_buffer_size 256k; proxy_pass http://app_backend; }client_body_buffer_size控制的是内存里能缓冲多少请求体，超过这个量就写临时文件。默认值通常只有 8k 或 16k，意味着 50MB 的上传会产生大量临时文件读写。调到 256k 到 1m 之间能覆盖大部分图片上传，既省磁盘 IO 又不至于把内存吃光。
代理侧的缓冲也要一起看：
proxy_buffer_size 32k; proxy_buffers 8 16k; proxy_busy_buffers_size 64k;proxy_buffer_size只需要装响应头，32k 足够覆盖绝大多数场景（包括很长的 Cookie 和多重跳转头）。proxy_buffers 8 16k是最多 8 个、每个 16k 的缓冲块，总量 128k。后端响应特别大的时候，超出部分会落盘到proxy_temp_path。如果磁盘 IO 成为瓶颈，或者你压根不想落盘，可以设proxy_max_temp_file_size 0;让它直接透传给客户端。
4. 负载均衡：算法选错，扩容等于白扩
4.1 四种调度算法，各自解决什么问题
upstream里不写least_conn、ip_hash这类指令，默认就是轮询（带权重的加权轮询）。四种常用算法我整理成表：
| 算法 | 指令 | 适用前提 | 不适用的情况 |
|---|---|---|---|
| 加权轮询 | 默认 | 后端性能接近，请求耗时均匀 | 有长请求、耗时差异大 |
| 最少连接 | least_conn | 请求耗时差异大、长连接多 | 请求都极快且均匀 |
| IP 哈希 | ip_hash | 需要按客户端粘性会话 | 客户端集中在少数出口 IP |
| 一致性哈希 | hash $key consistent | 需要按任意维度（用户、租户）粘性 | 后端节点频繁增减 |
为什么有长请求时要选least_conn？轮询是"按顺序发"，它假设每个请求消耗的资源差不多。但现实里一个导出请求可能占住后端线程 30 秒，这 30 秒里轮询还会继续往这台机器上发新请求，很快就堆积起来了。least_conn会优先发给当前连接数最少的节点，天然能把慢请求的影响摊开。
ip_hash的坑在于它只看客户端 IP 的前三段（IPv4）。如果大量用户走同一个出口（比如某些办公网络、运营商网关），这些用户会全部落在同一台后端上，均衡彻底失效，这台机器被打爆，其它机器闲着。所以用它之前一定要确认你的用户 IP 分布是分散的。
一致性哈希更适合"按业务维度粘性"的场景，比如多租户系统想按租户 ID 落节点，方便做本地缓存：
upstream app_backend { hash $arg_tenant_id consistent; server 10.0.1.11:8080; server 10.0.1.12:8080; server 10.0.1.13:8080; }consistent关键字的意义在于：节点增减时只影响相邻的一段哈希环，而不是全部重新洗牌。三节点扩到四节点时，普通取模哈希会导致几乎全部缓存失效，一致性哈希通常只影响 1/3 左右。
4.2 权重怎么算：一个具体的扩容推算
混部不同规格的机器很常见，权重必须按实际处理能力算，不能凭感觉。
假设原集群有两台 4 核 8G 的机器，各自扛 1000 QPS，权重都是默认的 1。现在新加一台 8 核 16G 的机器，实测能扛 2200 QPS。权重应该怎么给？
按"能力比值"来：以 4 核机器的 1000 QPS 为一个单位，新机器的权重就是 2200 / 1000 ≈ 2.2，取整数 2 或者调成 22:22:11 的比例。Nginx 的权重支持大整数，直接用比例更精确：
upstream app_backend { least_conn; server 10.0.1.11:8080 weight=5; server 10.0.1.12:8080 weight=5; server 10.0.1.13:8080 weight=11; }这里总量是 21，理论上新机器会接到约 52% 的流量，两台老机器各 24%。上线后要观察实际分布，如果偏差超过 10%，说明"实测 QPS"这个数不准，或者least_conn在起作用（它会在权重基础上再按连接数调整）。
注意：权重算完之后一定要看后端监控的实际负载，而不是只看 Nginx 的分发比例。因为响应慢的节点连接会堆积，
least_conn会自动少发给它，最终的实际流量分布和权重会不一样，这恰恰是它该做的事。
4.3 被动健康检查：参数背后的判定逻辑
开源版 Nginx 只有被动健康检查，也就是"靠真实请求的失败来发现故障"，没有定时探测。这决定了参数要谨慎设置。
upstream app_backend { server 10.0.1.11:8080 max_fails=3 fail_timeout=10s; server 10.0.1.12:8080 max_fails=3 fail_timeout=10s; }max_fails=3的含义是：在fail_timeout这个时间窗口内，如果失败了 3 次，就把这台机器标记为不可用。fail_timeout=10s是双语义的——既作为失败计数的时间窗口，也作为标记不可用之后的冷却时长。10 秒后 Nginx 会放一个请求过去试探，成功就恢复，失败就再等 10 秒。
这套机制有个明显缺陷：故障发现是被动的，靠用户请求来触发。如果流量很小，可能十几分钟都发现不了一台挂掉的后端。所以我一般会配合两件事：一是业务层加一个轻量的健康检查接口，前端轮询时会顺带打到后端；二是把应用监控接上，发现异常主动摘节点，不完全依赖 Nginx。
另一个细节是proxy_next_upstream的触发条件。默认只对error和timeout重试，像 502、503、504 这些"后端明确返回错误"的情况反而不会重试。我通常显式加上：
proxy_next_upstream error timeout http_502 http_503 http_504; proxy_next_upstream_tries 2; proxy_next_upstream_timeout 5s;加http_502这类状态码的意义在于：后端进程还在但内部依赖挂了、返回 502 的时候，能自动换一台试试。但proxy_next_upstream_tries 2必须设，否则遇到全集群都挂的情况，一个请求会在所有节点上挨个试一遍，放大故障。
有个必须避开的坑：非幂等请求不能随便重试。一个 POST 创建订单的请求，后端已经处理成功但响应超时了，Nginx 重试到另一台机器，就会创建两笔订单。所以这条指令要按 location 分别设置，写操作路径上谨慎开启，或者干脆关掉重试，让客户端自己去处理。
4.4 会话保持的三种做法，从最差到最好
后端是有状态的（session 存在本地内存）时，就必须考虑会话粘性。三种做法按推荐度从低到高排：
第一种，ip_hash。配置最简单，但前面说过它的缺陷：出口 IP 集中的用户会全落到一台机器上，均衡失效，而且后端扩缩容时会话会大面积失效。
第二种，一致性哈希按用户标识。比ip_hash精准得多：
upstream app_backend { hash $cookie_session_id consistent; server 10.0.1.11:8080; server 10.0.1.12:8080; }用 Cookie 里的会话标识做哈希，同一个用户的请求稳定落同一台。缺点是如果用户还没登录、Cookie 为空，所有空 Cookie 的请求会全落到同一台，形成热点。需要额外处理空值，比如降级成$remote_addr。
第三种，把会话外置，彻底不依赖粘性。这是我最推荐的做法：session 存到共享存储或做成无状态令牌，任何一台后端都能处理任何请求。这样负载均衡可以放心用least_conn，扩缩容时也不用担心用户掉登录。代价是要改一点应用代码，但这笔投入远比后期处理"扩容后部分用户被踢下线"的工单划算。
我的实际经验是：如果项目还在早期，别上
ip_hash这种省事的方案。它会让你以为"会话问题是解决了"，等到流量上涨、某个出口 IP 打爆一台机器时，你会发现整个架构被这个小决定绑死了。
5. 生产调优：参数不是越大越好，是要算得出来
5.1 并发容量估算：先把上限算清楚
调优的第一步不是改配置，是算出你的目标并发是多少。公式不复杂：
最大并发连接数 ≈ worker_processes × worker_connections
但反向代理场景下这个值要打对折，因为 Nginx 同时维护"客户端连接"和"到后端的连接"两条，一个用户请求占两个连接。所以：
可承载的客户端并发 ≈ worker_processes × worker_connections / 2
假设一台 8 核机器，worker_connections设 10240，那么理论上限是 8 × 10240 / 2 = 40960 个并发客户端。这个数字通常远超实际需要，真正的瓶颈往往在文件描述符和内存。
配置写起来是这样：
worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 10240; multi_accept on; use epoll; }worker_processes auto会自动跟随 CPU 核数，不用手写。worker_rlimit_nofile是给 worker 进程设的文件描述符上限，必须设，否则会撞到系统默认的 1024，一到几千并发就开始报Too many open files。这个值的经验算法是：worker_connections × 2 + 预留，10240 × 2 = 20480，给到 65535 有充足余量。
系统层面的限制也要同步改（这一步经常被漏掉，改完 Nginx 配置发现没生效）：
# /etc/security/limits.conf nginx soft nofile 65535 nginx hard nofile 65535 # 临时验证 ulimit -nmulti_accept on让 worker 一次尽可能多地接受新连接，高并发下能少一些系统调用开销。use epoll在 Linux 上是默认值，写出来只是让配置自解释。
5.2 连接复用与文件 IO：三个开关的实际作用
sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000;sendfile on让静态文件从磁盘到 socket 走内核态零拷贝，跳过用户态缓冲。这是静态资源服务的必开项，收益非常直接。
tcp_nopush on要和sendfile配合看：它让响应头和文件内容尽量凑在一个 TCP 包里发出去，减少包数量。但在需要低延迟的小响应场景下，它可能引入额外等待。
tcp_nodelay on则相反，禁用 Nagle 算法，小包立即发送。这两个看起来矛盾，实际上 Nginx 会自动协调：大文件传输用 nopush 攒包，长连接上的小包用 nodelay 立即发。两个都开是标准做法。
keepalive_timeout 65是客户端连接的空闲保持时间。设太短用户频繁建连，设太长会占住连接数。65 秒是个折中值，略大于常见的浏览器默认 60 秒，避免连接刚好在浏览器复用前被服务端先关掉（这种"竞态关闭"会导致偶发的请求失败，很难排查）。
keepalive_requests 1000是单个长连接上最多处理多少请求。默认 100，对大流量站点偏低，连接频繁重建；设 1000 能显著降低建连开销。但也不能无限大，否则单连接会一直占着 worker 的资源。
5.3 缓冲、限流与超时的联动关系
这三个东西必须一起调，单独调任何一个都可能出问题。
先说限流。limit_req_zone定义在http块，按 IP 或按接口维度限制速率：
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=20r/s; limit_conn_zone $binary_remote_addr zone=conn_limit:10m; location /api/ { limit_req zone=api_limit burst=40 nodelay; limit_conn conn_limit 20; }rate=20r/s是平均速率，burst=40是允许的突发量，nodelay表示突发部分立即处理而不是排队。这里的关键是zone的大小：10m大约能存 16 万个 IP 的状态。如果你的用户 IP 很分散，小于这个值会导致状态被覆盖，限流形同虚设。
limit_req和proxy_read_timeout的关系在于：如果限流把请求排队了，排队时间会算进后端响应时间里。排队太久，客户端可能先超时断开，产生大量 499。所以限流的burst值要和超时时间匹配，不能让请求排队超过客户端的耐心。
再说proxy_buffering。开启时 Nginx 会尽快从后端读完响应，释放后端连接，然后按客户端的消费速度慢慢发。这能显著降低后端连接占用时间。但开启的代价是内存和临时文件的使用，大响应场景要配合proxy_max_temp_file_size控制。
关闭缓冲适合：流式响应（导出、SSE）、响应极小且希望最快首字节的场景。我在实际项目里的默认策略是全局开、按路径关，而不是反过来。
5.4 日志格式：不自定义就等于没监控
默认的 combined 格式只有一个$request和状态码，出问题时基本查不出东西。我的标准格式是这样的：
log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' 'rt=$request_time urt=$upstream_response_time ' 'ua=$upstream_addr us=$upstream_status ' 'host=$host req_id=$request_id'; access_log /var/log/nginx/access.log main buffer=32k flush=5s;几个字段值得单独说。$request_time是 Nginx 从收到请求到发完响应的总耗时，$upstream_response_time是后端处理耗时。两个一减，就知道时间花在网络传输、缓冲还是后端。这个差值我在排查"后端很快但用户很慢"的问题时救过好几次场——最后发现是响应体太大、客户端下载慢。
$upstream_addr记录请求实际打到了哪台后端，做归因分析必备。后端有多台时，这个值可能是逗号分隔的多个（发生了重试），一眼就能看出有没有触发proxy_next_upstream。
buffer=32k flush=5s是把日志先写内存缓冲，满 32k 或每 5 秒落盘一次。高 QPS 下这个配置能把日志写入的 IO 开销降一个数量级。但要注意：进程被强杀时，缓冲区里的日志会丢，对账类场景要评估这个风险。
$request_id是 Nginx 生成的一个唯一标识，配合后端透传这个头，就能把"客户端请求 - Nginx 日志 - 后端日志"串成一条链。做全链路排查时，这个字段的价值无可替代。
5.5 配置校验与平滑发布：别在生产上直接 reload
发布流程我固定成三步，一步都不能省：
# 1. 语法与逻辑检查（不加载进运行进程） nginx -t -c /etc/nginx/nginx.conf # 2. 确认通过后平滑重载 nginx -s reload # 3. 观察错误日志和状态码分布 tail -f /var/log/nginx/error.lognginx -t会解析整个配置文件，检查语法错误、指令是否存在于已编译的模块、引用的文件是否存在。不通过就绝不 reload。
nginx -s reload的行为值得说清楚：它给 master 进程发 SIGHUP，master 检查配置后启动新的 worker，旧 worker 处理完手上的请求后退出。这个过程客户端的连接不会断，是真正的平滑。但如果新配置有严重问题（比如 upstream 地址写错了），新 worker 起来之后才会暴露，所以第三步的日志观察不能少。
二进制升级（换 Nginx 版本本身）走的是另一套流程，用 USR2 信号：
# 用新二进制替换文件后 kill -USR2 $(cat /var/run/nginx.pid) # 新 master 起来，监听同一个端口，需要手动把旧 master 的监听套接字摘掉 # 观察没问题后再退出旧的 kill -QUIT $(cat /var/run/nginx.pid.oldbin)这套流程稍复杂，非必要不在业务高峰做。普通配置变更用reload就足够了。
提示：生产环境建议保留最近三份配置副本，命名带时间戳。出问题时
cp回去再reload，比在编辑器里撤销靠谱得多。我在一次深夜回滚里就是靠这个省了十几分钟。
6. 排查实录：那些日志里看不到答案的问题
6.1 状态码速查表：先把症状对上号
大部分问题看一眼状态码和日志字段就能缩小到一两个方向。我整理了一份自己常用的对照表：
| 状态码 | 常见含义 | 先查什么 |
|---|---|---|
| 499 | 客户端在服务端响应前主动断开 | $request_time是否过长；后端是否慢导致用户放弃 |
| 502 | 后端返回了非法响应或连接被拒 | 后端进程是否存活；$upstream_addr是哪台；协议版本是否匹配 |
| 503 | 无可用后端或超出连接限制 | upstream 是否全被标记不可用；limit_conn是否触发 |
| 504 | 等待后端响应超时 | $upstream_response_time；proxy_read_timeout是否偏小 |
| 413 | 请求体超过client_max_body_size | 上传路径的 body 大小限制 |
| 400 | 请求格式错误 | 是否有代理改了请求头；Host是否异常 |
499 这个码值得单独强调，因为它是 Nginx 特有的（其它服务不一定记录），含义是"客户端跑了"。大量 499 从来不意味着客户端有问题，几乎总是意味着服务端太慢。看$request_time的分布，如果大量请求超过 3 秒，那就是慢接口问题，要往后端查。
6.2 三个真实排查案例，思路比结论重要
案例一：加了 HTTPS 之后登录一直掉。
现象是用户登录成功后刷新一下又变回未登录。查 Cookie 发现Secure属性没有，但站点是 HTTPS，某些浏览器会拒绝这种组合。
根因在后端：后端靠X-Forwarded-Proto判断该不该加Secure，而 Nginx 配置里漏了这一行。后端看到的是 HTTP，就不加 Secure，浏览器拒绝，登录态丢失。
这个案例的启示是：反向代理转发的不只是请求，还有"上下文"。凡是后端用来判断环境的信息（协议、端口、真实 IP、原始 Host），都要显式传过去。
案例二：某个接口偶发 502，压测时必现。
$upstream_addr显示 502 只出现在两台后端中的一台，而且压测时必现。单独用 curl 直连那台后端是正常的。
进一步看错误日志，是upstream prematurely closed connection。最后定位到：那台后端的应用框架在响应体较大时用了分块传输，而 Nginx 侧的proxy_http_version还是默认的 1.0，不支持 chunked 编码。
改成proxy_http_version 1.1后问题消失。这个坑的隐蔽性在于：正常请求都好好的，只有大响应才触发，很容易被当成偶发问题忽略掉。
案例三：扩容后缓存命中率暴跌。
从 3 台后端扩到 4 台，应用层的本地缓存命中率从 85% 掉到 20%，数据库压力瞬间翻倍。
原因很明确：默认的加权轮询在节点数变化时，几乎所有请求的落点都变了，本地缓存全部失效。
改法就是换成一致性哈希，并且按业务主键（比如用户 ID 或租户 ID）做哈希：
upstream app_backend { hash $arg_user_id consistent; server 10.0.1.11:8080; server 10.0.1.12:8080; server 10.0.1.13:8080; server 10.0.1.14:8080; }换完之后扩容只影响了约 1/4 的请求落点，缓存逐步回温。
6.3 一份踩过才写的避坑清单
下面这些条目，每一条背后都有一次不太愉快的经历，列出来供你对照。
改完配置一定要
nginx -t。有次少写一个分号，直接 reload，结果新 worker 起不来，旧 worker 还在跑，表面上服务正常，实际上新配置完全没生效，白等了两小时观察。proxy_pass尾部斜杠会把路径吃掉。转发的接口全部 404 时，先看这一行，比看后端日志快得多。$remote_addr不一定是真实客户端 IP。前面有代理层时，必须用real_ip模块还原，否则限流会把所有用户当成同一个 IP，一刀全切。limit_req的zone设小了会静默失效。状态被覆盖后限流不生效，日志里也不报错，只能靠压测发现。上传路径单独设
client_max_body_size。全局设大值会让所有接口都暴露在大请求下，攻击面变大。Unix socket 不一定比 TCP 快。同机通信时 socket 少一层协议栈开销，但如果 Nginx 和后端在容器里、跨命名空间，反而可能更慢或者连不上。先测再换。
worker_connections调大了要同步改系统限制。只改 Nginx 不改nofile，会在几千并发时报Too many open files，然后被误判成后端问题。日志缓冲会丢最后几秒。排查线上偶发问题时临时关掉
buffer，否则最关键的现场可能刚好在缓冲里没落盘。别在业务高峰做二进制热升级。配置 reload 是安全的，但换二进制文件涉及端口监听权的交接，出问题的恢复成本高得多。
压测环境一定要和后端真实配置一致。我在一台配置偏高的机器上压出漂亮数字，上线后发现生产机器是低配版本，容量估算完全错位。
最后说一个个人习惯：每次改动配置前，我先把当前的
nginx -T（输出完整生效配置）存一份到带时间戳的文件里。出了问题不用靠记忆推断"改之前是什么样"，直接 diff 两份配置，差异一目了然。这个习惯在过去两年里至少帮我省下了十几次翻来覆去的排查时间。
