Proxy Scope in an Extension-Based Search Product: The Search Encrypt Example

How does a local block request fall outside proxy scope?

The map and business block on a results page does not always come inside the main response. In the common layout, the block is filled by a separate request after the page opens, and that request goes not to the search domain but to a second domain used for location data. In an extension-based setup the chain gets one link longer: the phrase you type into the address bar first reaches the endpoint the extension redirects to, from there the results page, and from the page a third endpoint that feeds the block data. There is no reason to assume all three links go through the same exit.

This is exactly where the scope problem arises. If you set up your proxy rule with a domain list, the list contains only the search domain; the block request falls outside the scope and leaves directly over your own connection. The resulting picture is misleading: the organic listing comes from the target country's exit while the map block fills up with the inference from your real location. Most people read this as "the proxy isn't working"; in fact the part that works and the part that is out of scope sit side by side on the same page, waiting to be told apart.

The way to separate them is to widen the rule, not to narrow it. Define the scope by profile rather than by domain, reload the page and see whether the block's content changes. If it does, the problem was scope and it is solved. If it does not, the reason is not on the network side; the next step is to look at the engine's location inference and at which channel the blocks are fed from. The detail on that side — what inputs the inference is built from, why a location permission overrides the IP, why coverage varies by country — sits in the local block section on the Swisscows page .

Exit type, session and the cost balance

Search pages produce small responses; bandwidth is therefore rarely the bottleneck in this work. What really matters is the exit's geographic accuracy and how long the address stays in your hands. For a short check, an address from a pool is enough; in a comparison spread over days, a static address makes the job easier.

Datacenter proxy keeps costs low and is more than enough for country-level checks. ISP proxy gives a static address and is therefore preferred when you want to reproduce the same picture two weeks apart. When accuracy at city and provider level is needed, a residential exit comes into play. If you want a constantly changing address, a rotating pool is suitable, but in comparative measurement take care not to lose track of which address each round came from.

The authentication method is part of the process too. If you work from an office with a static IP, IP authorisation is practical; on a connection with a dynamic IP, access drops every time the line is renewed and you get a 407 response. Username and password work from anywhere but are a shareable secret. Using the two methods together is also possible; write down in your records which one is in effect during the measurement, because the reason access dropped mid-round is often hidden here.

Setup points and verification order

Where you define the proxy determines which traffic is routed. There are five common points and each has a different scope: a separate browser profile, a system-wide operating system setting, application-based routing, a Wi-Fi network setting on a mobile device, and an environment variable for a job running on the server side. For someone running search checks, the first option is usually the cleanest.

The scopes of these points do not contain one another; they intersect. A system-wide setting looks broad, but applications that use their own network stack do not read it; an application-based rule is narrow but catches exactly the process you want. When measuring, the path with the fewest surprises is to define it at a single point and keep the scope deliberately narrow. If you define it at two points, it is hard to work out afterwards which rule wins; when an application-based route and a system-wide setting conflict, the outcome depends on how the application sets up its own network stack.

In an extension-based setup, the first verification is scope verification and it comes before everything else. Run a single search in the test profile, keep the browser's network tab open and see that all the domains the results page triggers go out through the proxy; then read the exit country with my IP address . If the scope is incomplete these two outputs will not agree: the page comes from the target country while some requests have gone out over your own connection, and there is no sign on screen telling you so. On the leak side, running the three standard checks — DNS leak, WebRTC and anonymity test — once in the same profile and keeping the output is enough.

Even when these checks come out clean, one gap can remain: IPv6. If the endpoint the extension redirects to is also reachable over IPv6 and your exit carries IPv4 only, the client silently picks the IPv6 path and takes the proxy out of the picture. You get no error message; you just see a results page from a country you did not expect, and you usually mistake it for a scope error. an IPv6-capable exit Use or disable IPv6 in the test profile; when both address families are active at the same time, the operating system's preference order decides which path is chosen, and that order does not always work the way you expect.

Error symptoms, limits and responsibility

Most of the errors you will meet fall into a few categories. 407 Proxy Authentication Required tells you that credentials were not sent or that your IP authorisation has dropped. A timeout indicates that the proxy could not be reached at all or that the port is closed; measure liveness with with the proxy checker tool . A certificate warning is a separate category: a properly set up tunnel does not interfere with the TLS session, so if you see a warning, an intermediate point is establishing the session with its own certificate; do not continue measuring on such an exit, because you cannot tell whether the page you see came from the engine or from the layer in between.

On the performance side, a one-sentence expectation is enough: an extra stop lengthens page load time, it does not lower your ping. In an extension-based setup, a second source of latency is added on top of this, and that source is not on the network. The phrase you type into the address bar first passes through the extension's redirection step; this step is on the client side, it does not disappear when you turn the proxy off, and in measurement it is easily mistaken for network cost. To separate the two, run the same query once by going directly to the results page address: the difference is the extension's share, and the remaining difference is the route's.

Finally, scope and responsibility. This page describes access, privacy and regional verification scenarios; it is not written for automated query generation, bulk account creation or defeating a service's security measures. Complying with the terms of service of the product you use is your responsibility. If you want to see how other engines behave with the same setup, the guide list at the end of the page leads to a separate setup page for each engine; you can also find why free exits are not suitable for repeatable measurement in the frequently asked questions section below.