Using a Proxy With Mojeek: Regional Signal, Session State and Request Pace

Most of the proxy discussion around search engine pages gets complicated because it is unclear who produced the result. Many services take their result set from a partner; you think you are measuring one party while in fact you are recording the behaviour of a second provider. Mojeek is a plainer basis in this respect: crawling, indexing and ranking all happen under the same roof.

That simplicity doesn't expand the proxy's job, but it clarifies it. When your exit address changes, what is affected is not the whole ranking but one of the several inputs the engine reads as a regional cue. The remaining inputs — interface language, the country filter on the settings page, the query itself — live on the browser side and the proxy doesn't touch them.

The sections below unpack this distinction in order: which layer looks at the network and which looks at you; which of them must be held fixed when measuring; and how to plan the pace as the scale grows.

What does a proxy change on an engine that crawls its own index?

A Mojeek query passes through three separate layers. At the top is the query and interface layer: the phrase you type, the language you pick, the country filter you tick on the settings page. All of this is held client-side and is outside the proxy's field of view — changing the exit doesn't reset a preference, because the preference sits in your browser's storage.

The middle layer is the index and ranking. The engine's own crawler has collected, parsed and ordered the documents. This layer isn't rebuilt per person from request to request; the same query under the same conditions returns largely the same set of documents. When you wonder why a result is near the top, the place to look is not your proxy setting but this layer's indexing behaviour.

The bottom layer is transport and exit. The request is established over TCP, encrypted with TLS, and the only network identity visible on the server side is your exit IP address. What the engine can read from that address is limited: which autonomous system (ASN) the address belongs to and roughly which country it appears to be registered in. For how classification works, the article on ASN and IP reputation is a good starting point.

The practical benefit of separating the three layers is this: when you see a change in results, you first ask which layer moved. Did your preference change, did the index refresh, or did your exit simply shift to another country? Teams that don't ask this question attribute a difference caused by a browser preference to the proxy and look for the solution in the wrong place.

How do exit country and interface language differ in ranking?

Regional effect isn't tied to a single button; it is the resultant of two inputs that operate independently of each other. The first is the cue on the network side: the country your exit address is registered in. The second is the explicit preference on the application side: the interface language and the country filter on the settings page. When the two don't point the same way, the result is a mixed profile that a real user rarely produces.

A concrete example: if you use a German exit but leave the interface in English, the network layer says Germany while the application layer declares a particular language preference. The page you get back sits somewhere between the two and is identical neither to what a user in Germany sees nor to what a user who keeps their language English sees. If you are making comparisons, you need to record this intermediate state, or you will write two measurements into the same column.

The right setup is to fix both inputs deliberately. If you want to examine a country's result surface, take the exit from that country, set the interface language to that country's common language, and set the country filter in the same direction. For the country list see the proxy locations page, and for the TR view the Turkey exit .

A single rule largely solves the problem: change only one variable per series. If you are changing the country, leave the language fixed; if you are changing the language, keep the exit in place. A difference that comes out of a measurement where two variables moved together tells you nothing about which input produced it.

Keeping browser state out of the measurement

A privacy-focused engine may not be profiling you through an account; that doesn't mean your measurement is clean. Most of the state affecting how the page arrives already sits in your browser: previously saved preference cookies, rules injected by extensions, a content blocker hiding certain blocks, the window width and the font scale.

The most insidious thing about these state residues is that they carry over without you noticing. Last week you ticked a country filter; this week, when you start a new series with the same profile, the filter is still on and you mistake it for a proxy difference. Likewise, if an extension hides some of the links on the page, you count fewer results than there really are.

The solution isn't complicated, but it requires discipline. Open a separate browser profile for measurement; keep only the proxy definition and the minimum necessary extensions in it. Start each series with clean storage and don't change preferences until the series is over. Don't keep any logged-in tab in the same profile — a tab with an active session keeps generating requests in the background for as long as it stays open.

• Keep the measurement profile completely separate from your everyday profile.
• Note the window width; the layout changes with width.
• Keep the content blocker off in the measurement profile, or run every series with the same setting.
• Clear storage before starting the series, not in the middle of it.
• Write down which profile you measured with; results are profile-specific.

Once you have this arrangement in place, the difference you see when you change the exit really does come from the exit. The differences you saw before that usually come from the browser's memory, and no proxy setting will fix that.

Matching query pace to pool size

For one-off manual searches, pace is not an issue. But once you set up a monitoring routine that runs dozens of queries back to back, pace becomes the first limiting factor. A dense sequence of requests arriving from the same exit at short intervals produces a pattern that doesn't resemble human usage, and you are likely to meet a verification screen.

A verification screen isn't a punishment, it's a slow-down signal. The right response is not to retry at the same speed but to back off gradually: increase the wait time exponentially and return to the normal pace after a few runs. This page is about tuning the pace so verification screens are never triggered, not about getting past them.

Pace and pool size are two sides of the same equation. Once you have decided how many queries you will run per hour, you need enough addresses to keep the load per exit at an acceptable level. In most monitoring work, reducing the number of queries is a cheaper decision than increasing the number of addresses; the aim of the measurement is comparability, not volume. If you are opening parallel requests, concurrent connection limit must also be taken into account.

If you genuinely need access at scale, look first at the engine's own documented search interface. Working through an official interface gives more predictable results and is in line with what both parties expect. Before any arrangement that turns to page scraping, you should read robots.txt and the terms of service.