In traditional proxy platforms like TMG 2011, high availability (HA) meant:
- Multiple proxy servers
- Load balancing (NLB)
- Array membership
- Node-level failover
If one proxy failed, another took over.
Zscaler works differently.
Zscaler is a cloud-native service, so you don’t manage proxy nodes at all. Zscaler handles platform availability internally across multiple data centers.
Your responsibility for HA shifts to how users and networks reach the service.
What High Availability Really Means in Zscaler
1. Redundant Internet Connectivity
HA starts at your edge:
- Dual ISPs
- Redundant edge routers/firewalls
- Automatic failover between circuits
If users can’t reach the internet, they can’t reach Zscaler.
2. Multiple Traffic Steering Methods
Zscaler supports several ways to forward traffic:
- Client Connector (endpoint-based)
- GRE tunnels
- IPsec tunnels
- PAC files
Best practice:
Use at least two steering paths where possible.
Example:
- Primary: Client Connector
- Backup: PAC file or local breakout
3. Tunnel Redundancy (for Sites & Data Centers)
For GRE or IPsec-based forwarding:
- Configure multiple tunnels per site
- Terminate tunnels in different Zscaler cloud locations
- Use priority or ECMP where supported
If one tunnel or cloud location becomes unavailable, traffic automatically reroutes.
4. Endpoint-Level Resilience (Client Connector)
The Zscaler Client Connector:
- Automatically discovers the nearest healthy Zscaler service edge
- Fails over silently if a service edge is unreachable
- Continues enforcing policies without user intervention
This eliminates the “proxy node down” problem common with TMG.
5. Identity & Authentication HA
Authentication is also part of availability:
- Multiple IdPs (primary/secondary)
- Cached user authentication on endpoints
- Graceful fallback if IdP is temporarily unavailable
Users stay productive even during identity outages.
6. DNS Resilience
DNS is often overlooked:
- Redundant DNS resolvers
- Correct split-DNS configuration
- Avoid single-point DNS dependency
Broken DNS = broken access, even if Zscaler is healthy.
Key Mindset Shift: TMG vs Zscaler HA
| TMG Thinking | Zscaler Thinking |
|---|---|
| Proxy servers | Cloud service edges |
| NLB arrays | Global service fabric |
| Node failover | Path & tunnel failover |
| Local capacity planning | Elastic cloud capacity |
| Manual failover | Automatic service selection |
Real-World Example (Doha-Based Enterprise)
An enterprise in Doha migrated from a TMG array to Zscaler ZIA:
Before (TMG):
- 2 proxy servers in NLB
- Manual maintenance windows
- User impact during patching
After (Zscaler):
- Dual ISP links
- Client Connector + backup PAC
- Two GRE tunnels per site to different Zscaler locations
Result:
- No proxy downtime
- Maintenance without user disruption
- Improved resilience during ISP outages
The Golden Rule of Zscaler HA
If traffic can reach the internet through more than one path, Zscaler will remain available.
HA is no longer about “keeping a box alive” —
it’s about designing resilient paths to the cloud.