nginx基于内容的https路由必须先终止tls才能解析http层信息，因此全部依赖七层反向代理模式；需配置有效证书、启用ssl模块，并通过location、map、njs等机制实现路径、请求头、cookie、查询参数等维度的精准分流，敏感场景建议后端网关处理请求体解析与权限决策。
Nginx 支持基于内容的 HTTPS 路由分发，但需明确：HTTPS 层本身不暴露请求内容（如 URL 路径、Header、Body），必须先终止 TLS 才能解析 HTTP 层信息。因此，所有基于内容的路由都依赖于 七层（HTTP）反向代理模式，即 Nginx 主动解密 HTTPS 流量，再根据解密后的请求特征做决策。
✅ 前提：启用 HTTPS 终止与基础安全配置
确保 Nginx 已正确加载 SSL 模块，并配置有效证书：
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example.com.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
# 必须透传原始协议和客户端信息
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
}
? 基于 URL 路径的路由（最常用）
用 location 块匹配路径前缀或正则，直接转发：
location /api/v1/users/ {
proxy_pass https://users-service/;
}
location /api/v1/orders/ {
proxy_pass https://orders-service/;
}
location ~ ^/api/v2/(products|categories)/ {
proxy_pass https://catalog-service/$1/;
}
-
proxy_pass后加/表示去除匹配前缀再转发 - 正则匹配支持
$1,$2捕获组，便于重写路径
? 基于请求头的路由（如 User-Agent、Authorization、自定义 Header）
使用 map 提前提取变量，再在 location 或 if 中判断：
# 在 http 块顶层定义（非 server 内）
map $http_user_agent $backend {
default "default-backend";
~*mobile "mobile-backend";
~*curl|httpie "cli-backend";
}
map $http_x_client_type $route {
"admin" "admin-service";
"partner" "partner-service";
default "public-service";
}
server {
location / {
proxy_pass https://$backend;
# 或更精细控制：
# proxy_pass https://$route;
}
}
⚠️ 注意：if 在 location 中慎用（仅限简单判断），避免嵌套逻辑；优先用 map 实现无副作用的变量映射。
? 基于 Cookie 或查询参数的路由
同样通过 map 解析，例如按 ?env=staging 或 Cookie: version=v2 分流：
map $args $env_param {
~env=prod "prod-backend";
~env=staging "staging-backend";
default "default-backend";
}
map $cookie_version $version_route {
"v2" "v2-service";
"canary" "canary-service";
default "v1-service";
}
location / {
proxy_pass https://$env_param;
# 或组合使用：proxy_pass https://$version_route;
}
-
$args是完整 query string，正则匹配即可提取参数 -
$cookie_XXX直接读取指定 Cookie 名（自动小写转换）
? 基于请求体内容的路由（需谨慎）
Nginx 默认不读取请求体，要实现需启用 lua-nginx-module 或 njs，或借助外部服务。轻量级方案如下（仅适用于小体积 JSON 表单）：
# 启用 body 缓存（影响性能，仅限低频场景）
client_body_buffer_size 128k;
client_max_body_size 1m;
# 使用 njs 提取 JSON 字段（需编译含 njs 的 Nginx）
js_import ./router.js;
js_set $target backend_selector;
location /webhook {
proxy_pass https://$target;
}
对应 router.js 示例：
function backend_selector(r) {
try {
const body = JSON.parse(r.requestBody);
return body.event === "payment.succeeded"
? "payments-service"
: "events-service";
} catch (e) {
return "fallback-service";
}
}
⚠️ 生产环境推荐将 Body 解析逻辑下沉至后端网关（如 Spring Cloud Gateway、Traefik），Nginx 专注高效路由与 TLS 卸载。
? 安全增强建议
- 所有
proxy_pass目标建议使用 HTTPS（https://backend），避免内网明文传输 - 开启 OCSP Stapling 加速证书验证：
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/fullchain.pem; resolver 8.8.8.8 valid=300s;
- 对敏感路径（如
/admin）叠加 IP 白名单或 Basic Auth，作为前置防护
Nginx 的内容路由能力强大但有边界：它擅长解析已解密的 HTTP 元数据，不适合深度解析加密 Body 或执行复杂 RBAC。把内容识别交给 Nginx，把权限决策交给后端，才是稳健架构。
