Server块是Nginx中定义虚拟主机的核心单元，必须嵌套在http块内，通过listen和server_name匹配请求，内部由root、location、proxy_pass等指令协同处理请求逻辑。
Server 块是 Nginx 配置中定义虚拟主机的核心单元，它不独立存在，必须嵌套在 http 块内。解析 Server 块，关键在于理解它的作用边界、匹配逻辑和内部指令的协作关系。
Server 块的位置与嵌套规则
它只能出现在 http 块中，不能写在全局块或 events 块里。一个 http 块可包含多个 server 块，彼此并列、互不继承——每个都是一套独立的虚拟主机配置。
- server 块外的 http 全局配置（如
sendfile on）对其生效，但可被块内同名指令覆盖 - 多个 server 块之间无顺序依赖，Nginx 根据请求头中的 Host 字段和 listen 参数匹配最精确的那个
- 若无匹配的
server_name，Nginx 使用第一个满足listen条件的 server 块作为默认主机
Server 块的匹配触发条件
一个请求进来时，Nginx 不是“逐个读取 server 块”，而是先根据监听地址和端口筛选候选，再按域名精确度排序匹配。
-
listen是硬性门槛：比如请求目标是 443 端口，只有listen 443 ssl或listen *:443的 server 块才参与后续匹配 -
server_name决定最终归属：支持精确匹配（example.com）、通配符（*.example.com）、正则（~^www\d+\.example\.com$），优先级从高到低 - 未设
server_name或匹配失败时，空名称（server_name ""）或默认 server（带default_server标志）会兜底
Server 块内部常用指令分工
它本身不直接处理请求，而是通过子指令组织行为逻辑：
-
root或alias定义静态资源根路径；注意alias在 location 中更安全，能天然阻断目录遍历 -
location块按 URI 路径做二次分发，其匹配规则（前缀、正则、= 精确）影响执行优先级 -
proxy_pass、fastcgi_pass等用于反向代理或协议转发，必须配合location使用 - SSL 相关指令（如
ssl_certificate）只在启用ssl的listen行下有效
常见配置陷阱提醒
看似简单的 server 块，容易因细节导致 404、502 或证书错误：
- 多个 server 块监听同一端口但
server_name重复，后加载的会覆盖前者（取决于配置文件加载顺序） -
root写在 server 级，而location /api/又用了proxy_pass，此时 root 不影响代理行为，仅对未匹配 location 的请求起作用 - HTTP 和 HTTPS 服务必须用两个独立 server 块，不能混在同一块中——因为
ssl是 listen 的修饰符，不是通用开关 - 修改后务必运行
nginx -t验证语法，再nginx -s reload生效，避免配置错误导致服务中断
