PAC sends traffic to a proxy the Netskope Client may not know
low
When the Netskope Client runs on a device whose PAC file also points at other proxies, Netskope requires those proxies to be declared in the Client configuration ("Interoperate with Proxy"). The Client then intercepts CONNECT requests to them and steers managed destinations through its tunnel.
Why it matters
Netskope’s client configuration documentation says: if the PAC file redirects some traffic to other proxies, “it is mandatory to declare them in the Interoperate with Proxy settings”. The Client watches HTTP CONNECT requests to the declared on-premises proxies, compares the destination with the steering configuration and, for managed domains, resets the connection to the proxy and re-originates it through the Netskope tunnel. A proxy the PAC returns but the Client does not know about is a blind spot: requests to it are neither steered nor logged by Netskope. This is a configuration note for the Client, not a PAC error; it does not fire for Netskope’s own proxies or for loopback listeners.
How to fix
Add every proxy host:port the PAC returns to Netskope Client Configuration > Interoperate with Proxy, or route that traffic DIRECT and let the Client steer it.
Examples
Bad
function FindProxyForURL(url, host) {
if (isPlainHostName(host)) {
return "DIRECT";
}
if (dnsDomainIs(host, ".legacy-app.corp.example")) {
return "PROXY proxy.corp.example:8080";
}
return "PROXY eproxy-exampletenant.goskope.com:8081";
}
Good
function FindProxyForURL(url, host) {
if (isPlainHostName(host)) {
return "DIRECT";
}
return "PROXY eproxy-exampletenant.goskope.com:8081";
}
Related rules
- DIRECT in the PAC does not bypass the vendor's agent PAC-B014
- Selected vendor pack, but the PAC never routes to that vendor PAC-B015