Nginx 将 HTTP 请求处理划分为 11 个有序阶段：postread、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、postaccess、try-files、content、log，各阶段职责明确且支持模块介入，构成可预测、可扩展、易调试的请求处理流水线。
Nginx 处理一个 HTTP 请求，并非线性执行，而是划分为 11 个明确的、有序的处理阶段（phases）。每个阶段承担特定职责，模块可注册处理器（handler）介入，从而实现高度可控与可扩展的行为。理解这 11 个阶段，是掌握 Nginx 行为逻辑、调试配置异常、编写自定义模块的基础。
核心阶段顺序与作用
这 11 个阶段按执行先后排列，构成请求生命周期的骨架：
- postread：请求行和头部读取完成后立即触发。常用于修正客户端真实 IP（如 realip 模块读取 X-Forwarded-For 或 Proxy Protocol）。
- server-rewrite：在匹配 server 块后、查找 location 前，执行 server 级别的 rewrite 指令。
- find-config：根据 Host、URI 等信息，精确匹配到对应的 server 和 location 配置块。此阶段无模块可介入，纯内部路由。
- rewrite：在匹配的 location 内执行 rewrite 指令（如 rewrite ^/old /new redirect）。可多次重写，最终跳转或内部重定向。
- post-rewrite：重写流程结束后，判断是否发生内部重定向（如 last 标志），并决定是否重新进入 find-config 阶段。
- preaccess：访问控制前的准备阶段，例如限流模块（limit_req）在此处注册，做速率检查的前置初始化。
- access：核心权限控制阶段。IP 黑白名单（allow/deny）、auth_basic、limit_conn 等均在此生效。
- postaccess：access 阶段执行完毕后的收尾，例如记录拒绝日志或触发审计动作。
- try-files：尝试按指定顺序查找静态文件或目录（如 try_files $uri $uri/ /index.html），失败则进入 content 阶段。
- content：生成响应内容的核心阶段。由具体 handler 承担：static 模块返回文件、proxy_pass 转发请求、fastcgi_pass 交由 PHP-FPM 等。
- log：请求处理完成（无论成功或失败）后，记录 access_log 和 error_log。此阶段保证日志不遗漏。
阶段间的依赖与跳转逻辑
阶段并非严格单向推进。关键跳转点包括：
- rewrite 阶段中使用 last 会触发 post-rewrite → find-config 的循环，相当于“内部重定向”；使用 break 则直接进入后续阶段。
- try-files 查找不到任何匹配项时，不会报 404，而是将控制权交给 content 阶段的默认 handler（通常是 proxy_pass 或 index 指令）。
- access 阶段若拒绝请求（如 deny all），会直接跳转至 log 阶段，跳过 try-files 和 content，响应 403。
- content 阶段若 handler 未产生输出（如 proxy_pass 目标不可达），Nginx 会自动返回 502 或 500，仍会进入 log 阶段。
为什么阶段设计如此重要？
这种分阶段模型带来三方面实际价值：
- 行为可预测：你知道 limit_req 一定在 access 前执行，而 realip 一定在所有权限判断之前拿到真实 IP，避免逻辑错位。
- 模块协作清晰：不同功能模块各司其职，比如安全模块专注 access，缓存模块可在 content 前插入，无需侵入其他逻辑。
- 调试定位高效：当请求被意外拦截或重写异常，结合 error_log 中的 phase 信息，能快速锁定问题发生在哪个环节。
典型配置中的阶段映射示例
以下配置片段对应的关键阶段：
server {
listen 80;
server_name example.com;
<pre class="brush:php;toolbar:false;"># → server-rewrite 阶段生效
rewrite ^/temp/(.*)$ /$1 permanent;
location /api/ {
# → access 阶段：IP 白名单
allow 192.168.1.0/24;
deny all;
# → preaccess + access 阶段：每秒最多 10 个请求
limit_req zone=api burst=20 nodelay;
# → content 阶段：转发至上游
proxy_pass http://backend;
}
location / {
# → try-files 阶段尝试查找静态文件
try_files $uri $uri/ /index.html;
# → content 阶段：serve 静态文件
}
}
每一行指令背后，都锚定在某个具体阶段，共同编织出完整的请求处理流水线。
