What is Surrogate IP?
Surrogate IP is a Zscaler service that maps an authenticated user to their private IP address, so that user policies also apply to traffic the service cannot authenticate directly. According to Zscaler documentation, this mainly affects applications without cookie support, undecrypted HTTPS connections, and transactions with unknown user agents. Without Surrogate IP, only the blanket location policies would apply to such traffic. The mapping holds for one user per address, is carried through into the logs, and ends with idle timeout, logout, or another user authenticating from the same address.
Surrogate IP in detail
The mechanism is deliberately simple: when a user successfully authenticates at a known location, the service notes the connection as “this private IP currently belongs to this user”. From then on, transactions with no user credential are attributed to that person too, in both policies and logs. A practical side effect: once you have authenticated in one browser, you do not need to sign in again in a second browser or in desktop applications.
The requirements are a forwarding path that keeps the private address visible (a GRE or IPsec tunnel without NAT, proxy chaining with XFF forwarding, or a dedicated proxy port), plus enforced authentication at the location. The limits show up wherever many users share one address: for multi-session VDI, Zscaler explicitly advises against using it, because the mapping can then hit the wrong users.
Why Surrogate IP matters in Zscaler operations
In everyday operations, Surrogate IP explains a whole family of puzzling tickets. A user seemingly gets the wrong policies at random: in reality, the location policy applies because the mapping has expired. Two colleagues share one machine, and the second inherits the first one's blocks: in reality, the mapping is still active. A desktop application behaves differently from the browser: in reality, without Surrogate IP, there is no user credential for non-browser traffic.
The mechanism also cuts both ways for reporting: the mapping makes logs user-specific and therefore meaningful, but it also carries mismapping through into the record. Anyone basing reports or evidence on log data should know at which locations Surrogate IP is active, with what idle timeout, and where shared devices limit how much the data can prove.
Common sources of error
- Surrogate IP combined with multi-session VDI: many users share one address, so policies and logs hit the wrong people.
- Idle timeout set poorly: too short causes constant fallbacks to location policies, too long keeps mappings on shared devices alive artificially.
- NAT in the forwarding path: if the private address disappears along the way, the service cannot map it, and the feature has no effect.
- No documentation of where Surrogate IP is active: the helpdesk then reads policy anomalies as a Zscaler fault instead of a mapping question.
Surrogate IP in practice: what CentaurNexus contributes
CentaurNexus clarifies whether an odd policy behaviour is down to an expired or someone else's mapping, without you digging through views. The 360° User Search shows a user's status across ZIA, ZPA and ZDX on one page, by name, email or IP address, with no Zscaler admin rights needed. Connectivity Triage Map adds a plain-language read on whether a problem sits with the device, the network, a policy or the mapping. That lets 1st Level answer “Why does the wrong rule apply to me?” with a finding instead of a guess. The 360-degree approach is described in the article Zscaler support without admin rights.
Related terms
Frequently asked questions about Surrogate IP
Not all traffic can be authenticated directly: applications without cookie support, undecrypted HTTPS connections and unknown user agents carry no user credential. Surrogate IP closes that gap by mapping such transactions, through the private IP address, to whichever user last authenticated from there. That way, user policies apply instead of blanket location policies.
The mapping holds for exactly one user per IP address and lasts until the configured idle timeout expires, the user logs out, or another user authenticates from the same address. The idle timeout is configured by the admin at the location; it is the most important lever between convenience and clean mapping.
Zscaler advises against using it with multi-session VDI, because many users there share one virtual machine and therefore the same private IP address. The mapping can then attribute traffic to the wrong user, in both policies and logs. Other authentication routes are the better choice for such environments.
According to Zscaler documentation, it needs a forwarding path that keeps the private IP visible: a GRE or IPsec tunnel without NAT, proxy chaining with XFF forwarding enabled, or a dedicated proxy port. Authentication also has to be enforced at the location. Only then can the service reliably link user and address.
The service attributes the mapped transactions to the user in the logs too. That makes reporting more meaningful, but it also means a wrong mapping, for example on a shared machine, ends up in the record as well. Anyone using logs for evidence or analysis should know and document the limits of IP-based mapping.
- Zscaler Help Portal: Understanding Surrogate IP - help.zscaler.com
- Zscaler Help Portal: Understanding User Provisioning and Authentication - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.