Understanding Half Proxy Mode: A Comprehensive Guide

The term Half Proxy is commonly used informally to describe a traffic-processing architecture that provides less connection separation than a classic Full Proxy.
Unlike a classic Full Proxy, which independently manages a client-facing TCP connection and a separate server-facing TCP connection, a Half Proxy or flow-oriented device generally preserves more of the original traffic relationship while maintaining enough state to make forwarding, security, NAT, or load-balancing decisions.
The easiest way to remember the difference is:
Full Proxy
Independently manages the client-side and server-side connection sides.
Half Proxy / Flow-Oriented Processing
Maintains traffic state and applies forwarding or security decisions with less independent connection separation.
—

—

Understanding Half Proxy Architecture

A traditional Full Proxy can be represented conceptually as:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend Server
The Full Proxy independently owns and manages the two connection sides.
A flow-oriented or Half Proxy style architecture is different.
Conceptually:
Client → Stateful Intermediary → Backend Server
The intermediary is still in the traffic path, but it does not necessarily create the same independently controlled client-side and server-side TCP connections used by a classic Full Proxy.

Half Proxy Core Architecture

Half Proxy / Flow-Oriented Architecture

1Client2Traffic Flow3Stateful Intermediary4Traffic Flow5Backend Server

What the Intermediate Device May Do

Depending on the platform, it may:

• Track connection state

• Validate TCP flags

• Inspect the initial connection

• Perform NAT

• Apply ACL or firewall policy

• Select a backend server

• Apply connection limits

• Perform rate limiting

• Detect malformed traffic

• Apply Layer 4 policy

• Perform selected application inspection

The important concept is:
The device processes the flow without necessarily providing the same complete TCP separation as a Full Proxy.

Why Is It Called Half Proxy?

The term is useful conceptually because the intermediary may provide some proxy-like behavior while behaving more like a stateful forwarding device for other parts of the connection.
It may:
Act like a security intermediary
by:

• Tracking sessions

• Validating connection state

• Applying policy

• Selecting destinations

while avoiding some of the complete connection termination and recreation associated with a classic Full Proxy.

—

TCP, TLS and Application-Layer Behavior

TCP behavior is the most important technical difference between Full Proxy and flow-oriented processing.

TCP Connection Establishment

Consider a client connecting to:
10.10.10.100:443
The normal TCP handshake is:
Client → SYN
Server-side response path → SYN-ACK
Client → ACK
A flow-oriented intermediary may inspect and track this process.
For example, it can evaluate:

• Source address

• Destination address

• TCP port

• SYN state

• Security policy

• NAT requirement

• Backend selection

If the traffic is permitted, it continues through the device.

Half Proxy TCP Flow Processing

1Client2TCP SYN3Stateful Intermediary4State Validation5Security or Load-BalancingDecision6Backend Server7Return Traffic

What Happens After the Handshake?

Once the connection is established, the intermediary continues tracking the flow.
It may:

• Validate TCP state

• Apply NAT

• Maintain connection tables

• Enforce policy

• Apply QoS

• Count bytes and packets

• Apply rate limits

• Forward traffic

• Drop invalid traffic

This can generally require less processing than full application proxying.

TLS / HTTPS Behavior

A pure flow-oriented architecture does not automatically mean that TLS is terminated.
If TLS remains end-to-end:
Client → Encrypted TLS → Intermediary → Encrypted TLS → Server
the intermediary cannot normally read the decrypted HTTP payload simply from basic forwarding.
However, modern security products may separately provide TLS decryption capabilities.

HTTP and Layer 7 Processing

If the intermediary does not terminate or decrypt the application session, its ability to modify encrypted HTTP traffic is naturally limited.
A basic flow-oriented path generally cannot directly perform Full Proxy functions such as:

• Rewriting decrypted HTTP response bodies

• Modifying encrypted HTTP headers

• Manipulating application cookies inside undecrypted TLS

• Performing HTTP caching

• Performing content compression

However, vendor capabilities vary.
Modern platforms may provide:

• Application identification

• Protocol decoding

• TLS decryption

• Threat inspection

