Understanding Full Proxy Mode: Benefits and Architecture

—
Full Proxy Mode is a traffic-processing architecture in which an intermediary independently manages the client-facing and server-facing sides of a communication.
For a classic TCP Full Proxy, the fundamental architecture is:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend Server
The client establishes one TCP connection with the Full Proxy.
The Full Proxy independently establishes and manages another TCP connection toward the backend server.
Because the two sides are independently managed, the proxy can provide significantly more connection and application control than simple packet forwarding.
Depending on the product and configuration, a Full Proxy may provide:

• Independent TCP connection management

• TCP optimization

• TLS termination

• TLS re-encryption

• HTTP inspection

• Layer 7 routing

• Load balancing

• WAF integration

• API security

• Connection pooling

• Header manipulation

• Cookie processing

• Backend health monitoring

• Persistence

• Application acceleration

—

Introduction and Core Architecture

The defining characteristic of a Full Proxy is independent connection control.
The proxy acts as an endpoint toward the client and separately communicates with the backend server.

Client-Side Connection

The client communicates with the proxy.
For example:
Client → Full Proxy VIP
The proxy can independently manage client-side characteristics such as:

• TCP handshake

• TCP MSS

• TCP receive window

• TCP options

• Retransmissions

• Connection timeout

• TLS negotiation when enabled

Server-Side Connection

The Full Proxy separately communicates with the backend server.
For example:
Full Proxy → Backend Server
The server-side connection can have different:

• Source IP

• Source port

• TCP sequence space

• MSS

• Window behavior

• Connection timeout

• TLS version

• Cipher configuration

Simple Connection Example

Assume the following addresses:

• Client: 192.168.10.25

• Full Proxy VIP: 203.0.113.10

• Full Proxy server-side address: 10.10.10.5

• Backend Server: 10.10.10.50

The client-side connection may look like:
192.168.10.25:51000 → 203.0.113.10:443
The server-side connection may independently look like:
10.10.10.5:42000 → 10.10.10.50:443

—

How Full Proxy Works

A classic TCP Full Proxy handles the client-facing and server-facing connections separately.

Client-Side TCP Handshake

The client initiates a TCP connection toward the Full Proxy VIP.
The expected handshake is:

1. Client sends SYN.
2. Full Proxy sends SYN-ACK.
3. Client sends ACK.

The client-side TCP connection is now established.

Client → Full Proxy     SYN
Full Proxy → Client     SYN-ACK
Client → Full Proxy     ACK

Server-Side TCP Handshake

The Full Proxy separately establishes a connection toward the selected backend server.
The expected handshake is:

1. Full Proxy sends SYN.
2. Backend sends SYN-ACK.
3. Full Proxy sends ACK.

Full Proxy → Backend     SYN
Backend → Full Proxy     SYN-ACK
Full Proxy → Backend     ACK

Are Both Connections Created at the Same Time?

Not necessarily.
Depending on the implementation and configuration, the Full Proxy may:

• Delay backend connection establishment

• Select a backend after receiving application information

• Reuse an existing backend connection

• Maintain backend connection pools

• Retry another backend

• Use different TCP profiles on each side

• Apply different idle timeouts

Connection Pooling and Reuse

Some Full Proxy platforms can maintain backend connections independently from client connections.
For example:
Multiple client connections may be serviced using a smaller or separately managed set of backend connections when the application protocol and product support that behavior.
This can reduce backend connection establishment overhead.
—

TCP, TLS and Layer 7 Processing

Full Proxy architecture becomes particularly powerful when application-layer processing is enabled.

Independent TCP Behavior

Because the proxy owns separate TCP state on each side, it can potentially use different settings.
Client Side

• Internet-optimized TCP behavior

• WAN-oriented settings

• Larger latency tolerance

• Client-specific MSS

• Client-specific receive window

Server Side

• Data-center-optimized TCP behavior

• Backend connection reuse

• Different MSS

• Different window behavior

• Lower-latency server communication

