Your script is solid for showing the symptom, latency spikes on internal apps. That's exactly where Netskope can feel clunky.
A key setting that helped us was using tenant steering policies to tag internal app domains and set them to a local POP, or even bypass heavy inspection tiers entirely. This is separate from the regular policy exceptions, it's more about controlling the initial route before any security modules kick in.
The trade-off is you might lose some of that impressive security logging for those flows, but sometimes the user experience win is worth it, especially on low-risk internal tools. Did you notice if your test traffic was all getting routed to the same distant POP?
Always optimizing.
You've hit on the architectural reality. That initial steering decision is based on policy assignment, not per-packet content, so the long route is baked in from the start.
A more dynamic scan would require a local POP to have all the licensed inspection engines, which defeats the purpose of their centralized, cost-efficient hub model. I haven't seen a vendor that truly does dynamic re-steering mid-session without breaking the TLS tunnel.
Your best bet is what user1433 hinted at: use tenant steering to assign those internal or critical-performance app domains to a local POP with a reduced inspection profile. You're right, it feels like you're disabling the product, but sometimes it's the only way to make a business app usable.
catdad
Yeah, that's the part that confused me too at first! It really is the miles on the wire that hurt.
> wouldn't the traffic for *other* file types be allowed to stay on the local POP?
From what I've been testing, it seems the answer is no. The initial decision on where to send the traffic is based on the most powerful security rule you have attached to that app, not what's actually in the packets. So if DLP is turned on for Salesforce at all, everything goes to the big inspection POP first, even simple web requests.
I guess that's why they have those tenant steering policies everyone's mentioning? To sort of pre-categorize traffic before the heavy rules kick in. But it feels like a workaround. Does this mean all the fancy "zero trust" stuff adds latency by default, just from the rerouting?
Your latency test script is exactly what I used to prove the problem to our network team. Those spikes are real.
The comments about tenant steering policies are spot on. That's the main knob you have. What helped us most was creating a separate policy for our internal apps, tagging them with a "LowRisk-Internal" label, and steering that label to a local POP with only basic URL filtering and threat protection enabled (no DLP or full TLS decrypt). It cut our latency on those apps by over 150ms.
The clunky connector feeling might not go away completely though. It's a trade-off for that deep security stack. If most of your traffic is to internal apps, that trade-off can feel pretty heavy. Did you test if the drops during SSO were from timeouts due to that extra routing hop?
Dashboards or it didn't happen.