Nginx 不直接按“请求类型”分发，而是通过 server 块匹配 Host 头、location 匹配 URI、if 判断请求方法或请求头（如 $request_method、$http_content_type），再结合 upstream 和 proxy_pass 将不同特征请求路由至对应后端集群，并透传 Host、X-Real-IP 等关键头部。
Nginx 本身不直接按“请求类型”（如 GET/POST/JSON/XML）来分发或差异化响应，而是通过 server 块 + location 块 + 条件判断 的组合实现对不同请求特征的区分处理。真正起决定作用的是 Host 头、URI 路径、HTTP 方法、请求头内容、甚至请求体特征，而非笼统的“请求类型”。关键在于理解 Nginx 的匹配逻辑和可干预阶段。
按 Host 头选择 server 块是第一步
每个 server 块代表一个虚拟主机，Nginx 首先根据请求中的 Host 请求头 匹配 server_name 指令：
- 精确匹配优先（如
server_name api.example.com;） - 通配符支持开头（
*.example.com）或结尾（www.example.*），但不能同时用 - 未匹配时路由到该端口标记为
default_server的块（建议显式配置，避免依赖顺序） - 无 Host 头的请求默认匹配
server_name ""（0.8.48+ 版本自动生效），可用return 444主动断连
在同一个 server 内按路径或方法做细粒度分流
进入 server 后，Nginx 用 location 块匹配 URI，再结合 if 或内置变量做进一步判断：
-
location /api/ { ... }匹配所有以/api/开头的路径，常用于转发 JSON API 请求 -
location = /health { ... }精确匹配健康检查端点，返回静态文本或 200 -
if ($request_method = POST) { ... }可拦截特定方法，但仅限简单判断（不推荐嵌套复杂逻辑） -
if ($http_content_type ~* "application/json") { ... }可依据请求头识别 JSON 请求，再设置不同 proxy_pass 或限流策略
用 upstream 和 proxy_pass 实现后端差异化响应
实际“不同处理”往往体现为转发到不同后端服务，这时需配合 upstream 定义集群：
- 为 REST 接口定义
upstream backend_api { server 10.0.1.10:8000; } - 为文件上传单独定义
upstream backend_upload { server 10.0.1.20:9000; }，并在对应 location 中proxy_pass http://backend_upload - 务必透传关键头：
proxy_set_header Host $host;、proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
注意匹配顺序与性能影响
Nginx 的匹配不是逐行扫描，而是构建哈希表或树结构加速查找，但仍有规则需遵守：
-
server_name匹配不区分大小写，但建议统一小写书写 - 多个
server块监听同一 IP:端口时，避免server_name重叠（如同时写example.com和*.example.com） - 大量域名建议用 hash map 优化：
server_names_hash_bucket_size 64;（根据最长域名长度调整） - 正则
server_name ~^www\d+\.example\.com$功能强但性能略低，非必要不滥用
