Nginx通过map指令解析User-Agent识别浏览器内核并路由，location仅限定路径作用域；map在http块中预定义内核变量，配合proxy_pass实现高效分流，避免使用不可靠的if+proxy_pass。
Nginx 本身不直接识别“浏览器内核”，但可以通过解析请求头中的 User-Agent 字符串，结合 location 配合 if 或更推荐的 map 指令，实现按内核特征（如 WebKit、Blink、Gecko、Trident）做条件路由。关键不是 location 单独完成，而是用 location 定义路径入口，再借助变量驱动 proxy_pass 分发。
用 map 提取内核类型，统一管理判断逻辑map 适合多规则、可读性强、性能稳定，应定义在 http 块中：
http {
map $http_user_agent $backend_kernel {
default backend-standard;
~*Trident backend-ie;
~*Edge backend-edge;
~*WebKit.*Apple backend-safari;
~*WebKit.*Chrome backend-chrome;
~*Gecko backend-firefox;
~*Blink backend-chrome;
}
upstream backend-standard { server 10.0.1.10:8080; }
upstream backend-ie { server 10.0.1.20:8080; }
upstream backend-safari { server 10.0.1.30:8080; }
# 其他 upstream ...
}然后在 server 块中用普通 location / 接收所有请求，通过 $backend_kernel 变量转发：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://$backend_kernel;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}为什么不用 if + proxy_pass？if 在 location 外部使用 proxy_pass 是非标准行为，易导致变量未初始化或重写冲突；即使放在 location 内，也受限于执行阶段（rewrite 阶段），不如 map 在 server 阶段预计算可靠。
location 的作用是限定作用域，不是做 UA 判断location 本身只匹配 URI 路径，不处理请求头。若你希望“仅对 /api/ 下的请求做内核分流”，就用：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
location /api/ {
proxy_pass http://$backend_kernel;
# 其他 proxy_* 参数
}这样，map 仍负责 UA 解析，location 控制分流生效范围——路径和内核两个维度正交组合，灵活可控。
注意 User-Agent 的常见匹配要点
- 正则用
~*（大小写不敏感）更稳妥 - Safari 的 UA 同时含
WebKit和Apple，单独匹配WebKit会误判 Chrome；建议加.*Apple限定 - Chrome 和新版 Edge 都用 Blink，但 Edge UA 含
Edg，可单列~*Edg提高精度 - IE11 UA 含
Trident/7.0，~*Trident足够覆盖
不建议的做法
- 在每个
location里重复写if ($http_user_agent ~* Trident) { ... }：难维护、易出错、不支持嵌套 proxy_pass - 用
rewrite修改 URI 再靠路径匹配：绕远路，增加复杂度且丢失原始路径语义
本质上，这是“请求头特征 + 路径作用域”的协同策略，location 定边界，map 做决策，proxy_pass 执行分发。
