Backhaul Is the Bottleneck: How Cloud-Proxy SSE Slows Every Request (and What Fly-Direct Does Instead)
.jpeg)
The short answer
Cloud-proxy SSE has one structural bottleneck: backhaul. Every user request detours to a vendor data center to be inspected, then continues to its destination. That detour is the tax you pay on every single request, and it grows the further your users sit from a point of presence. Fly-direct removes the bottleneck by inspecting on the device, so traffic goes straight to its destination with no detour at all.
SSE runs on one of two architectures. Cloud-backhaul is the one with the bottleneck. Fly-direct is the one without it. This is the clearest way to understand why the same security controls can feel completely different depending on where they run.
Where the bottleneck comes from
Follow one request through a cloud proxy.
- The device sends the request to the vendor's nearest point of presence (PoP).
- The PoP decrypts the TLS session and inspects the contents.
- It opens a fresh connection to the real destination and forwards the request.
- The response comes back to the PoP.
- The PoP re-encrypts and returns it to the device.
Every step after the first exists only because inspection lives somewhere other than the device. The round trip to and from the PoP is the bottleneck. It is small when the user is close and the node is healthy. It grows with distance, congestion, and any filtering in the path.
Now the fly-direct path:
- The device inspects the request locally.
- The request goes straight to its destination.
Two steps instead of five, because there is no remote inspection point to visit. See what is backhauling.
The bottleneck by the numbers
Backhaul latency is not a rounding error. Representative figures from ThousandEyes and vendor documentation put the detour at roughly 40 to 80 ms when a user is near a PoP, and 150 to 400 ms when they are far from one. Through a filtered or restricted network the number climbs higher and becomes unpredictable.
| User location | Cloud-backhaul detour | Fly-direct |
|---|---|---|
| Near a point of presence | ~40 to 80 ms added | No network detour |
| Far from a point of presence | ~150 to 400 ms added | No network detour |
| Behind a filtered network | Highly variable, can fail | No remote hop to fail |
Those figures are per request. A modern web page makes dozens of requests. An app in active use makes thousands over a session. When each carries an extra 100 to 300 ms, the compounded effect is an internet that feels slow. Critically, it feels slowest for the people furthest from a PoP: remote workers, travelers, and international staff.
Why bandwidth cannot fix it
The most common misdiagnosis is treating slow SSE as a bandwidth problem. It is not. Bandwidth is about capacity, how much data can move at once. The backhaul bottleneck is about distance and detour, how far each request has to travel before it is allowed to continue. Adding bandwidth widens the road but does not remove the mandatory stopover. This is why "our internet feels slow" so often turns out to be an architecture symptom rather than a capacity one.
The bottleneck is not only latency
Backhaul creates three more costs that ride along with the detour.
Privacy. To inspect encrypted traffic, the proxy decrypts it. Your corporate plaintext then exists inside the vendor's cloud at the moment of inspection, sometimes in another jurisdiction. See on-device vs cloud SSL inspection.
Fragility in hard geographies. If the path to the PoP runs through a chokepoint like the Great Firewall, the backhaul hop degrades or fails, and the security fails with it. See why cloud-proxy SSE struggles in China.
Operational weight. Backhaul needs forwarding infrastructure: tunnels, PAC files, and connector meshes, all configured and maintained so traffic reaches the right node. That is real ongoing work.
How fly-direct removes the bottleneck
Fly-direct does not optimize the detour. It deletes it. dope.security runs a lightweight agent on the device that decrypts TLS locally, applies your policy, scans for threats and data leaks, and sends traffic straight to its destination. There is no PoP in the path, so there is no round trip to pay for.
The Fly-Direct Secure Web Gateway does SSL inspection, URL filtering, anti-malware, Cloud Application Control, and AI-powered Dopamine DLP on the endpoint, in under 100 MB of RAM, at up to 4x the performance of legacy proxy SWGs. Because decryption is local, corporate data never transits a vendor cloud. Because there is no remote hop, the model keeps working in restricted regions.
This is not "no cloud." Management, policy, analytics, and data-at-rest scanning stay in one cloud console with real-time policy push. Only the inspection of live traffic moves to the device, which is precisely the piece the bottleneck lives in.
What removing the bottleneck looks like in practice
Removing backhaul changes how a rollout feels because there is nothing to route. A Fortune 100 customer scaled the fly-direct agent from 900 to more than 18,000 devices in weeks. Outreach Health secured 99% of its fleet in a week and cut web-access tickets 70%. Greylock Partners moved off a legacy SSE and signed in 27 days. A Cisco Umbrella customer migrated 2,000 machines in two days. In each case there was no forwarding architecture to build, because fly-direct inspection has nothing to forward.
How to know if the bottleneck is hurting you
- Remote and international staff complain the internet feels slow, while office users do not.
- Your fastest apps still carry a floor of extra latency that bandwidth upgrades never remove.
- Users in restricted regions have connectivity that comes and goes.
- Your team spends real time maintaining PAC files, tunnels, or connectors.
If those sound familiar, the issue is architectural. Swapping one cloud proxy for another keeps the detour. Moving to fly-direct removes it. The honest test is to run fly-direct next to your current SWG for a week and watch the latency on real traffic.
For the wider architecture picture, see cloud-backhaul vs fly-direct, and for the raw math, the latency math of a cloud-proxy SWG.
Frequently asked questions
What is backhaul in SSE? Routing a user's traffic to a central inspection point, a vendor data center or point of presence, before it continues to its destination. The traffic detours instead of going direct.
Why is backhaul a bottleneck? Because it adds a mandatory round trip to every request. The detour grows with distance from a point of presence and cannot be removed by adding bandwidth.
Do all SSE vendors backhaul? Most cloud-proxy vendors do, including Zscaler, Netskope, Palo Alto Prisma Access, Cloudflare, Forcepoint, and Fortinet. dope.security is the fly-direct exception that inspects on the device.
Does fly-direct really add no latency? It adds no network detour, because there is no remote inspection point. On-device inspection itself is lightweight: dope.security runs at up to 4x the performance of legacy proxy SWGs.
Can I measure the backhaul tax myself? Yes. Measure your round-trip latency, then run fly-direct alongside your current SWG for a week and compare on real traffic.
See it in action
Want to see what your traffic does when the backhaul bottleneck is gone? Start a free trial or book a 20-minute demo at dope.security.
.jpg)
.jpg)