• URL filtering

• Application-aware policy

even when their primary forwarding architecture is flow based.

—

Half Proxy vs Full Proxy

The safest way to compare the two is by connection independence and processing depth.

Full Proxy

A classic TCP Full Proxy uses:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend
The proxy can independently manage:

• Client-side TCP

• Server-side TCP

• Retransmissions

• Window behavior

• Connection reuse

• Backend pooling

• TLS termination

• Layer 7 processing

Half Proxy / Flow-Oriented Processing

A flow-oriented intermediary generally provides:

• Connection-state tracking

• Forwarding

• NAT

• Security policy

• Basic or advanced inspection depending on platform

• Lower connection-processing overhead

• Less independent control of the two TCP sides

Side-by-Side Comparison

—

Real-World Examples

Vendor terminology differs considerably, so real-world examples must be described carefully.

F5 BIG-IP FastL4

F5 BIG-IP provides a FastL4 profile for efficient Layer 4 traffic processing.
FastL4 is designed for performance-oriented handling and can use hardware acceleration where supported.
Typical use cases include:

• Performance Layer 4 virtual servers

• Forwarding virtual servers

• High-throughput L4 traffic

• Traffic that does not require full-proxy TCP processing

Cisco Secure Firewall ASA

Cisco ASA performs stateful inspection.
The firewall tracks connection state and evaluates traffic according to security policy.
For a new connection, the ASA can evaluate information such as:

• Source

• Destination

• Protocol

• Port

• Connection state

• NAT

• ACL policy

Once the connection is permitted, subsequent packets can be processed according to the established connection state.

Palo Alto Networks NGFW

Palo Alto Networks uses traffic-flow processing together with technologies such as App-ID.
App-ID can identify applications using:

• Signatures

• Protocol decoding

• Behavioral characteristics

• Heuristics

This provides application awareness without requiring us to incorrectly label the entire platform as a Half Proxy.

FortiGate

FortiGate supports multiple security inspection approaches and features.
When discussing a FortiGate deployment, determine:

• Inspection mode

• Security profile

• TLS inspection

• Firewall policy

• Application Control

• IPS

• Proxy features

• FortiOS version

before deciding how the particular traffic flow behaves.

NGINX Stream

NGINX stream functionality can proxy TCP and UDP services.
A deployment might look conceptually like:
Client → NGINX Stream → Backend TCP Service
However, NGINX is itself acting as a proxy and its connection behavior must be evaluated according to the actual stream configuration.
Therefore, it should not automatically be grouped into a generic “Half Proxy” category without examining how the traffic is handled.

A10 Thunder ADC

A10 Thunder ADC supports high-performance Layer 4 and application-delivery capabilities.
The correct architectural description depends on:

• Virtual port configuration

• Service type

• SSL configuration

• Template configuration

• Traffic-processing feature

• ACOS version

—

Performance, Security and Use Cases

Flow-oriented processing is often selected when traffic does not require complete application proxying.

Potential Benefits

Lower Processing Overhead
Less connection and application-layer processing can reduce resource consumption.
High Throughput
Performance-oriented L4 processing can be optimized for large traffic volumes.
Lower Latency
Avoiding unnecessary application processing can reduce processing delay.
Stateful Security
The device can still maintain connection state and apply network security policy.
Efficient NAT and L4 Load Balancing
Flow-oriented architectures are well suited to many network-layer and transport-layer use cases.

Potential Limitations

Compared with a Full Application Proxy, a basic flow-oriented architecture may provide less native capability for:

• Independent TCP optimization

• Backend connection pooling

• HTTP manipulation

• Application caching

• Content compression

• TLS termination

• Full application proxying

However, additional platform features may add many of these capabilities.

Good Use Cases

A flow-oriented or performance Layer 4 design may be appropriate for:

• High-volume TCP traffic

• Layer 4 load balancing

• Stateful firewalling

• NAT

• High-throughput internal applications

• Low-latency services

• Simple connection distribution

• Traffic not requiring HTTP manipulation

When Full Proxy Is More Appropriate

Full Proxy is often preferable when you require:

