Nginx源码中ngx_http_core_module如何全面掌控请求生命周期？

本文共计835个文字，预计阅读时间需要4分钟。

ngx_http_core_module是NGINX HTTP模块的核心，它不直接控制请求的生命周期，而是通过定义标准阶段、调度handler、管理连接与上下文，使整个生命周期的配置、插拔、预测成为可能。

请求生命周期由 11 个固定阶段驱动

该模块在初始化时构建并维护一个阶段数组（phases[NGX_HTTP_XXX_PHASE]），每个阶段对应请求处理的一个逻辑关口。真正执行顺序由核心引擎严格保障，模块只能向其中注册 handler，不能增删或重排阶段：

• NGX_HTTP_POST_READ_PHASE：刚读完请求头，适合快速拦截（如限速、IP 黑名单）
• NGX_HTTP_SERVER_REWRITE_PHASE 和 NGX_HTTP_REWRITE_PHASE：分别执行 server 块和 location 块内的 rewrite 指令
• NGX_HTTP_FIND_CONFIG_PHASE：内部专用，完成 location 匹配，不可注册 handler
• NGX_HTTP_ACCESS_PHASE：执行 allow/deny、auth_basic 等访问控制指令
• NGX_HTTP_CONTENT_PHASE：最关键的阶段，静态服务、proxy_pass、fastcgi_pass 等内容生成逻辑在此触发
• NGX_HTTP_LOG_PHASE：记录 access_log，无论响应是否成功都会执行

连接与请求资源由它统一调度和回收

它不创建连接，但决定连接如何被复用、超时如何判定、缓冲区如何分配：

• keepalive_timeout 控制长连接空闲时长；client_header_timeout/client_body_timeout 防止慢速攻击拖垮 worker
• 每个请求绑定独立内存池（r->pool），所有动态变量值（如 $uri、$args 解析结果）、临时文件路径、header 字符串都从中分配，请求结束自动释放
• sendfile、aio、directio 等 I/O 优化行为由它解析配置后，在 sendfile 阶段或 content 阶段协同内核机制启用

路由与文件定位逻辑由它实现并暴露为配置原语

location 匹配不是正则引擎简单扫描，而是编译为前缀树 + 正则链表的混合结构，由 core module 在 NGX_HTTP_FIND_CONFIG_PHASE 高效完成：

• root 指令拼接路径时保留 URI 后缀；alias 则完全替换前缀，二者语义差异直接影响文件系统查找路径
• try_files 不是简单 if-else，而是在 content 阶段按顺序调用 ngx_http_realpath 检查文件/目录是否存在，命中即跳过后续 handler
• 正则 location 中使用 alias 必须引用捕获组（如 alias /data/$1/;），否则无法确定替换目标

错误与响应流程由它兜底和协调

当某个阶段 handler 返回 NGX_ERROR 或 NGX_HTTP_SPECIAL_RESPONSE，core module 会接管后续流程：

• 遇到 404，若配置了 error_page 404 /404.html，则发起内部子请求，进入新一轮 phase 循环
• recursive_error_pages on 允许子请求再触发 error_page，但默认关闭以防无限递归
• log_not_found off 可屏蔽 404 日志，避免日志刷屏；log_subrequest on 则记录所有子请求，用于调试嵌套逻辑