Intermittent "No connectivity to the proxy server" error when accessing isolated resources via Cloud SWG
Article ID: 413367
Updated On:
Products
Issue/Introduction
When accessing isolated webpages using Cloud SWG the user may face the error "No connectivity to the proxy server":
This occurs randomly for different URLs that become accessible again upon the next attempt.
Environment
Cloud SWG
WSS Agent
Web Isolation
Cause
Looking at the client HAR file we see that the request to https://global-shared.fire.glass/shareddomain.html returns the message: "This website should never be accessed directly... You probably did something wrong":
This happens because the URL is accessed directly, although it belongs to a list of Web Isolation-specific service URLs that must be isolated as well:
global-shared.fire.glass global-noauth-shared.fire.glass shared.fireglass noauth.shared.fireglass docisolation.prod.fire.glass docisolation-eu.prod.fire.glass
Examining SymDiag troubleshooting bundle it may appear that the request to global-shared.fire.glass is visible in WssServiceNetTrace.pcapng capture file collected on a physical interface. This means that the request has been bypassed in WSS Agent as the intercepted traffic is visible in another capture, WssaInTunnelTrace.pcap:
That can also be confirmed by a trace log from the SymDiag:
08/18/2025-11:36:04.8232631 Debug Found bypassed IP 3.169.71.2908/18/2025-11:36:04.8232635 Debug passthru due to domain bypass08/18/2025-11:36:04.8232682 Debug Passing through TCP packet for 3.169.71.29
The WSS Agent applies intercept/bypass rules based on IP address even if they are configured by URL. That is achieved using DNS snooping.
When checking the DNS snooping database in SymDiag bundle to confirm that the IP address is unique, it may turn out that it's not:
There is another domain that is resolved into the same IP address and the Cloud SWG ATM contains the rule that bypasses that domain.
So when the user accesses global-shared.fire.glass that is resolved into 3.169.71.29 the WSS Agent determines that this IP stands for another domain and applies the rule accordingly.
This may happen when both resources are hosted in some CDN (Cloudfront in this case) so their URLs are resolved into the same IP address.
Resolution
To address this issue one needs to create Always Intercept rule in the Cloud SWG Agent Traffic Manager and add the following URLs as destination:
global-shared.fire.glass global-noauth-shared.fire.glass shared.fireglass noauth.shared.fireglass docisolation.prod.fire.glass docisolation-eu.prod.fire.glass
Always Intercept rules have higher priority than bypass rules so they are guaranteed to be applied.
Feedback
