How to temporarily bypass specific DCs for Road Warriors running ZCC

Updated: Jan-5-2023

Zscaler has a number of options when customers want to bypass specific DCs for their Road Warriors. The recommended solution is to use Subclouds and remove the DC.

You can find more information on Subclouds here. As of v6.2+, customers can manage their own Subclouds in the ZIA AdminUI and no longer need to open a case with Zscaler support to make changes. This is the recommended long term approach.

Another approach is to use an App Profile PAC for situations where you may want to avoid a specific DC or a specific VIP for a short period of time.


  • This bypass method is meant for web traffic (80/443) over Z-Tunnel 1.0 only

  • This method is also applicable for customers using Z-Tunnel 2.0 with the new “Redirect Web Traffic to ZCC Proxy” feature enabled + “Use Z-Tunnel 2.0 for Proxied Web Traffic” feature disabled which results in Z-Tunnel 1.0 being used for web traffic. This is used in situations where customers need to bypass destinations for non proxy-aware Windows applications.

  • In other scenarios where Z-Tunnel 2.0 is in use, Zscaler recommends the use of Subclouds

Configuration Steps:

In the below example, the Chicago DC will be bypassed and the secondary DC will be used instead.

  1. In order to bypass Chicago, find the Proxy hostnames to bypass using Zscaler Config for ZS3. In this case (ZS3) is in use and the hostnames are and

  2. Create a PAC file to bypass the Chicago DC by entering the Proxy names from step 2 above. Example PAC file shown below.

function FindProxyForURL(url, host) {

    var privateIP = /^(0|10|127|192\.168|172\.1[6789]|172\.2[0-9]|172\.3[01]|169\.254|192\.88\.99)\.[0-9.]+$/;
    var resolved_ip = dnsResolve(host);

    /* Don't send non-FQDN or private IP auths to us */
    if (isPlainHostName(host) || isInNet(resolved_ip, "","") || privateIP.test(resolved_ip))
        return "DIRECT";
    /* test with ZPA */
    if (isInNet(resolved_ip, "",""))
        return "DIRECT";
    /* Trust sites are directly accessible */
    var trust = /^trust\.(zscaler|zscalerone|zscalertwo|zscloud|zscalergov|zsfalcon|zdxcloud)\.(com|net)$/;
    if (trust.test(host))
        return "DIRECT";

    /* === Chicago DC Bypass ================ */
    var gateway_port = "${GATEWAY}";
    var gateway = gateway_port.replace(":80","");
    var chicago1 = dnsResolve("");
    var chicago2 = dnsResolve("");

	/* Bypass Chicago */	
	if ((gateway == chicago1)||
		    (gateway == chicago2))
    /* === End Bypass Section ================ */

    /* Default Traffic Forwarding. Forwarding to Zen on port 80, but you can use port 9400 also */
  1. Update the App Profile with the new PAC URL. Its best to use a new PAC URL as Zscaler Client Connector will enable it quicker can changing the contents of an existing PAC.

  2. Instead of sending web traffic to the Chicago DC, Zscaler Client Connector will now send traffic to the backup DC

  3. When you want to start using the Chicago DC again, replace the App Profile PAC URL with the original PAC URL and Zscaler Client Connector will start using the Chicago DC in the next 15 mins


Very nice article, too bad the support folks can’t provide this information, instead just say “failover to your secondary DC” and expect that the customers all know that intuitively.

1 Like

We had to do this recently when the CHI ZS2 DC was down. I wish Zscaler redirected traffic more quickly in these instances by removing DCs from GATEWAY and dropping IPSec tunnels. The trust page for ZIA and ZPA always says, “traffic has been rerouted” but usually we have to manually fail over in these situations. I am not sure who the traffic is rerouted for but it is definitely not our business.


Adrian posted a great article using the above method for bypassing our Moscow DC How to avoid to connect Russia Zen Node

Thanks for the post, Niladri.
About the Subclouds functionality, however, it is worth noting that “non-redundant” datacenters currently cannot be removed from a Subcloud via the self-service functionality. This is the case for most European datacenters today.

1 Like