nginx 不支持网络层透明代理，其 http/2 代理是应用层反向代理；需配置 http2 监听、proxy_http_version 2 及 alpn 协商，并通过 map/rewrite 动态改写路径，透传原始 uri 与关键响应头以保障“透明感”。
Nginx 本身不支持网络层意义上的“透明代理”，HTTP/2 的后端代理也遵循这一原则：它做的是应用层反向代理，不是四层透明转发。所谓“动态路径的透明转换”，实际是指在 HTTP/2 连接下，客户端请求路径被 Nginx 动态改写（如重写、截断、添加前缀）后，再以 HTTP/2 协议原样转发给后端服务，且后端能正确识别原始意图——这需要兼顾协议兼容性、路径处理逻辑与头信息透传。
下面分三块讲清楚怎么做：
HTTP/2 代理基础配置要点
要启用 HTTP/2 后端代理，Nginx 必须满足两个前提：
- 前端监听使用
http2（仅限 HTTPS server 块） - 后端
proxy_pass目标需支持 HTTP/2，且必须用域名（不能用 IP 直连），并开启http2协议显式声明
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location /v1/ {
# 启用 HTTP/2 到后端（要求 upstream 支持 ALPN）
proxy_http_version 2;
proxy_pass https://backend-service/; # 注意末尾斜杠的作用
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
⚠️ 注意：proxy_http_version 2 不会自动升级连接，它依赖后端服务器在 TLS 握手时通过 ALPN 协商出 h2；若后端只支持 HTTP/1.1，Nginx 会自动降级，不会报错但失去 HTTP/2 优势。
动态路径转换的实现方式
“动态”意味着路径改写逻辑不是静态的，而是依据参数、变量或条件实时计算。Nginx 提供 rewrite + map + if（慎用）组合来支撑：
-
用
map预定义路径映射规则（推荐，高效且安全）map $arg_service $upstream_path { default "/api/"; "user" "/v2/users/"; "order" "/v3/orders/"; "report" "/internal/reports/"; } server { location /gateway/ { rewrite ^/gateway/(.*)$ $upstream_path$1 break; proxy_pass https://backend-cluster; proxy_http_version 2; } } -
用
rewrite+ 正则提取参数做路径拼接location /app/ { # 将 /app/{env}/{id} → /services/{env}/instance?id={id} rewrite ^/app/([^/]+)/(\d+)$ /services/$1/instance?id=$2 break; proxy_pass https://backend-api; proxy_http_version 2; } -
避免常见陷阱
-
rewrite ... last会引发内部重定向，可能丢失原始$args或触发二次解析，建议优先用break -
proxy_pass末尾带/时，Nginx 会剥离匹配的 location 路径前缀；不带/则原样拼接，务必统一风格 - HTTP/2 下不支持
chunked编码的响应体缓存，如需缓存请确保后端返回Content-Length
-
真实路径与头信息的“透明感”保障
所谓“透明”，核心是让后端像直连客户端一样获取必要上下文：
-
保留原始路径语义：用
X-Original-URI或自定义头透传proxy_set_header X-Original-URI $request_uri; proxy_set_header X-Forwarded-Path $uri;
-
强制透传关键响应头（默认 HTTP/2 会过滤部分头）
proxy_pass_header Server; proxy_pass_header Date;
-
禁用不必要的重写干扰
proxy_redirect off; # 防止后端 302 重定向地址被 Nginx 错误改写
不复杂但容易忽略
