Nginx执行顺序全解析：从配置加载到请求响应的关键步骤

Nginx作为高性能Web服务器和反向代理工具，其配置执行顺序直接决定了服务的行为逻辑。无论是静态资源访问、反向代理转发，还是重定向、缓存策略，背后都依赖于一套严格的执行规则。理解这些顺序不仅能解决"配置不生效"的常见问题，更能优化性能、排查故障。本文将拆解Nginx从启动到响应完成的核心执行流程。

一、配置加载：由外到内的层级覆盖

Nginx的配置执行始于配置文件加载，遵循"顶层定义→继承覆盖"的原则。

主配置文件为起点：Nginx启动时优先加载nginx.conf，解析顶层块（如main、events、http）。其中main块定义全局参数（如worker进程数、错误日志路径），events块配置连接模型（如epoll、kqueue），http块则是核心配置容器，包含多个server块。

子配置文件的叠加：通过include指令引入的子配置文件（如conf.d/*.conf），会按文件出现顺序覆盖或增强父块配置。例如http块中gzip on的全局压缩开关，可被子配置文件中的gzip off局部禁用。

Server块的独立作用域：每个server块通过listen（端口/IP）和server_name（域名）匹配请求，一旦匹配成功，该块内的配置将覆盖http级配置。例如：

http {
  gzip on;  # 全局开启gzip
  server {
    listen 80;
    server_name example.com;
    gzip off;  # 局部禁用gzip
  }
}

此时仅example.com域名的请求会关闭gzip，其他域名仍启用。

二、请求处理：从连接建立到响应返回的五大阶段

当请求进入Nginx，会按固定阶段逐步处理，每个阶段有明确的执行顺序和功能。

1. 连接建立与请求读取（Read Phase）

TCP握手确认：Nginx通过listen监听端口，接收客户端TCP连接（如HTTP/1.1的长连接或HTTP/2的多路复用）。
请求头解析：读取HTTP请求行（方法、URI、协议版本）和请求头（如Host、User-Agent），此时尚未解析URI路径（如/api/123）。

2. 路由与Location匹配（Route Phase）

匹配规则优先级：Nginx按以下顺序匹配Location块，一旦匹配成功立即终止后续匹配：
1. 精确匹配（location = /static）：完全匹配URI路径；
2. 前缀匹配（location ^~ /static）：以指定前缀开头，^~修饰符阻止后续正则匹配；
3. 正则匹配（location ~ \.php$）：按正则表达式匹配，按配置文件顺序执行第一个匹配项；
4. 普通前缀匹配：未匹配前三项时，取最长前缀匹配（如location /api匹配/api/v1）。
示例：请求/static/style.css时，location = /static/style.css（精确匹配）优先于location ^~ /static（前缀匹配），后者又优先于location ~ \.css$（正则匹配）。

3. 指令执行与内容处理（Handler Phase）

进入匹配的Location块后，按指令优先级执行处理逻辑：

重写（Rewrite）：在rewrite指令中修改URI（如rewrite /old /new permanent），执行后URI会被重新解析（可能进入新的Location匹配）；
反向代理（Proxy Pass）：通过proxy_pass转发请求到后端服务器（如proxy_pass http://backend:8080），此时请求已离开Nginx的处理范围；
静态资源处理：通过root或alias指定文件路径（如root /var/www/html），Nginx直接读取文件并返回（需处理压缩、缓存等）。