前置阅读：Nginx-13 实战案例（Go 服务 + Docker）

本篇是整个系列的收尾。前 13 篇每篇末尾都有对应主题的面试题，这里做跨主题的汇总：先给一张速查表用于突击复习，然后是分难度的问答，最后是几道综合设计题和答题框架。

1. 三十秒速查表

面试前扫一遍，能想起答案就跳过，想不起来的回去看对应篇目。

1.1 概念与原理

1.2 配置语义

1.3 代理与负载均衡

1.4 静态、缓存、限流、TLS

1.5 运维与排障

2. 分难度问答

2.1 初级（必须答对）

Q：Nginx 常用命令有哪些？改完配置的标准流程是什么？

nginx -t              # 测试语法
nginx -T              # 测试并打印合并后的完整配置（排查 include）
nginx -V              # 版本 + 编译参数（查模块在不在）
nginx -s reload       # 平滑重载
nginx -s quit         # 优雅停止
nginx -s reopen       # 重开日志（配合 logrotate）

标准流程是改配置 → nginx -t → nginx -s reload。nginx -t 是纪律不是建议：配置语法错误时 reload 会保留旧配置继续跑，服务不挂但你的改动一个字都没生效——这种「静默失败」最浪费排查时间。

Q：nginx -s stop 和 quit 的区别？

stop 发 TERM，立即关闭、中断正在处理的请求；quit 发 QUIT，处理完当前请求再退出。生产下线必须用 quit。

Q：worker_processes 设多少？

auto（= CPU 核心数）。worker 是单线程事件循环，核数就是并行上限，超出只增加上下文切换和 CPU 争抢。磁盘 I/O 阻塞应该用 aio threads 解决而不是加 worker。

Q：Nginx 单机最大并发连接数怎么算？

理论上限 worker_processes × worker_connections。但反向代理时每个请求占 2 个连接（客户端侧 + 上游侧），实际可服务客户端数要除以 2。还受 worker_rlimit_nofile、系统 ulimit -n、fs.file-max、ip_local_port_range 限制。

Q：怎么配置一个最基本的反向代理？