Retransmission Isolation

Suppose packet loss occurs between the client and the Full Proxy.
The client-side TCP connection may experience retransmissions.
The server-side TCP connection does not necessarily experience the same retransmission because it maintains separate TCP state.
Similarly, packet loss between the Full Proxy and backend can be handled independently on the server-facing side.

TLS Termination

For HTTPS traffic, the Full Proxy can terminate TLS when configured to do so.
The architecture can be:
Client → TLS → Full Proxy → TLS → Backend Server
The client-side and server-side TLS sessions can be independent.
For example:
Client Side: TLS 1.3
Server Side: TLS 1.2

TLS Offloading

Another possible architecture is:
Client → HTTPS → Full Proxy → HTTP → Backend
In this design, TLS terminates at the Full Proxy.

Layer 7 HTTP Processing

When HTTP traffic is available for processing, a Full Proxy can potentially inspect:

• HTTP method

• Host header

• URI

• Cookies

• Request headers

• Response headers

• Content type

• HTTP status

• Request body

• Response body

depending on the product and enabled features.

Request-Side Functions

Possible functions include:

• Host-based routing

• URI-based routing

• Header insertion

• Header removal

• Cookie processing

• Authentication

• WAF inspection

• API security

• Rate limiting

Response-Side Functions

Possible functions include:

• Header modification

• Cookie modification

• Compression

• Caching

• Response inspection

• Security-header insertion

—

Real-World Enterprise Example

Consider an e-commerce application:
https://shop.example.com
The environment contains:

• Public VIP: 203.0.113.10

• Full Proxy ADC/WAF

• Web Server 1: 10.10.10.11

• Web Server 2: 10.10.10.12

• Web Server 3: 10.10.10.13

• Client-side TLS

• Backend TLS

• WAF

• Health monitoring

• Load balancing

Step 1 — Client Connects to the VIP

The customer opens:
https://shop.example.com
The client creates:

192.168.10.25:51000 → 203.0.113.10:443

The Full Proxy completes the client-facing TCP handshake.

Step 2 — TLS Is Established

The client negotiates TLS with the Full Proxy.
For example:

TLS Version: TLS 1.3
SNI: shop.example.com
ALPN: h2

Step 3 — HTTP Request Arrives

After TLS processing, the proxy receives the application request.

GET /products/laptop HTTP/2
Host: shop.example.com

Step 4 — Security Policy Is Applied

The proxy or integrated security engine may check:

• URI

• HTTP method

• Headers

• Cookies

• Request body

• WAF signatures

• Rate limits

• Bot policy

Step 5 — Backend Health Is Checked

Assume the health status is:

10.10.10.11     UP
10.10.10.12     UP
10.10.10.13     DOWN

The proxy excludes the unhealthy server.

Step 6 — Backend Is Selected

The proxy selects:
10.10.10.12

Step 7 — Server-Side Connection Is Used

The backend-side TCP connection may look like:

10.10.10.5:42000 → 10.10.10.12:443

This is independent from the client-side connection:

192.168.10.25:51000 → 203.0.113.10:443

Step 8 — Backend Processes the Request

The backend returns:

HTTP/1.1 200 OK
Content-Type: text/html

Step 9 — Proxy Processes the Response

Depending on configuration, the proxy may:

• Apply response security policy

• Add or remove headers

• Modify cookies

• Compress content

• Cache eligible content

Step 10 — Response Returns to the Client

The Full Proxy sends the response over the existing client-facing connection.

—

Benefits, Limitations and Troubleshooting

Full Proxy architecture provides significant control, but it also introduces additional processing requirements.

Major Benefits

Independent TCP Control
The proxy can independently manage TCP behavior on both sides.
Application Visibility
When the application protocol is available for inspection, the proxy can make Layer 7 decisions.
TLS Termination
Client-side TLS can terminate at the proxy.
TLS Re-Encryption
A separate encrypted connection can be established toward the backend.
Advanced Load Balancing
Backend selection can use:

