When configuring preferred routing for the WSS Agent, connection attempts to unexpected backup data centers may occur.
Symptoms include:
Agents connect to different physical locations (e.g., Frankfurt/GDEFR or Milan/GITMO) instead of explicitly requested backup multi-country locations (e.g., Nicosia/GCYNI and Athens/GGRAT).
Symdiag logs show connection attempts and timeouts substituting the requested locations:
CTC Response ACTIVE (PRECHK) - egress: <Primary_IP> GILTA2-<IP> GDEFR-<IP> GITMO-<IP> geolocation: IL TA Tel Aviv
Connection failed for GILTA2, will try the next POP in the connect list...
Attempting to connect to GDEFR via UDPCloud Secure Web Gateway (Cloud SWG)
WSS Agent (macOS and Windows)
This routing behavior is intentional to guarantee high availability. Many locations in the Cloud SWG network are multi-country vPOPs (Localization Zones). These virtual points of presence provide local IP addresses for regional web localization but are physically hosted within a larger, centralized regional data center. In this scenario, Nicosia, Cyprus (GCYNI) and Athens, Greece (GGRAT) are both physically hosted in Frankfurt, Germany (GDEFR).
If routing is configured to use multiple vPOPs sharing the exact same physical host facility, geographic redundancy is lost. If the centralized data center experiences an outage, all vPOPs hosted within it fail. To prevent this single point of failure, the backend infrastructure proactively overrides the requested vPOPs to substitute distinct, physically separate data centers into the failover list.
This is expected behavior. The backend routing automatically substitutes geographically distinct physical data centers into the connection list to ensure continued connectivity in the event of a catastrophic data center failure. No configuration changes are required on the WSS Agent or in the Cloud SWG portal.
See the "Localization Zones" mapping section in the following document: Article ID 167174 - Cloud SWG (formerly WSS) Ingress and Egress IP addresses