• Independent client/server TCP optimization

• TLS termination

• TLS re-encryption

• WAF

• API security

• HTTP header manipulation

• Cookie processing

• URL-based routing

• Connection pooling

• Application acceleration

• Advanced Layer 7 controls

—

Troubleshooting Half Proxy / Flow-Oriented Traffic

Packet captures can help determine how a particular flow is being processed.

Step 1 — Identify the TCP Handshake

Look for:
SYN → SYN-ACK → ACK
Determine where each packet is observed.

Step 2 — Capture on Both Sides

Where possible, capture:

• Client side of intermediary

• Server side of intermediary

Compare the same connection.

Step 3 — Compare the 5-Tuple

Check:

• Source IP

• Destination IP

• Source port

• Destination port

• Protocol

NAT or load balancing may modify some fields.

Step 4 — Compare TCP Behavior

Check:

• Sequence numbers

• ACKs

• MSS

• Window size

• SACK

• Timestamps

• Retransmissions

Step 5 — Determine TLS Endpoint

Ask:
Who terminates TLS?
Possibilities include:

• Client and backend directly

• Load balancer

• Firewall

• Reverse proxy

• WAF

Step 6 — Check Retransmission Scope

Determine whether retransmissions are visible:

• Client side only

• Server side only

• Across the forwarded flow

• At both capture locations

Step 7 — Correlate Device State

Review:

• Session table

• Connection counters

• NAT translation

• Backend selection

• Firewall policy

• Drop counters

• CPU

• Memory

—

Common Questions

Does Half Proxy Always Use One TCP Session?

No.
That description is an oversimplification.
The exact TCP behavior depends on the implementation.
The more useful architectural distinction is whether the device independently manages client-side and server-side TCP connections like a classic Full Proxy.

Does Half Proxy Always Intercept the SYN?

Not necessarily in the same way across products.
Stateful devices normally track connection establishment, but SYN proxying, SYN cookies, delayed binding, hardware forwarding, and other features can change the behavior.

Can a Flow-Oriented Firewall Inspect Applications?

Yes.
Modern NGFWs can provide:

• Application identification

• IPS

• URL filtering

• Threat inspection

• TLS decryption

• User-based policy

depending on the platform and configuration.

Can a Flow-Oriented Device Perform TLS Decryption?

Yes, some platforms can.
TLS handling is a separate feature decision.
Do not infer TLS capability solely from the label “flow based.”

Is F5 FastL4 a Half Proxy?

F5 officially calls the feature FastL4 and describes it as an efficient Layer 4 processing profile.
It is useful for contrasting performance-oriented processing with F5 Full Proxy TCP processing, but it is safer to use F5’s official terminology than to redefine FastL4 as a universally standardized Half Proxy mode.

Is Cisco ASA a Half Proxy?

Cisco officially describes ASA as a stateful inspection firewall.
That terminology is more technically precise.

Is Palo Alto Networks a Half Proxy?

Palo Alto Networks NGFW uses its own traffic-processing architecture and App-ID application classification.
It should be described using Palo Alto Networks terminology rather than assigning the whole platform a generic Half Proxy label.

Is Flow Mode the Same as Half Proxy?

Not universally.
“Flow mode” is generally vendor-specific terminology.
Always verify what the vendor means by the mode.
—

Summary

Half Proxy is best treated as a conceptual description, not a universal vendor-standard feature.
The safest definition is:
Half Proxy / Flow-Oriented Processing
A traffic-processing architecture that maintains flow state and applies forwarding, security, NAT, or load-balancing decisions without necessarily providing the same independent client-side and server-side connection management as a classic Full Proxy.

Full Proxy

Think:
Client → TCP Connection 1 → Full Proxy → TCP Connection 2 → Backend
Key characteristic:
Independent connection management

Half Proxy / Flow-Oriented Processing

Think:
Client → Stateful Intermediary → Backend
Key characteristics:

• Traffic-state tracking

• Forwarding

• Security policy

• NAT

• Layer 4 processing

• Less independent connection separation

Final Comparison

—

Useful Links and References

SanchitGurukul Static Resources

Official External References