location /api/ {
    proxy_pass http://backend;
    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 后端收到的是 upstream 名字；不设后三个后端拿不到真实客户端信息，生成的绝对 URL 也会是 http://。

2.2 中级（区分度最高）

Q：一个请求 /api/config.js，配置里有 location /api/ { proxy_pass ...} 和 location ~* \.js$ { root ...}，会走哪个？为什么？怎么修？

走正则那个，去 /var/www/static/api/config.js 找文件然后 404。因为正则优先于普通前缀匹配。

修复是给前缀加 ^~：

location ^~ /api/ { proxy_pass http://backend; }
location ~* \.js$ { root /var/www/static; }

规律：只要一个前缀 location 里配了 proxy_pass，且同时存在按扩展名匹配的正则 location，就应该给这个前缀加 ^~。

Q：为什么我在 location 里加了一条 add_header，server 层的安全头全没了？

add_header、proxy_set_header、access_log 这类可写多条的数组式指令，继承规则是「全有或全无」：子层级只要出现任意一条同名指令，父层级的所有同名指令一律不继承。

解法：子层重复写全，或抽成 include snippets/security-headers.conf 片段复用。

这个坑最隐蔽的形式是它会悄悄破坏 upstream keepalive：

http {
    proxy_http_version 1.1;
    proxy_set_header Connection "";      # 全局设置
    server {
        location /api/ {
            proxy_set_header X-Foo bar;   # ⚠️ 这一行让上面的 Connection "" 失效
            proxy_pass http://backend;
        }
    }
}

结果是 keepalive 64 完全失效、大量 TIME_WAIT，而配置看起来毫无问题。

Q：limit_req 和 proxy_pass 在配置里的先后顺序会影响执行顺序吗？

不会。执行顺序由阶段决定：limit_req 在 PREACCESS（第 6 阶段），proxy_pass 在 CONTENT（第 10 阶段），无论怎么写都是限流先执行。

同理 deny 在 ACCESS（第 7），所以顺序永远是「限流 → 鉴权 → 生成内容」。这个设计是对的：让廉价的限流先挡住流量，避免昂贵的鉴权被打爆。

Q：配了 keepalive 64 但上游还是几千个 TIME_WAIT，排查思路？

按顺序查四点：

1. 漏了 proxy_http_version 1.1;（Nginx 默认用 HTTP/1.0，不支持持久连接）
2. 漏了 proxy_set_header Connection "";（Nginx 默认发 Connection: close）
3. 子 location 里写了其他 proxy_set_header，数组式继承把父级的 Connection "" 整体冲掉了 ← 最隐蔽
4. 后端自己的 keepalive 没开，或者它的空闲超时比 Nginx 短

验证方法：

ss -tan | grep :8080 | awk '{print $1}' | sort | uniq -c
# 期望：ESTAB 数量稳定在 keepalive 值附近，TIME-WAIT 个位数

Q：rate=10r/s burst=20 和 rate=10r/s burst=20 nodelay 有什么区别？瞬间来 25 个请求分别什么结果？

漏桶算法下 rate=10r/s 实际是「每 100ms 放行 1 个」。

• 只有 burst：第 1 个立即处理，第 2-21 个进队列分别延迟 100ms…2000ms 处理，第 22-25 个返回 503。问题是第 21 个用户等了 2 秒。
• burst + nodelay：第 1-21 个全部立即处理（占满槽位），第 22-25 个 503；之后槽位按每 100ms 释放 1 个。

生产用 nodelay：用户打开页面瞬间发 10 个 API 请求是正常行为，不该被延迟。它的语义是「允许合理突发，长期速率受控」。

Q：proxy_next_upstream 该配哪些值？为什么不能加 http_500？

推荐 error timeout http_502 http_503 http_504，并配 proxy_next_upstream_tries 2。

• error：连接/发送都失败，后端没收到，安全
• 502/503/504：通常是后端进程没起或队列满，请求未被业务逻辑处理，相对安全
• http_500 不安全：500 意味着后端已经执行了请求只是过程出错，重试会造成重复副作用
• non_idempotent 更危险：POST 也会重试，后端已成功但响应超时时会重复下单/重复扣款

根本解法是业务层幂等（唯一请求 ID 去重），而不是在 Nginx 层纠结。另外 proxy_next_upstream_tries 不设默认是 0（不限次数），会把所有后端试一遍，后端多时一个请求能拖很久。

Q：$request_time = 3.5s 但 $upstream_response_time = 0.05s，问题在哪？

问题不在后端。$request_time 是 Nginx 视角的完整耗时，包含客户端网络传输时间。3.5s 里有 3.45s 花在了客户端接收数据上。

可能原因：响应体太大（看 $body_bytes_sent）、客户端网络差、没开压缩。处理方向是压缩、CDN、分页减小响应体——调 Nginx 或后端都没用。

反过来如果 upstream_connect_time 大，说明后端 accept 队列满、网络问题或没开 upstream keepalive。

Q：怎么防止缓存击穿？完整配置是什么？

proxy_cache_lock on;                    # 同 key 只让一个请求回源
proxy_cache_lock_timeout 5s;
proxy_cache_use_stale error timeout http_5xx updating;   # 后端挂了用旧数据顶
proxy_cache_background_update on;       # 过期时立即返旧值，后台异步刷新
proxy_cache_revalidate on;              # 带条件头回源，304 时不重传体

后两行是性价比最高的两行，实现了 stale-while-revalidate 语义：过期时用户零等待拿到旧数据、后台静默更新；后端全挂时用户仍能看到内容而不是 502。

Q：proxy_buffering on 有什么价值？什么时候必须关？

开启时 Nginx 尽快把上游响应读完缓存起来，后端进程立刻释放去处理下一个请求，慢速客户端由 Nginx 扛着。这是保护后端的核心机制——尤其对 PHP-FPM、同步框架这类每请求占一个进程/线程的后端。

必须关的场景：SSE、实时日志推送、大文件边下边传。也可以让上游返回 X-Accel-Buffering: no 来动态关闭，比在 Nginx 里写死更灵活。

2.3 高级（深度题）

Q：详细说说 reload 的完整流程，以及有什么坑。

1. nginx -s reload → 新起一个进程读 pid 文件，给 master 发 SIGHUP，然后退出
2. master 重新解析配置
   → 失败：打日志、保留旧配置继续跑，reload 静默失效  ⚠️
   → 成功：继续
3. master 创建新 listen socket（配置未变则复用旧 fd）
4. master fork 新 worker（用新配置）
5. master 给所有老 worker 发 SIGQUIT
6. 老 worker：从 epoll 移除 listen fd（停 accept）→ 处理完存量连接 → 销毁池 → 退出
   超过 worker_shutdown_timeout 则强制关闭连接后退出
7. master 回收僵尸进程，完成

三个坑：

1. 长连接会拖住老 worker（WebSocket/SSE/大文件下载），必须配 worker_shutdown_timeout 30s。
2. 频繁 reload 会累积老 worker，ps -ef | grep "shutting down" 能看到，进程数和内存越堆越多。
3. 共享内存 zone 会重建——限流计数器、upstream 的 zone 状态、缓存 key 索引全部清零。所以别把 reload 当常规操作反复执行（比如每次服务注册变化就 reload）。

Q：Nginx 的惊群问题有几代解决方案？各自的取舍？

生产建议：Linux 3.9+ 直接开 reuseport，accept_mutex off。官方压测显示长尾延迟明显改善。

Q：什么操作会阻塞 worker？后果多严重？怎么解决？

事件驱动模型的致命前提是回调绝不能阻塞。一旦卡住，这个 worker 上的所有连接（可能上万个）全部停摆，表现为部分请求突然变慢或超时——而且是随机的一批用户受影响，排查时容易误判为「偶发抖动」。

关于线程池：官方测试在大文件随机读（数据集远大于内存）场景吞吐提升 9 倍，但在文件全命中 page cache 的场景是负优化（白增调度开销）。所以它是专用优化不是万能开关。

Q：proxy_pass 里写域名和写变量有什么本质区别？

写死域名只在启动/reload 时解析一次，IP 缓存到进程生命周期结束。上游 IP 变了（K8s Pod 重建、云 SLB 换 IP、Docker 容器重建）就持续 502。

含变量时 Nginx 才会在运行时用自己的异步 resolver 解析：

resolver 127.0.0.11 valid=10s ipv6=off;   # Docker 内嵌 DNS
set $backend "api.example.com";
proxy_pass http://$backend$request_uri;    # 必须显式带 URI，变量式不自动传递

副作用是 URI 不再自动传递，要手写 $request_uri。另外 1.27.3+ 开源版支持 upstream 里的 server ... resolve 参数，是更干净的方案。

Q：11 个阶段里，try_files、auth_request、mirror、limit_req、realip 分别在哪个阶段？为什么这样排？

realip 在第 1 阶段是关键设计。如果它在限流之后，limit_req 拿到的就是代理的 IP 而不是真实客户端 IP，所有基于 IP 的限流全部失效——所有用户会共享同一个限流配额。

Q：sub_filter 对某些页面不生效，为什么？

过滤器链的顺序是编译期固定的：sub_filter 在 gzip 之前。如果上游返回的已经是 gzip 压缩的内容，sub_filter 拿到的是压缩后的字节流，无法做字符串匹配。

location / {
    proxy_pass http://backend;
    proxy_set_header Accept-Encoding "";   # 让上游返回未压缩内容
    sub_filter 'old' 'new';
    sub_filter_once off;
    sub_filter_types text/html text/css application/json;  # 默认只处理 text/html
    gzip on;                                # 由 Nginx 自己压缩
}

另一个常见原因是 sub_filter_types 默认只有 text/html。

Q：Nginx 的内存到底花在哪？怎么估算？

总内存 = worker_processes × 每 worker 内存 + 共享内存（只算一次）

每 worker 内存 =
    固定开销（代码段 + 共享内存映射）
  + worker_connections × 约 500 字节   ← 启动时一次性预分配！
  + 活跃连接数 × (proxy_buffers 总大小 + request pool)

共享内存 = proxy_cache 的 keys_zone
         + limit_req_zone + limit_conn_zone
         + ssl_session_cache
         + upstream 的 zone

两个关键点：

1. worker_connections 是启动时就分配的——设 100 万意味着启动就吃掉几百 MB 的 ngx_connection_t 和 ngx_event_t 结构体。所以要按实际并发算，不能拍脑袋。
2. proxy_buffers 是「每个活跃连接」的——proxy_buffers 16 64k（1MB）× 1 万并发 = 理论 10GB。调大要算清楚。

3. 综合设计题

这类题考的是能否把知识串成体系。答题时先讲思路和分层，再落到具体指令。

3.1 设计一个日均 1 亿 PV 的网站接入层

回答框架：分层 → 每层职责 → 关键配置 → 容量估算 → 监控。

DNS（智能解析/GSLB）
   ↓
CDN（静态资源 + 部分 API 缓存）
   ↓
四层 LB（LVS/云 SLB，做 VIP 和跨机房）
   ↓
Nginx 集群（本层重点）
   ↓
业务服务集群

Nginx 层的职责与配置：

# 容量估算：1亿 PV/天 ≈ 平均 1157 QPS，峰值按 5 倍算 ≈ 6000 QPS
# 单机 8 核能扛 3-5 万 QPS（反代），4 台机器有充足余量 + 容灾冗余

worker_processes auto;
worker_cpu_affinity auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 20480;      # 按峰值并发 × 2 / worker 数算
    accept_mutex off;
}

http {
    # ① 静态资源：CDN 回源，本层强缓存
    # ② API：短 TTL 缓存 + 防击穿
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:500m
                     max_size=50g inactive=2h use_temp_path=off;

    # ③ 上游长连接（最关键的优化）
    upstream backend {
        least_conn;
        server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
        # ... 更多节点
        keepalive 64;
        keepalive_timeout 30s;     # 短于后端 IdleTimeout
    }

    # ④ 分层限流
    limit_req_zone $binary_remote_addr zone=perip:50m rate=50r/s;
    limit_req_zone $server_name zone=global:10m rate=20000r/s;

    # ⑤ TLS 性能（HTTPS 站点的最大开销）
    ssl_session_cache shared:SSL:200m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;        # 多机共享 ticket key
    # ECDSA + RSA 双证书

    # ⑥ 日志（JSON + buffer）
    access_log /var/log/nginx/access.json.log json buffer=64k flush=5s;
}

要主动提到的点（体现深度）：

• 容量估算过程，而不是空谈「加机器」
• 多台 Nginx 必须共享 ssl_session_ticket_key，否则会话复用率极低
• 多台 Nginx 各自算 least_conn 会有羊群效应，考虑 random two least_conn
• 缓存分片如果用 hash 必须加 consistent，否则扩容一次缓存全失效、后端被击穿
• 单点问题：Nginx 层要 ≥ 2 台 + 四层 LB 或 keepalived
• 监控：5xx 率、P99 延迟、accepts != handled、缓存命中率、证书过期

3.2 设计一个灰度发布方案

回答框架：分流维度 → 一致性要求 → 可观测 → 回滚。

# 优先级：请求头（测试）> Cookie（用户主动）> 用户 ID 尾号（稳定）> hash（无登录态）
map $http_x_canary $by_header { default ""; "1" "canary"; "0" "stable"; }
map $cookie_uid    $uid_tail   { default ""; "~(\d)$" $1; }
map $uid_tail      $by_uid     { default ""; "7" "canary"; }   # 约 10%
split_clients "${remote_addr}${http_user_agent}" $by_hash { 5% "canary"; * "stable"; }

map "$by_header|$by_uid|$by_hash" $pool {
    default          "app_stable";
    "~^canary"       "app_canary";
    "~^\|canary"     "app_canary";
    "~^\|\|canary"   "app_canary";
}

location /api/ {
    proxy_pass http://$pool;
    proxy_set_header X-Pool $pool;
    add_header X-Pool $pool always;      # 便于验证和分池统计
}

关键论点（面试官想听的）：

1. 不要用 upstream 的 weight 做灰度。同一用户的连续请求会在新旧版本间跳，可能出现「刚提交的数据看不到」这类问题。
2. 必须按用户稳定分流（uid 尾号或 split_clients 哈希），保证同一用户永远在同一侧。split_clients 对输入做 MurmurHash2，同输入必然同结果。
3. 可观测性是灰度的前提：日志里带 X-Pool 或 $upstream_addr，能分池对比 5xx 率和 P99 延迟。没有分池监控的灰度等于盲测。
4. 回滚必须是秒级的：改 map 比例 + reload，不需要重新部署。
5. 数据库兼容性：灰度期间新旧代码同时读写同一个库，schema 变更必须向前兼容（先加字段不删字段、先双写后切读）。这是灰度真正的难点，不在 Nginx 层。

3.3 线上突然大量 502，排查思路

回答框架：先看日志定性 → 再分层验证 → 最后处置。

# ① error.log 定性（502 的具体原因就写在里面）
tail -200 /var/log/nginx/error.log | grep -oP '\) \K[a-z ]+' | sort | uniq -c

# ② 分层验证：从 Nginx 机器上直连后端，排除 Nginx 自身
curl -v http://10.0.0.1:8080/health

# ③ 看是全部后端还是部分
jq -r 'select(.status==502) | .uaddr' access.json.log | sort | uniq -c
#   全部节点都有 → 后端整体故障 / 依赖（DB/Redis）挂了
#   只有某个节点 → 单机问题，先摘掉它

# ④ 看时间分布：是持续还是尖峰
jq -r 'select(.status==502) | .time[0:16]' access.json.log | uniq -c

# ⑤ 是不是刚发布/刚 reload
docker compose ps    # 或 kubectl get pods -w
git log --oneline -5

一个高频的隐蔽原因（答出来加分）：Nginx 的 upstream keepalive_timeout 长于后端的 IdleTimeout。后端先关闭空闲连接，Nginx 恰好在这一瞬间往这条连接上发请求，就会 upstream prematurely closed connection。特征是502 数量少但持续存在，后端却没有任何错误日志。修复是让 Nginx 侧超时更短（Nginx 30s，后端 90s）。

K8s 环境的高频原因：滚动更新时 SIGTERM 和移除 Endpoint 并行，preStop: sleep 10 可以消除这个窗口。

处置顺序：先止损（摘掉故障节点/回滚发布/开 proxy_cache_use_stale 顶住），再定位根因。不要在流量还在打的时候慢慢调试。

3.4 静态资源加载慢，怎么优化

回答框架：先量化 → 分层优化 → 验证。

# 量化：先搞清慢在哪一段
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} size:%{size_download}\n" \
  https://example.com/app.js

