Retour 
A common theme we hear from organizations utilizing a cloud delivered web proxy, either standalone or part of an SSE or SASE platform, is the frustration caused by website localization issues, a common trade-off when using services hosted in different geographies to the user. This is more acute the larger the customer is and the wider the distribution of employees beyond their home country or smaller organizations located in countries with no large scale data center (DC) infrastructure. Users’ traffic processed via a web proxy or filter originates from an IP associated with the country that the DC is located within. This leads to websites altering content or language, assuming that is where the user is located. In some extreme cases sites even prevent access completely due to tight access restrictions.
With Netskope’s coverage across 71 metro regions globally, and in conjunction with NewEdge Traffic Management 2.0, our dynamic DC selection process, users, no matter their location, maintain fast access to applications and websites. In fact with 68 of our 71 regions carrying no surcharges, we surpassed key competitors in terms of full compute locations. With NewEdge Traffic Management 2.0, users are connected to the data center that offers the best overall performance and lowest latency, not simply utilizing DNS load balancing and the perceived “closest” location. Even with our best in class coverage, we wanted to design a solution to improve content localization.
There are various methods to achieve this, one such method is to add Virtual Points of Presence (vPoPs) in countries with no real compute locations, but this type of PoP is simply a front door for users to access the web proxy in another location. This leads to overly complex routing and increases latency and therefore decreases application performance. vPoPs also don’t make sense for small countries or for overseas territories such as Réunion, with just a handful of users.
Another alternative is to deploy “exit nodes” in every country, where egress traffic is routed internally from the DC undertaking filtering to a node in the egress country, before exiting onto the open internet. This has similar drawbacks to the vPoP approach, with significantly ad