Introduction
Full Proxy architecture is widely used in modern ADCs, WAFs, API gateways, and cloud security platforms because it enables deep Layer-7 inspection, TLS termination, and advanced security enforcement.
However, Full Proxy fundamentally changes how traffic flows through the network.
This directly impacts three critical performance metrics:
- Latency
- Throughput
- CPU utilization
Understanding these impacts is essential when:
- Designing production architectures
- Sizing hardware or virtual appliances
- Troubleshooting performance issues
- Deciding between Full Proxy and L4 / Half Proxy modes
This article explains how and why Full Proxy affects latency, throughput, and CPU, using practical examples and architecture-level reasoning.
What Makes Full Proxy Different
A Full Proxy:
- Terminates client TCP
- Decrypts TLS
- Parses application payload
- Applies security and routing logic
- Creates a new server-side connection
This is very different from packet forwarding or L4 proxying.
Full Proxy does not forward packets — it rebuilds conversations.
📊 Diagram 1 – Full Proxy Traffic Processing Pipeline
Caption
Full Proxy introduces multiple processing stages that directly impact latency, throughput, and CPU usage.
1️⃣ Full Proxy Impact on Latency
Why Latency Increases in Full Proxy
Latency increases because Full Proxy introduces additional processing steps:
- TCP handshake termination
- TLS handshake and decryption
- Application parsing
- Security policy evaluation
- New backend connection
Each step adds micro-latency, which becomes visible under load.
Example: HTTPS Request Flow
| Mode | Request Path |
|---|---|
| L4 Proxy | Client → Server |
| Full Proxy | Client → Proxy → Server |
In Full Proxy:
- TLS handshake happens twice (client-side and server-side)
- Request is fully parsed before forwarding
Even with optimized hardware, this adds 1–5 ms per request.
Where This Matters Most
- High-frequency trading
- Low-latency APIs
- Real-time communications
- Gaming platforms
📊 Diagram 2 – Latency Comparison: Full Proxy vs L4
2️⃣ Full Proxy Impact on Throughput
Why Throughput Is Affected
Throughput depends on how many connections and packets per second a device can process.
Full Proxy:
- Parses every request
- Maintains session state
- Executes security logic per request
This limits:
- CPS (Connections Per Second)
- TPS (Transactions Per Second)
- SSL TPS (Encrypted sessions)
Example: 10 Gbps Traffic Scenario
| Mode | Achievable Throughput |
|---|---|
| L4 Proxy | Near line-rate |
| Full Proxy (with WAF) | Lower, CPU-bound |
The bottleneck is not bandwidth — it is processing capacity.
Common Throughput Killers
- Large HTTP headers
- JSON-heavy APIs
- High TLS handshakes
- Bot traffic
- Excessive logging
📊 Diagram 3 – Throughput Bottleneck in Full Proxy
3️⃣ Full Proxy Impact on CPU Utilization
Why Full Proxy Is CPU-Intensive
CPU is consumed by:
- TLS encryption/decryption
- HTTP parsing
- WAF rule execution
- Session tracking
- Logging and metrics
Unlike L4 forwarding, Full Proxy:
- Touches every packet at multiple layers
- Executes complex logic per request
Example: TLS Decryption Cost
| Feature | CPU Cost |
|---|---|
| TLS handshake | High |
| AES encryption | Medium |
| RSA/ECDHE | Very High |
| HTTP parsing | Medium |
| WAF rules | High |
This is why SSL TPS is often the first resource to exhaust.
Real-World Symptom
- CPU hits 80–90%
- Latency spikes suddenly
- New connections drop
- Existing sessions slow down
Performance Is Predictable (If Designed Correctly)
Full Proxy performance issues are not random — they are design-driven.
Key Sizing Metrics
- CPS
- SSL TPS
- Concurrent sessions
- Average request size
- Inspection depth
Ignoring these leads to:
- Under-sized platforms
- Unexpected bottlenecks
- False “proxy is slow” conclusions
Design Best Practices to Minimize Impact
Reduce Latency
- Enable TCP reuse
- Use TLS session resumption
- Offload crypto where possible
Improve Throughput
- Separate L4 and L7 traffic
- Avoid unnecessary inspection
- Disable verbose logging
Control CPU Usage
- Use hardware acceleration
- Tune WAF rules
- Limit inspection to required paths
Full Proxy Performance Sizing Checklist
This checklist helps you predict latency, throughput, and CPU impact before deploying Full Proxy.
🔢 1. Traffic Characteristics (Baseline)
✔ Peak concurrent connections
✔ New connections per second (CPS)
✔ Average session duration
✔ Average request size (KB)
✔ Response size distribution
✔ Burst vs steady traffic pattern
🔎 Why it matters:
Full Proxy maintains session state → concurrent sessions directly impact memory and CPU.
🔐 2. TLS / SSL Load
✔ TLS versions used (1.2 / 1.3)
✔ Cipher suites (RSA vs ECDHE)
✔ SSL TPS (handshakes per second)
✔ TLS session reuse enabled
✔ mTLS enabled (yes/no)
🔎 Why it matters:
TLS handshakes are CPU-expensive and often the first bottleneck.
🧠 3. Application Inspection Depth
✔ WAF enabled or disabled
✔ Number of WAF rules
✔ API schema validation enabled
✔ Bot mitigation enabled
✔ Request/response body inspection size limit
🔎 Why it matters:
More inspection = more CPU per request.
🌐 4. Throughput Expectations
✔ Expected peak bandwidth (Gbps)
✔ Requests per second (RPS)
✔ API-heavy vs page-heavy traffic
✔ HTTP/2 or HTTP/1.1 usage
🔎 Key Insight:
Throughput in Full Proxy is CPU-bound, not link-speed-bound.
🧮 5. CPU Capacity Planning
✔ CPU cores available
✔ TLS acceleration support (hardware/software)
✔ Max CPU threshold (recommended ≤ 70%)
✔ Headroom for traffic spikes
🔎 Rule of thumb:
Always keep 30% CPU headroom for spikes and failover.
💾 6. Memory & Session State
✔ Max concurrent sessions
✔ Session timeout values
✔ Persistence enabled (cookies, source IP)
✔ HA state sync enabled
🔎 Why it matters:
Each session consumes memory and HA sync bandwidth.
🔄 7. High Availability & Failover
✔ Active/Active or Active/Standby
✔ Session sync enabled
✔ Acceptable session loss during failover
✔ Asymmetric routing avoided
🔎 Common pitfall:
Failover without state sync = dropped sessions.
📜 8. Logging & Telemetry
✔ Access logs enabled
✔ Security logs enabled
✔ SIEM forwarding enabled
✔ Log rate limits configured
🔎 Why it matters:
Logging can silently consume CPU + disk I/O.
🎯 Final Sizing Decision Rule
If any of the following is true:
- SSL TPS is high
- WAF rules are heavy
- API traffic is dominant
- Bot traffic is expected
👉 Size for CPU first, bandwidth second.
Summary
| Metric | Full Proxy Impact |
|---|---|
| Latency | Slightly higher |
| Throughput | CPU-bound |
| CPU | High utilization |
Full Proxy trades raw speed for intelligence and security.
This trade-off is acceptable — and necessary — for:
- Web applications
- APIs
- Internet-facing services
- Security-critical workloads
If you need to understand the traffic, Full Proxy is worth the cost.
Useful Links
https://www.youtube.com/@sanchitgurukul
