Browser access for public hosted website

Can we configure browser access for public hosted websites?

For example website is ‘’, and it has a public A record.

If I configure browser access and put cname for ‘’, connector will not be able to resolve to actual web server IP

Any thoughts?

Hello Raghav,
Since a publicly hosted website is already available through a web browser, what would you be trying to achieve by sending this traffic through ZPA? Since you do not own the public DNS for “xyz.technociate[.]in”, it will not work through the public internet anyways.
At most you would be able to do so only on endpoints where you control the DNS records, but again what would be the purpose?

Warm Regards,

Use case is, Public application access is restricted to DC public IPs. Connectors are located in DC

  1. “” is our own domain and we can change DNS records

Need to give access via clientless browser access feature

Inputs anyone?looking for a alternative way to achieve this

Not quite what you want but would SIPA work?

With Zscaler Client Connector you can send the request through ZIA and use Source IP Anchoring to forward through ZPA to give you the unique Source IP. Or you can use Zscaler Client Connector and advertise the application directly through ZPA.

However - I’d question what you’re looking to achieve. If the website is source IP anchored, why not simply enable authentication on the website for any IP which isn’t defined. That way you get what you’re looking for.

You could use ZPA Browser Based Acces - however you would need to do some form of URL rewrite. i.e. Application is public website. Create a ZPA application called as browser-based application, with public CNAME resolving to Zscaler BBA. You’d create a static Server definition for and associate with servergroup, and appropriate connector group which provides the source IP anchor.
Flow would be-

  1. Client to
  2. ZPA BBA Authenticates user
  3. forwarded through Connector A
  4. Connector A resolves
  5. Connector A forwards to
  6. uses source IP of Connector A to allow access

Points to note

  1. As far as the webbrowser is concerned, the user is accessing
  2. Because of #1 the HOST header is and the SSL SNI is
  3. ZPA is essentially performing a NAT of to, after the authentication
  4. The webserver will see the HOST header of and an SSL SNI of
  5. ZPA would need to disable SSL verification for the website because of #4
  6. The webserver, because of #4, would need to also accept HOST headers of, or simply serve to a request of

Basically - ZPA is NOT a ReverseProxy for this content. It’s a NAT/Forwarder essentially for these websites.

Hi Mr. Ryan

I did not follow below part

“You’d create a static Server definition for and associate with servergroup, and appropriate connector group which provides the source IP anchor”

Create a Server (which is a STATIC mapping, rather than allowing the Connector to perform the DYNAMIC server discover).
Map this server to the servergroup, which maps to the App Connector you’ll user for the source IP anchoring.

N.B. This is about the only time I would ever recommend creating a static server. 99.99% of the time you should stick to Dynamic Server Discovery.

@mryan It worked. I was almost there, We were doing DNS mapping in the internal DNS server that the connector speaks to

Appreciate the support here. This use case will be very common and competition is able to achieve this without these workarounds

1 Like

Remember this traffic is now not going through the Zscaler security stack so you have no threat protection, sandbox, dlp, ips etc.

Noted…No ZIA in this installation

1 Like