• Health

• Load

• Persistence

• Application information

• Connection count

WAF and API Security
Application security can be integrated when supported.
Connection Pooling
Backend connections can potentially be reused according to protocol and platform capability.
Backend Protection
Public users normally communicate with the proxy VIP rather than directly with individual backend servers.

Limitations

Packet Capture Troubleshooting

When troubleshooting a Full Proxy, capture on both sides whenever possible.

Client-Side Capture

You may observe:

192.168.10.25 → 203.0.113.10     SYN
203.0.113.10 → 192.168.10.25     SYN-ACK
192.168.10.25 → 203.0.113.10     ACK

Server-Side Capture

Separately:

10.10.10.5 → 10.10.10.12     SYN
10.10.10.12 → 10.10.10.5     SYN-ACK
10.10.10.5 → 10.10.10.12     ACK

What to Compare

Check:

• Source IP

• Destination IP

• Source port

• Destination port

• TCP sequence behavior

• ACKs

• MSS

• Window size

• Retransmissions

• TLS handshake

• Connection timing

Common Symptoms

—

Vendor and Implementation Considerations

Full Proxy architecture is commonly associated with application delivery and reverse proxy platforms, but vendor behavior must be described according to actual configuration.

F5 BIG-IP

F5 BIG-IP is a well-known example of Full Proxy application delivery.
Depending on configuration, it can independently manage client-side and server-side TCP behavior.
Capabilities may include:

• TCP profiles

• TLS termination

• Server-side TLS

• HTTP processing

• Load balancing

• Persistence

• Application routing

F5 also supports other traffic-processing modes such as FastL4.
Therefore, not every BIG-IP virtual server should automatically be described as using identical Full Proxy behavior.

A10 Thunder ADC

A10 Thunder ADC provides Layer 4–7 application-delivery capabilities.
Actual behavior depends on:

• Virtual port

• Service type

• Templates

• TLS configuration

• ACOS version

• Enabled features

NetScaler

NetScaler can provide:

• Reverse proxying

• Load balancing

• TLS processing

• Content switching

• Persistence

• Application routing

• Application security

Actual connection behavior depends on the configured virtual service and feature set.

NGINX

NGINX can operate as an HTTP Reverse Proxy.
For example:

server {
    listen 443 ssl;
    server_name www.example.com;

    location / {
        proxy_pass http://backend_pool;
    }
}

The client communicates with NGINX while NGINX separately communicates with the configured upstream application servers.

Cloud Reverse Proxies

Cloud application-delivery services may use proxy-based architectures such as:
Client → Cloud Proxy → Origin Server
Depending on the provider and service, capabilities may include:

• TLS termination

• WAF

• CDN

• DDoS protection

• Bot management

• Caching

• Origin protection

—

Summary

Full Proxy architecture provides independent control over the client-facing and server-facing sides of communication.
For classic TCP Full Proxy architecture:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend Server
The two TCP connections maintain independent connection state.
This enables capabilities such as:

• Independent TCP optimization

• TLS termination

• TLS re-encryption

• Application inspection

• Layer 7 routing

• WAF

• API security

• Connection pooling

• Backend health monitoring

• Intelligent load balancing

Key Technical Concept

The most important characteristic is:
The Full Proxy independently manages client-facing and server-facing connection state.
This is what differentiates classic Full Proxy architecture from basic packet forwarding and many stateful flow-oriented architectures.

Full Proxy in a Real Application

For an HTTPS application:
Customer → Full Proxy ADC/WAF → Backend Servers
the proxy can:

1. Accept the client TCP connection.
2. Establish client-side TLS when configured.
3. Inspect the application request.
4. Apply security policies.
5. Select a healthy backend.
6. Establish or use an independent server-side connection.
7. Send the request to the backend.
8. Receive the backend response.
9. Process the response.
10. Return the response to the client.

—

Useful Links and References

SanchitGurukul Static Resources

Official External References