Nginx 侧的具体配置：

# ① 压缩：构建时预压缩，运行时零 CPU
gzip_static on;
brotli_static on;

# ② 缓存分层：带 hash 的永久缓存
location ~* \.[0-9a-f]{8,}\.(js|css|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
    try_files $uri =404;      # 不能回退到 index.html
}

# ③ 入口 HTML 绝不缓存（否则发版后用户还是旧页面）
location = /index.html {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
    expires -1;
}

# ④ 传输
sendfile on;
tcp_nopush on;
open_file_cache max=100000 inactive=60s;
ssl_buffer_size 4k;          # 降低首字节延迟

# ⑤ HTTP/2 或 HTTP/3
http2 on;

要提到的关键论点：真正的大头往往不在 Nginx——静态资源优化的收益顺序是 CDN > 浏览器缓存策略 > 压缩 > Nginx 传输参数。前三项是数量级的改善，最后一项是百分比级的。

4. 易错点速查

面试时说错这些会直接暴露没有实操经验。

5. 答题框架

被问到开放性问题时，用这几个框架组织回答，比零散罗列配置项显得体系化得多。

5.1 「你怎么优化 Nginx 性能」

先讲方法论，再讲具体项：

1. 建立基线 + 明确目标（QPS 多少、P99 多少），不要盲目抄参数
2. 分层压测定位瓶颈：return 200（测极限）→ 静态文件 → 直压后端 → 通过 Nginx 压后端。四组数据一对比就知道瓶颈在哪层
3. 强调一个前提：绝大多数「Nginx 性能问题」病根不在 Nginx。判断依据是 $upstream_response_time / $request_time 的比例——如果 90% 时间在等后端，调 Nginx 是白费功夫
4. 一次只改一项并压测验证，否则不知道是哪项起作用、有没有某项被掩盖的负作用
5. 按收益排序说具体项：upstream keepalive（最大）> TLS 会话复用 > gzip_static > reuseport > 日志 buffer > 缓冲区调整

