Verifying Swisscows Results from Different Exits

The most common mistake when examining a search engine from behind a proxy is attributing every observed difference to the exit IP. In fact there are at least four independent inputs that shape a result page: the geographic inference drawn from the network the request comes from, the language preference the browser reports, the region or filter setting selected in the interface, and the content the engine's own index happens to hold at that moment. A proxy changes only the first of these.

In the case of Swisscows this distinction is even more pronounced, because the two features that define the engine's identity — its emphasis on Swiss jurisdiction and its default content filter — work independently of your exit address. Switching to a German exit does not change the filter's behaviour; what can change is the ranking of results tied to geographic inference, and the local blocks.

The sections below build up in order: the path of the request across the network, the exit type decision, reading local results, the sampling method, freshness, and finally the setup and verification steps.

What is visible from the outside as a search request passes through the tunnel?

When you type a query into the address bar, the browser establishes a connection over HTTPS. If a proxy is configured, the client first sends the proxy server a request in the form CONNECT ornek.example:443 ; from that point on the proxy only carries encrypted bytes between the two ends. The query text, the result you click and the page returned are inside this tunnel; the proxy cannot read them.

What is visible from the outside is narrower, but not empty: the target host name, the port, the time of the connection and the number of bytes carried can all be logged on the proxy side. The server name field in the TLS handshake also travels in the clear in most setups. That is why choosing a provider is not a technical decision but a trust decision: do not tie a measurement that will run for days to an exit without first reading which fields are retained, how long the records are kept and whether they are shared with third parties.

Where is domain name resolution performed?

When you use an HTTP proxy, you tell the proxy the target in plain text and it performs the resolution. On the SOCKS5 side the decision is made not by the protocol itself but by your client's configuration; even two separate profiles of the same browser may resolve the domain on their own network or hand that job to the remote end. In a regional search check this distinction touches the finding directly: if resolution happens on your side, the server address the engine returns to you is your own region's answer, and even though you have moved the exit to Switzerland the first connection may be established to a local endpoint. Test which behaviour applies before you start measuring; where DNS is resolved in SOCKS5 the article places the two paths side by side. Local resolution is also a scope issue: which engine you connected to remains in your own resolver's logs, even if the tunnel is encrypted.

A second scope issue is the suggestion endpoints. The completion list that appears as you type often goes to a separate endpoint; if your rule only covers the main domain, these requests can leave outside the proxy. The check is simple: with the proxy on, verify in the same browser profile and in the same round that the completion list arrives and that the exit lookup tool shows the country you expect.

How do the filter and the index source shape the result set?

The content filter Swisscows highlights is a policy applied on the server side. No change you make at the network layer affects it: exiting from a different country, using a different protocol or switching to IPv6 does not widen or narrow the filter's scope. If you cannot see the page you expect for a query, first separate whether this is a filter decision or a case of not being in the index.

The second variable is the index source. An engine that relies on its own crawl and an engine that takes part of its results from shared indexes react differently to a change of country. With results from shared sources, regional ranking differences are usually more pronounced; with engines that use entirely their own index, the difference arises more from the language preference. Rather than guessing which applies, measure it: running the same query from two exits and placing the order of the first ten results side by side is a few minutes' work.

The third and most frequently overlooked variable is the language preference the browser reports. The Accept-Language header is entirely independent of the IP address. If you move the exit to the Netherlands but leave the browser language as Turkish, the engine receives a mixed signal and the page you see is neither what a real Dutch user would see nor your usual view. If you are running a regional check, move the language preference to the target region as well, and record that you did.

• Assess a gap caused by the filter separately from a case of not being in the index.
• Run the same query from at least two exits and compare the ranking.
• Make the language preference consistent with the exit country.
• Keep the region or safe search setting in the interface the same in every test.

Which exit type suits which kind of check?

Reading search results produces a different load profile from tasks that involve signing in: requests are short, responses are small, and the number of repetitions is high. For that reason choosing the most expensive exit is usually unnecessary. The criterion is simple: is what you want to target at country level or at city level?

If a country-level view is enough, datacenter proxy is the most cost-effective option and is comfortable on the bandwidth side. If you need city-level location inference, residential proxy or ISP proxy gives a more accurate result; the latter offers a static address, which keeps the picture stable in long-running comparisons. Mobile exits carry the geographic inference of the carrier network and are generally a broader tool than this job requires.

Which autonomous system an address belongs to is one of the main inputs feeding location inference; datacenter blocks are explicitly flagged in most geolocation databases, and that flag usually comes together with the city field being left empty or coarse. For checking work this is not a problem — just proceed knowing that city accuracy will be low, and express your finding at country level.

How many people the exit is shared with also affects the picture: in a shared pool, heavy traffic from the same address can trigger extra verification screens, an interruption occurs in the middle of your query set, and that round's record becomes unusable. On long sets, an address dedicated solely to you largely eliminates this risk.

What determines when map and business blocks appear?

Local result blocks rest on the engine's inference about where the request comes from. The main source of this inference is what the IP address maps to in a geolocation database, and its accuracy is high at country level and variable at city level. Two different exits in the same country can show a different business list for the same query; this is not an error but the natural precision limit of the inference.

A second and much stronger source is the browser's location interface. When a page asks for location permission and receives it, the coordinates it obtains override IP-based inference. If you are running a regional check, do not grant this permission; if you have, revoke it in your test profile. Otherwise, even with the exit moved to Milan, you will see businesses from your own city and think the proxy is not working.

The third point is the source of the blocks. Engines that do not run their own map infrastructure feed this area from a provider; the provider's coverage is not the same in every country. Seeing no local blocks at all in a region does not mean there are no results there — most of the time it means that channel is not active in that location. The way to separate the two is to repeat the same query on another privacy-focused engine and compare the block behaviour; Startpage with its intermediary layer and the Europe-based Qwant are suitable pairs for this comparison, and you can find setup guides for both in the related pages list at the bottom of this page.

Sampling: how many queries, how many repetitions, what evidence?

Looking at a single query once and drawing a conclusion is the most common source of error in this work. Even without personalisation, search results move over time: new pages enter the index, ranking signals are updated, and interface experiments may show different layouts to different users. Only repetition tells you whether the difference you see is regional or temporal noise.

A workable plan has three parts. The first is a fixed query set: ten to twenty queries chosen by topic that do not change between tests. The second is a repetition schedule: running the same set from the same exit at two different times of day and on at least two separate days. The third is an evidence record: for each run, the query, the exit label, the country, the time and a screenshot. A comparison with no evidence kept becomes open to dispute a week later.

Do not forget the control group. If you run an exit in your own country at the same time as the target country, the entire difference between the two pictures belongs to the region; with a one-sided measurement you cannot separate out the effect of time. If you want to increase the number of queries, set a reasonable rate before moving to automation, keep the interval between requests close to a human pace, and verify at the start of each round that the exit is still up.

• Write the query set down and do not change it between tests.
• Note the exit IP on every run; if the sticky window expires, the record gets muddled.
• Keep an HTML copy of the page alongside the screenshot.
• Run a control exit from your own country together with every round.
• Compare results as a set, not as a ranking; order alone is misleading.