nginx配置采用严格分层树状结构：main块负责进程级全局控制，events块管理连接处理，http块作为http服务中枢，server块定义虚拟主机，location块实现uri路由匹配与处理。
Nginx 配置不是扁平罗列，而是严格分层的树状结构。每一层只负责特定职责，上层设默认值、下层可覆盖，这种继承与隔离机制让配置既灵活又可控。
main 块：进程级全局控制
这是整个 nginx.conf 最外层、无花括号包裹的部分，只在 master 进程启动时读取一次。它不处理请求，但决定 Nginx 怎么“活下来”：
- user 指定 worker 进程运行身份，直接影响静态文件读取权限；生产环境切勿用 root 持续运行
-
worker_processes 建议设为
auto，自动匹配 CPU 核心数；设得过多反而增加调度开销 - worker_rlimit_nofile 提升单个 worker 可打开的文件描述符上限，需同步调整系统 ulimit
- pid 和 error_log 必须在此层定义，否则启动阶段就无法记录关键错误
- include 只能出现在 main 层，常用于加载模块配置或加密参数文件
events 块：连接处理的底层开关
紧接 main 块之后，专管网络连接行为。它不涉及业务逻辑，只决定 Nginx 怎么“收包”和“分发”：
- use epoll 显式声明事件模型（Linux 下推荐），比依赖编译默认更可靠
-
worker_connections 设定单个 worker 最大并发连接数；总并发能力 ≈
worker_processes × worker_connections -
multi_accept on 让 worker 尽可能一次接收多个就绪连接，降低延迟，但需配合
accept_mutex防止惊群 - 该块不可嵌套、不可重复，遗漏则回退到编译默认值（如 512），极易成为性能瓶颈
http 块：HTTP 协议处理的中枢
所有 Web 服务配置都发生在这里，是真正意义上的“配置主战场”。它本身不响应请求，但为内部 server 和 location 提供统一上下文：
- sendfile、tcp_nopush、keepalive_timeout 等优化指令应统一在此层开启，避免重复配置
- log_format 必须在 http 块顶层定义；access_log 才可在 http/server/location 多级覆盖
- upstream 必须定义在 http 块内，且不能放在 server 中——它是全局资源，供多个 server 复用
-
gzip 相关指令（on/off、level、types）必须在此层启用，否则 location 内的
gzip_static不生效 - include /etc/nginx/conf.d/*.conf 是常见做法，把站点配置拆出，保持主文件清爽
server 与 location：请求路由的两级终点
server 是虚拟主机边界，location 是 URI 路由终点，二者构成实际请求处理链：
- 每个 server 通过
listen+server_name匹配请求；Nginx 按顺序扫描，首个满足条件者胜出 - TLS 配置（
ssl_certificate、ssl_protocols）必须成对出现在同一 server 块中，不可拆分 -
location 的匹配有明确优先级：
=（精确） >^~（前缀） >~/~*（正则） > 纯前缀；匹配成功即终止搜索 - root、index、client_max_body_size 等指令可在 server 层设置默认值，在 location 层按需覆盖
- proxy_pass、try_files、rewrite 等核心转发/重写逻辑，基本都落在 location 块内执行
