Proxy Protocol support in OpenSIPS 4.0

Modern SIP infrastructures increasingly rely on load balancers, reverse proxies and cloud edge services in order to provide scalability, security and geographic distribution. While these components are extremely useful, they often hide the original source address of the client from the backend SIP infrastructure.

Starting with OpenSIPS 4.0, we are introducing support for the Proxy Protocol, allowing OpenSIPS to transparently receive and forward the original client addressing information even when connections pass through intermediate proxies.

Proxy Protocol

The Proxy Protocol was originally developed by HAProxy Technologies for HAProxy, as a lightweight method for proxies and load balancers to forward the original client IP address and port to backend servers.

Instead of relying on application-level headers (which may not exist or may not be trusted), Proxy Protocol prepends a small header to the transport connection. This header contains metadata about the original connection, including:

• client IP address
• client port
• destination IP and port
• transport family

Today, Proxy Protocol is widely supported across modern infrastructure platforms and is used by many large-scale services, including:

• Cloudflare
• Amazon Web Services
• Google Cloud
• Microsoft Azure
• load balancers such as HAProxy, NGINX or Envoy

The initial OpenSIPS implementation supports Proxy Protocol v1, both for incoming and outgoing connections, across the following transports:

• UDP
• TCP
• TLS
• WebSocket (WS)
• Secure WebSocket (WSS)

Inbound Connections

One common scenario involves running OpenSIPS behind a cloud edge service such as Cloudflare, which forwards TCP or TLS connections.

A simplified architecture might look like this:

Without Proxy Protocol, OpenSIPS only sees the Cloudflare IP address as the source of the connection. This makes it difficult to identify the real client behind Cloudflare, thus it is not able to:

• perform authentication
• apply IP-based routing policies
• detect abusive client

With Proxy Protocol enabled, Cloudflare prepends a header such as:

PROXY TCP4 203.0.113.10 198.51.100.5 50612 5061

OpenSIPS parses this header before processing the SIP message and extracts the connection metadata carried by the Proxy Protocol header. This information is made available to the routing script through the new $proxy_protocol variable, which exposes details about the original client connection (such as source and destination addressing). The SIP script and all modules can then use this information to make routing, logging or security decisions based on the real client endpoint, even though the connection itself originates from Cloudflare.

Outbound Connections

Proxy Protocol is also useful when OpenSIPS itself acts as a proxy or SBC, forwarding traffic to another SIP infrastructure component. For example:

This allows the upstream SIP platform to retain full visibility of the original client endpoint, even though the connection now originates from OpenSIPS.

Such deployments are especially common when OpenSIPS is used as an edge SBC, performing:

• NAT traversal
• TLS termination
• topology hiding
• security filtering

while still allowing upstream systems to make decisions based on the real client IP address.

Conclusions

With the introduction of Proxy Protocol support in OpenSIPS 4.0, SIP infrastructures can now integrate more easily with modern load balancers, edge proxies and cloud networking platforms.

By supporting Proxy Protocol v1 for both inbound and outbound connections, across TCP, TLS, WS, WSS and UDP, OpenSIPS allows operators to preserve the original client connection information even when traffic traverses multiple proxy layers.

This enables cleaner deployments behind cloud edge services and more transparent SBC architectures, while still allowing routing logic and security policies to rely on the real client endpoint.

Join us at the OpenSIPS Summit, 28 April-01 May 2026 in Bucharest to find out more about the new stuff in OpenSIPS 4.0!