http/2 协议层面全局生效，无法按路由开关；可动态调整的是 proxy_pass 目标、upstream 成员等路由逻辑，通过 map、upstream 分离与 reload 实现灰度发布，且不影响已建立的 http/2 连接。
HTTP/2 本身是协议层面的特性，启用后全局生效，**不能在系统升级期间对“部分路由”单独开启或关闭 HTTP/2**。Nginx 不支持 per-location 或 per-server 的 HTTP/2 开关——listen 指令上一旦声明 http2，整个 server 块都走 HTTP/2；没声明，就走 HTTP/1.1。
真正可动态调整的是路由行为，不是协议版本
你在升级期间想“差异化处理某些路径”，实际要解决的是：如何让特定请求（如 /api/v2/ 或 /admin）走新后端，而其他路径保持旧逻辑，且整个过程不中断、不影响已建立的 HTTP/2 连接。这靠的是路由分发 + 后端调度能力，而非切换协议。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- HTTP/2 连接一旦建立，会复用到底层 TCP 连接，协议版本由 TLS ALPN 协商决定（通常在 SSL 握手时定死），后续所有请求都在该连接上多路复用，无法中途变更
- 你真正能动态控制的，是 proxy_pass 目标、upstream 成员、rewrite 规则 或 条件变量（map/geo）
- 这些路由逻辑修改后，只需
nginx -s reload，已存在的 HTTP/2 连接不受影响，新请求立即按新规则转发
升级中安全切换核心路由的实操方式
以“将 /payment 路径灰度切到新支付服务”为例：
-
用 map 定义动态上游变量：在 http 块中定义
map $request_uri $payment_backend {<br> ~^/payment/.* "new-payment-cluster";<br> default "legacy-payment-cluster";<br>}
再在 location 中：proxy_pass http://$payment_backend; -
upstream 分离管理：把新旧后端分别写进独立文件，如
include /etc/nginx/upstreams/payment-legacy.conf;<br>include /etc/nginx/upstreams/payment-new.conf;
升级时只改 map 的匹配逻辑或更新 new 配置，reload 即可 -
配合健康检查自动剔除：为新 upstream 加入
check interval=3 rise=2 fall=3 timeout=1（需第三方模块），当新服务未就绪时自动跳过，避免 502
确保 HTTP/2 兼容性不被破坏
动态调整路由时，必须保障以下几点，否则可能意外降级到 HTTP/1.1 或报错：
- 所有 upstream 后端服务必须支持 HTTP/2（若 proxy_pass 到 HTTPS 后端，目标需启用 h2；若 HTTP 明文，则 Nginx 到后端仍是 HTTP/1.1，仅客户端到 Nginx 是 HTTP/2）
- SSL 配置中必须包含
http2且证书有效：listen 443 ssl http2;，禁用不安全的 TLS 版本（如 TLSv1.0） - 不要在 rewrite 或 if 块中错误覆盖
$scheme或$host，导致 proxy_pass 构造异常，引发 502 并中断复用连接
