Zscaler IP Ranges: How to Find, Allowlist, and Maintain Them
.jpeg)
Quick answer: Zscaler publishes its IP ranges per cloud at config.zscaler.com. The Zscaler Aggregate IP ranges live at config.zscaler.com/<cloud name>/cenr and the Hub IP ranges at config.zscaler.com/<cloud name>/hubs, split into Required and Recommended. You need them for firewall rules, upstream ACLs, and any SaaS app that restricts sign-ins by source IP. And because Zscaler keeps adding ranges as it expands, someone on your team owns this list forever.
Here's how to find the right list, what each one is for, how to stay ahead of changes, and what's different when web inspection runs on the device instead of in a vendor cloud. This post is part of our Zscaler admin guide.
Last updated: November 2026
Where to find Zscaler IP ranges
Start by knowing your cloud name. Zscaler runs several clouds, including zscaler.net, zscloud.net, zscalerone.net, zscalertwo.net, zscalerthree.net, and zscalerbeta.net, and each one has its own published ranges. Your cloud name is in your admin portal URL. Zscaler's help center also has a page on what your ZIA cloud name is.
Then use the config site:
- Aggregate IP ranges: config.zscaler.com/zscaler.net/cenr (swap in your cloud name).
- Hub IP ranges: config.zscaler.com/zscaler.net/hubs, listed as Required and Recommended.
- ZPA: Private Access has its own firewall allowlist section on the same config site, under your ZPA cloud.
Pull from these pages directly. Copies in wikis, gists, and threat-intel lists go stale fast.
Which list goes where
Most allowlist problems come from using the right ranges in the wrong place. Here's the practical mapping.
| What you're configuring | Zscaler list to use | Ongoing upkeep |
|---|---|---|
| Firewall policy and upstream ACLs | Hub IP ranges (allow everything under Required; Recommended covers broader ranges) | Update before each announced availability date |
| SaaS sign-in restrictions by source IP (conditional access, IP allowlists) | Aggregate IP ranges (cenr) | Re-sync in every SaaS app that holds a copy |
| Private app access (ZPA) | ZPA firewall allowlist section for your ZPA cloud | Separate list, separate owner in many teams |
| Partner and vendor allowlists (B2B portals, payment gateways) | Aggregate IP ranges | You depend on the partner to apply your updates |
That last row is the one that bites. When a range changes, you can update your own firewall in an afternoon. Getting a partner's change ticket through their queue takes longer.
Why the list keeps changing
Zscaler adds ranges as its cloud grows, and it tells you to update your rules before the new ranges go live. One recent example: a Zscaler support notification added 137.31.0.0/16 to both the Hub (Recommended) and Aggregate lists across zscaler.net, zscloud.net, zscalerone.net, zscalertwo.net, zscalerthree.net, zscalerbeta.net, and several ZDX and ZPA clouds, with availability on January 5, 2026 or later. The action required: "Update Your Firewall Policy Configuration" and any upstream ACLs (Zscaler support notification).
Miss a notice like that and the symptom rarely says "IP range." It shows up as intermittent connection failures, or a SaaS app suddenly prompting for MFA, or a partner portal rejecting logins. That's why IP range changes belong in your runbook next to outages. See Is Zscaler down? A status and outage runbook.
A maintenance checklist that actually holds up
- Subscribe to Zscaler support notifications and route them to a shared queue, not one person's inbox.
- Keep one source of truth. Pull ranges from config.zscaler.com on a schedule and diff them. Don't hand-copy.
- Inventory every place the ranges live: firewalls, cloud security groups, SaaS conditional access policies, partner allowlists.
- Allow Recommended where you can. Per Zscaler's notice, if the broader Recommended ranges are already allowed, a new addition inside them needs no action.
- Test before the availability date, not after users report it.
If you want the deeper story of how traffic gets to those IPs in the first place, read Zscaler ZIA architecture, explained. We won't repeat it here.
What changes when inspection runs on the device
In a cloud-proxy model, your users' traffic reaches the internet from the vendor's IP addresses, so the vendor's ranges become part of your security model. Every SaaS allowlist, partner ACL, and geo-based rule has to know about them.
dope.security takes a different path. The secure web gateway runs on the endpoint, and SSL inspection, URL filtering, and Cloud Application Control all happen on the device. Traffic flies direct from the device to its destination, with no stopover in a vendor data center. That's Fly Direct.
Two practical consequences:
- No vendor egress pool to track for web traffic. Sites see traffic arriving from the user's own connection, so you aren't re-syncing a vendor's CIDR list into every SaaS app. Your own firewalls still need whatever rules your network team sets for the agent's control-plane traffic.
- Source IP stops being your SaaS control. When users work from home, hotels, and coffee shops, a source-IP allowlist isn't a reliable signal anyway. Tenant-level control is. Cloud Application Control lets corporate accounts through and blocks personal ones on the same domain, wherever the user is.
The City of Visalia moved to dope.security for exactly this reason: once employees went mobile, perimeter-based rules stopped following them.
Book a 20-minute demo to see how policy follows the user instead of an IP range.
Frequently asked questions
Where can I find Zscaler IP ranges?
On config.zscaler.com, per cloud. Aggregate ranges are at /<cloud name>/cenr and Hub ranges are at /<cloud name>/hubs. ZPA has its own allowlist section.
What's the difference between Zscaler Hub and Aggregate IP ranges?
Hub ranges are the ones Zscaler asks you to allow in firewall policy and upstream ACLs, split into Required and Recommended. Aggregate ranges are the broader list typically used for SaaS and partner IP allowlists.
How often do Zscaler IP ranges change?
Whenever Zscaler expands its cloud. It announces additions through support notifications with an availability date, and asks customers to update rules before that date.
Do I need to allowlist IP ranges with dope.security?
Web traffic leaves from the user's own connection, so there's no vendor egress pool to sync into SaaS allowlists. Check with our team for any network rules the agent itself needs in your environment.
.jpeg)
.jpeg)
.jpeg)
