proxy_pass仅转发HTTP/HTTPS请求，不实现协议转换；AJP需第三方模块支持；FastCGI/uWSGI由专用指令fastcgi_pass/uwsgi_pass处理，与proxy_pass并列且互不替代。
proxy_pass 本身不实现协议桥接，它只是将请求按原始协议转发给后端。所谓“不同协议桥接”，实际是 Nginx 在客户端与后端之间分别使用不同协议栈完成通信，靠的是模块能力与配置协同，而非 proxy_pass 指令自身转换协议。
HTTP → HTTP/HTTPS 的透明转发
这是最常见场景。Nginx 接收客户端的 HTTP 或 HTTPS 请求，再以 HTTP 或 HTTPS 协议向后端发起新连接。
- 若后端地址写为 http://127.0.0.1:8080，Nginx 用 HTTP 协议连接后端
- 若写为 https://127.0.0.1:8443，Nginx 自动启用 SSL/TLS，与后端建立 HTTPS 连接
- 需注意：后端 HTTPS 服务必须可被 Nginx 验证（提供有效证书或配置 ssl_verify off）
- 证书校验相关指令如 ssl_trusted_certificate、ssl_verify_depth 可控制验证行为
HTTP → AJP 的代理需额外模块支持
Nginx 官方不内置 AJP 协议支持。要实现 HTTP 请求经 Nginx 转发为 AJP 协议给 Tomcat，必须借助第三方模块（如 nginx-ajp-module）或改用 Apache httpd（原生支持 mod_proxy_ajp）。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 标准 Nginx 编译不含 AJP 处理逻辑，proxy_pass 写 ajp:// 地址会报错
- 启用 AJP 桥接需重新编译并加载对应模块，且配置语法与常规 proxy_pass 不同
- 生产环境更推荐保持协议一致：前端 HTTPS → Nginx → 后端 HTTP（通过防火墙或内网保障安全）
HTTP → FastCGI / uWSGI 属于应用层协议适配
这类不是“桥接”，而是 Nginx 通过专用模块（fastcgi_pass / uwsgi_pass）与对应语言运行时通信，属于明确划分的协议适配，不走 proxy_pass。
- fastcgi_pass 指向 PHP-FPM 的 socket 或地址，使用 FastCGI 二进制协议
- uwsgi_pass 对应 uWSGI 服务器，使用 uWSGI 自有协议
- 它们与 proxy_pass 并列存在，互不替代；不能用 proxy_pass 转发到 .sock 文件
- 协议细节由对应模块封装，无需手动处理编码或帧格式
协议转换不在 Nginx 核心职责范围内
Nginx 的设计哲学是高效转发与边缘处理，而非深度协议翻译。真正需要跨大版本协议转换（如 HTTP/1.1 ↔ HTTP/2 ↔ gRPC）时，应考虑：
- gRPC 服务暴露：用 grpc_pass（需 NGINX Plus 或开源版 1.13.10+ 启用 gRPC 模块）
- WebSocket 升级：通过 Upgrade / Connection 头透传，配合 proxy_http_version 1.1
- 避免在 Nginx 层做 HTTP ↔ TCP、HTTP ↔ MQTT 等非标准转换，容易引入不可靠性
