nginx.conf 核心结构按 main→events→http→server→location 五级作用域嵌套设计：main 配置全局运行参数，events 调优连接处理，http 定义协议行为与默认上下文，server 划分虚拟主机，location 实现 URI 路由匹配。
nginx.conf 是 Nginx 的灵魂所在，其结构不是随意堆砌，而是围绕“作用域嵌套”与“指令生效层级”设计的。理解它的核心块（main、events、http、server、location）及其嵌套逻辑，才能真正掌控配置行为，避免常见陷阱，比如指令位置错误导致失效、上下文冲突或性能异常。
main 块：全局运行环境的基石
main 块位于配置文件最外层，不被任何花括号包裹，是整个 Nginx 进程的全局配置区。它不处理请求，但决定 Nginx 如何启动、以谁的身份运行、日志怎么记、工作模式如何调度。
- user 指定 worker 进程运行用户，影响静态资源读取权限；若用 root 启动但未降权，存在安全风险
- worker_processes 设置 worker 进程数，通常设为 auto（自动匹配 CPU 核心数），过多反而引发上下文切换开销
- pid 和 error_log 必须在此层级定义，否则无法在启动阶段生效
- include 常用于引入模块配置（如 modules-enabled/*.conf）或加密参数，但不能出现在 http/server 等子块内
events 块：连接处理机制的开关面板
events 块紧邻 main 块，专用于调优网络连接行为。它不定义业务逻辑，只控制 Nginx 怎么收包、怎么分发、能扛多少并发。
- use 显式指定事件驱动模型（epoll/kqueue/select），Linux 下默认 epoll，但显式声明更稳妥
- worker_connections 设定单个 worker 最大并发连接数，实际最大连接 ≈ worker_processes × worker_connections
- multi_accept 控制是否一次性接受全部就绪连接；开启可降低延迟，但需配合 accept_mutex 避免惊群
- 该块不可嵌套，也不可重复出现；若遗漏，Nginx 使用编译时默认值（如 512），易成性能瓶颈
http 块：协议处理与请求分发的核心中枢
http 块是绝大多数配置落地的地方，所有与 HTTP 协议相关的行为——MIME 类型识别、日志格式、缓存策略、反向代理逻辑——都从这里展开。它本身不响应请求，但为内部 server 和 location 提供默认继承上下文。
- sendfile、tcp_nopush、tcp_nodelay 等优化项应在此层级统一开启，避免在每个 server 中重复写
- gzip 相关指令（on/off、level、types）必须在 http 块中启用，否则 location 内的 gzip_static 不会生效
- upstream 定义必须放在 http 块下，且不能嵌套在 server 内；它属于全局资源，供多个 server 共享调用
- 注意变量作用域：$host、$request_uri 在 http 块不可用，仅在 server 及以下上下文有效
server 与 location：请求路由的两级决策引擎
server 块定义虚拟主机边界（基于 IP:Port 或 ServerName），location 块则在该 host 内按 URI 前缀或正则进一步细分处理逻辑。二者构成“先选主机、再选路径”的两级匹配机制，且 location 匹配有严格优先级规则。
- 一个 http 块可含多个 server，每个 server 应有唯一 listen 指令；未指定 default_server 的监听端口，Nginx 任选其一作兜底
- location 匹配顺序：精确匹配（=）→ 前缀最长匹配（^~）→ 正则匹配（~ / ~*）→ 普通前缀匹配；正则一旦命中即终止搜索，不继续比前缀
- proxy_pass 后的 URI 尾部斜杠影响重写逻辑：proxy_pass http://backend/ 截断匹配路径，proxy_pass http://backend 不截断
- root 与 alias 行为差异大：root 把 location 路径拼接到末尾，alias 把 location 路径替换为指定目录，误用会导致 404
