现代 SIP 基础设施越来越依赖负载均衡器、反向代理和云边缘服务来实现可扩展性、安全性和地理分布。虽然这些组件非常有用，但它们通常会对后端 SIP 基础设施隐藏客户端的原始源地址。
从 OpenSIPS 4.0 开始，官方引入了对代理协议（Proxy Protocol）的支持，即使连接经过中间代理，OpenSIPS 也能透明地接收和转发原始客户端寻址信息。
代理协议
代理协议最初由 HAProxy Technologies 为 HAProxy 开发，作为一种轻量级方法，用于代理和负载均衡器将原始客户端 IP 地址和端口转发到后端服务器。
代理协议不依赖应用层标头（这些标头可能不存在或不可信），而是在传输连接前添加一个小型标头。该标头包含有关原始连接的元数据，包括：
- 客户端 IP 地址
- 客户端端口
- 目标 IP 和端口
- 运输家族
如今，代理协议已在现代基础设施平台上得到广泛支持，并被许多大型服务所采用，其中包括：
- Cloudflare
- 亚马逊网络服务
- Google Cloud
- Microsoft Azure
- 负载均衡器，例如 HAProxy、NGINX 或 Envoy。
初始 OpenSIPS 实现支持代理协议 v1，包括入站和出站连接，支持以下传输方式：
- UDP
- TCP
- TLS
- WebSocket（WS）
- Secure WebSocket (WSS)
入站连接
一种常见场景是将 OpenSIPS 部署在 Cloudflare 等云边缘服务之后，该服务负责转发 TCP 或 TLS 连接。
简化架构示意如下：
如果没有代理协议，OpenSIPS 只能将Cloudflare 的 IP 地址视为连接的来源。这使得识别 Cloudflare 背后的真实客户端变得困难，因此它无法：
- 执行身份验证
- 应用基于 IP 的路由策略
- 检测滥用客户
启用代理协议后，Cloudflare 会在请求头前添加类似这样的信息：
PROXY TCP4 203.0.113.10 198.51.100.5 50612 5061OpenSIPS 在处理 SIP 消息前会解析此报头，并提取代理协议报头携带的连接元数据。这些信息通过新增的 $proxy_protocol 变量提供给路由脚本，该变量揭示原始客户端连接的详细信息（如源地址和目标地址）。即便连接本身源自 Cloudflare，SIP 脚本及所有模块均可利用这些信息，基于真实客户端端点进行路由、日志记录或安全决策。
出站连接
当OpenSIPS 本身充当代理或 SBC（服务边界控制器）的角色，将流量转发到另一个 SIP 基础架构组件时，代理协议也很有用。例如：
即使连接现在源自 OpenSIPS，上游 SIP 平台也能完全了解原始客户端端点。
当 OpenSIPS 用作边缘 SBC时，这种部署方式尤为常见，其功能包括：
- NAT穿越
- TLS终止
- 拓扑隐藏
- 安全过滤
同时仍然允许上游系统根据真实的客户端 IP 地址做出决策。
结论
随着OpenSIPS 4.0引入代理协议支持，SIP 基础设施现在可以更轻松地与现代负载均衡器、边缘代理和云网络平台集成。
OpenSIPS通过支持TCP、TLS、WS、WSS 和 UDP的入站和出站连接的代理协议 v1 ，允许运营商即使在流量经过多个代理层时也能保留原始客户端连接信息。
这使得云边缘服务背后的部署更加清晰，SBC 架构更加透明，同时仍然允许路由逻辑和安全策略依赖于真正的客户端端点。
内容来源：https://blog.opensips.org/2026/02/24/proxy-protocol-support-in-opensips-4-0/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/65060.html
