proxy_pass 是 nginx 反向代理核心指令，通过 url scheme 适配 http/https、grpc/grpcs 等协议，不直接支持协议但依赖模块能力；需注意斜杠处理、ssl 验证、http/2 及 websocket 配置。
proxy_pass 是 Nginx 实现反向代理的核心指令，它决定请求被转发到哪个后端服务。它本身不直接“支持协议”，而是通过目标地址的 URL scheme（协议前缀）来适配不同后端协议，并依赖 Nginx 模块能力完成通信。
支持的协议类型与写法
Nginx 原生通过 proxy_pass 支持以下常见协议前缀：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
http:// 和 https://：最常用，转发至 HTTP 或 HTTPS 后端服务（如 Tomcat、Node.js、Spring Boot 应用）。Nginx 默认使用 HTTP/1.1，可配合
proxy_http_version 1.1和proxy_set_header Connection ""保持长连接。 -
fastcgi://：需搭配
fastcgi_pass指令（非 proxy_pass），但常被混淆；真正用于 PHP-FPM 等 FastCGI 后端，属于独立协议栈。 -
grpc:// 和 grpcs://：自 Nginx 1.13.10 起支持 gRPC 反向代理，需启用
ngx_http_grpc_module。适用于微服务间基于 Protocol Buffers 的 RPC 通信。 -
uwsgi://：需
uwsgi_pass指令，专用于 uWSGI 协议（如 Django、Flask 应用），不属于 proxy_pass 范畴。 -
未带协议前缀（如
proxy_pass 127.0.0.1:8000）：默认按http://处理，等价于http://127.0.0.1:8000。
实际应用场景匹配
不同协议前缀对应典型部署模式：
-
Web 应用网关：用
proxy_pass https://backend.example.com统一 TLS 终止，后端走内网 HTTP，兼顾安全与性能。 -
动静分离架构：静态资源由 Nginx 直接 serve，动态 API 请求（如
/api/）通过proxy_pass http://app_cluster转发至 upstream 服务组。 -
gRPC 服务暴露：前端浏览器调用 REST API，内部服务间用 gRPC；Nginx 以
proxy_pass grpcs://grpc-service:50051代理加密 gRPC 流量，支持健康检查与负载均衡。 -
多协议共存网关：同一 server 块中，用不同 location 区分协议路径——例如
location /v1/转发 HTTP，location /grpc/转发 gRPC，实现协议路由。
关键注意事项
使用时需关注几个易错点：
- URL 末尾斜杠影响路径重写：
proxy_pass http://backend/会剥离 location 匹配部分；proxy_pass http://backend;（无斜杠）则原样拼接，容易导致 404。 - HTTPS 后端需显式开启 SSL 验证：
proxy_ssl_verify on并配置 CA 证书，否则默认跳过校验。 - gRPC 要求 HTTP/2 支持，需在 listen 指令中启用
http2，且客户端必须使用 h2 协议发起连接。 - 不支持直接代理 WebSocket over HTTP/1.1 以外的协议；若需 WebSocket，须设置
proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade等头字段。
