Wrong geolocation for "gateway.zscloud.net" in Brazil

Does anybody knows how Geolocation works for DNS resolution at Zscaler?

We are located at Brazil, and when we do a nslookup for “gateway.zscloud.net” we receive an IP address from Melbourne, Australia. It is supposed to receive the IP address of the closest ZEN, that in this case is SAO PAULO (it was working fine 2 weeks ago).

About the problem:
When we are working from our network (internal Lan) we use the mode “enforce proxy” for Trusted Network and the .pac file is configured to forward the traffic this way:

/* Default Traffic Forwarding. */
return “PROXY gateway.zscloud.net:80; DIRECT”;

The problem is that this hostname is resolving to - this is located at Melbourne, Australia. So it appears that the problem is with the geolocation detection from our source to this hostname, it is supposed to redirect us to SAO PAULO ZEN.

With this I have a huge latency and I had to change the IP address to SAO PAULO ZEN manually, I can´t anymore use the hostname for the proxy.

To solve I had to change the .pac file to this:
/* Default Traffic Forwarding. */
return “PROXY; DIRECT”;

I already opened a ticket for this, but the issue persists nobody can solve that. So I want to understand better how this works and see if I can´t use anymore the hostname.


Hi Denis,

any specific reason for using Proxy hostname or IP address Instead of using zscaler macros ?
If possible use country gateway Variable to determine closest ZEN to clients country .


1 Like

Thank you very much Ramesh, I´ll give a try.

No specific reason to use hostname, I didn´t know that I can use these variables for country region.

The gateway..net will be resolved to closest gateway based on your DNS server IP, while the $GATEWAY variable (which is in the default pac file) will use your source IP when you download the pac file.

Best Regards,

Jones Leung

SE Manager, Greater China


HK: +852 9463 6204

TW: +886 983 904 288

China: +86 186 8156 3905

I forgot to mention, but because of a particularity at my company, we need to host the .pac file inside our LAN for “Trusted Network”.
If I am not mistaken, MACROS only works when the .pac file is hosted at Zscaler. Is that correct?

Yes that is true. Macros will work only if you host the pac file on Zscaler cloud.

Hi ,

What is the Zscaler App version you are using ?

We had similar issues with our users in US in one of the app version where TAC confirmed that it is bug where the Zscaler is unable to parse the pac file.In such cases the machine will resolve gateway.zscloud.net through its local dns server.In our case the forwarders configured in DNS were present in UK which was the reason users were getting london nodes and not nodes based in US.

The Zscaler App we are using is
I think we have the same issue, I was checking our internal DNS servers and the configuration have forwarders that are not from Brazil (using google for instance
I already informed the team responsible to change this configuration (another team from my company), so I think that when they change to the ISP provider DNS servers the problem will be solved.
Thanks for the help.

Hi Denis,

Google Public DNS can handle correct location.

From: https://developers.google.com/speed/public-dns/faq

Google Public DNS sends queries to authoritative servers from Core data centers and Google Cloud region locations. Google publishes a list of the IP address ranges Google Public DNS may use to query authoritative DNS servers (not all the ranges in the list are used). You can use it for geo-location of DNS queries lacking EDNS Client Subnet (ECS) data, and to configure ACLs to allow higher query rates from Google Public DNS.

And the Zscaler ZEN node in Brazil (Sao Paulo II) needs a Regional surcharge as listed in https://ips.zscaler.net/cenr. Maybe you can’t use it, if the company which made the contract with Zscaler isn’t based in Brazil.

Best Regards,

Hi Patrick,

Thank you for sharing this information about Google.

Since last week the hostname is resolving to SAO Paulo ZEN node, I don´t know if this was related to something with Google Public DNS servers or not.

Anyway, we will fix our DNS forwarders to avoid this behavior.