5.2 「说说你对 Nginx 架构的理解」

按四层展开：

1. 进程模型：master（root，管配置和进程，不处理请求）+ worker（低权限，干活）+ cache manager/loader。worker 间无共享无锁，一个崩了 master 重启它
2. I/O 模型：epoll ET + 全非阻塞 socket + 状态机。请求被拆成一串「让出-回来」的片段，一个 worker 单线程管数万连接
3. 模块化：11 个阶段的 handler 链 + 两条 filter 链（header/body），阶段和链的顺序编译期固定。第三方模块通过往阶段注册 handler 参与处理
4. 内存管理：三种生命周期的内存池（cycle/connection/request），小块分配只是移动指针，请求结束一次性销毁全部回收

然后主动引出一个深度点，比如：「这个设计的代价是回调绝不能阻塞——一旦某个 worker 卡在磁盘冷读或同步 DNS 解析上，它上面的上万个连接全部停摆，表现为随机一批用户突然变慢。这也是 aio threads 线程池和 resolver 配置存在的原因。」

5.3 「线上出问题你怎么排查」

固定动作，按顺序说：

# ① error.log 定性（Nginx 的报错信息质量很高，多半直接告诉你原因）
tail -200 /var/log/nginx/error.log

# ② access_log 定量（范围、时间分布、涉及哪些节点）
jq -r 'select(.status>=500) | "\(.time[0:16]) \(.uaddr) \(.uri)"' access.json.log | sort | uniq -c

# ③ 耗时拆解（Nginx 慢还是后端慢）
jq -r 'select(.rt>1) | "\(.rt) \(.urt) \(.uri)"' access.json.log | sort -rn | head -20

# ④ 连接状态（队列溢出、TIME_WAIT、CLOSE_WAIT）
ss -s; nstat -az | grep -E "ListenOverflows|ListenDrops"

# ⑤ 系统资源
top; iostat -x 1; free -h

# ⑥ 配置确认（include 展开后的真实配置）
nginx -T | grep -A5 "location /api"

# ⑦ 只对自己的 IP 开 debug（不影响其他用户）
# events { debug_connection 1.2.3.4; }  error_log ... debug;

强调两点：

• 止损优先于定位：先摘故障节点/回滚发布/用 proxy_cache_use_stale 顶住，再慢慢查根因
• $request_id 是最高效的工具：用户提供一个 ID，就能在 Nginx 日志、应用日志、SQL 日志里精确定位同一次请求的全部记录。没有它只能靠时间戳 + IP 模糊匹配，高并发下几乎不可行

6. 系列回顾

上一篇：Nginx-13 实战案例（Go 服务 + Docker）