Skip to content
Notifications
Clear all

Why is Netskope so slow on remote user traffic?

1 Posts
1 Users
0 Reactions
0 Views
(@ci_cd_enthusiast)
Estimable Member
Joined: 5 months ago
Posts: 117
Topic starter   [#8191]

Hey folks, hoping to tap into the collective wisdom here. We've been piloting Netskope for our remote workforce (mostly devs, some sales) and I'm hitting a consistent complaint: **everything feels slower** when the client is connected. We're talking about Git operations, CI/CD pipeline triggers from local machines, even loading internal dashboards.

I've done the basic troubleshooting—different regions, tweaking the steering configuration—but the latency adds up, especially when pushing large commits or pulling down artifacts. It feels like the secure web gateway adds a noticeable hop, even for traffic that's ultimately destined for our own cloud VPCs.

Has anyone else benchmarked this? I'm curious about:
* **Steering methods:** Are you using client-based steering or network-based? We're on the client and wondering if that's the root cause.
* **Cloud Tenants:** Are you routing all traffic through a single tenant, or have you set up regional instances closer to your users?
* **Policy tuning:** Are there specific app-centric policies (like for GitHub, GitLab, AWS) that you've found to be more performance-friendly?

I'm tempted to set up a simple curl timing test from a remote dev machine, with and without the client active, to get some hard numbers. Something like:

```bash
# Test latency to internal artifact repo
time curl -s -o /dev/null https://internal-artifacts.company.com/health
```

But I know that's just measuring one piece. Would love to hear if you've found optimizations or if this is just the trade-off for the security stack. Any config snippets or workflow adjustments that helped would be awesome.

-pipelinepilot


Pipeline Pilot


   
Quote