SearXNG Proxy Setup: Instance Exit, Local Results and Screen Width
SearXNG is a meta-search layer with no index of its own: it distributes your query to multiple sources and merges the returned lists on a single page. The proxy decision is made in two places here — between the browser and the instance, and between the instance and the source engines. These are two different questions.
Two separate linksThe browser–instance link and the instance–source link are configured separately.
02
Separating stateAre preferences carried in a cookie or in the link, and how does that affect the result?
03
Map categoryWhere local results and business cards come from.
04
Screen widthWhy narrow-screen and wide-screen output should be counted separately.
SearXNG is the maintained version of the project long known as SearX, and both names describe the same idea: an upper layer that builds no index of its own, distributes the query to other engines and merges the returned lists. This architecture splits the proxy question in two, and setups that confuse the two questions produce unexpected results.
The first question is between you and the instance: through which exit does your browser connect to the instance? The second question is between the instance and the sources: from which address does the instance send requests to the engines? If you run your own installation, you decide both. If you use an instance run by someone else, the second link is entirely in the hands of whoever operates that instance.
Below we first separate these two links, then cover where preferences are stored, where map and local blocks come from, and how screen width changes the output.
The query travels over two links: which one do you control?
In a classic search engine, the request travels over a single link. In a meta-search layer there are two separate links, and they carry different network identities. On the first link your browser connects to the instance; the exit address visible here is your proxy setting. On the second link the instance forwards the query to the source engines; the address the sources see belongs to the instance's server, not yours.
The most important consequence of this distinction is this: setting a country exit in your browser does not make the source engines see a request coming from that country. What the sources see is where the instance is located. If you want to measure a regional view, the address that needs to change is the one on the second link.
If you run your own installation, you can configure the second link: the outbound connection settings in the configuration file allow requests to leave through an HTTP or SOCKS5 proxy. At this point the socks5h form is meaningful, because it also leaves domain name resolution to the proxy side. For choosing a protocol, the the protocol selection guide and the SOCKS5 proxy page provide guidance.
On an instance run by someone else, you have no control at all over the second link. You do not know which sources it has enabled, which address it exits from, or how it limits requests. If you are running a comparative measurement, this uncertainty directly undermines the repeatability of the result.
Tip
If you are going to measure, write down every time which link you changed. A shift on the same results page can come from a change on the first link or from a change on the second link, and these two are not the same thing.
DIAGRAMThe query's journey between the lanes
You can scroll the diagram horizontally to inspect it
The two links carry separate network identities: your exit is visible on the browser–instance link, and the instance's address on the instance–source link.
Where are preferences kept, and how do they carry into the result?
In this layer, personalisation works through preferences, not through an account. Settings such as which sources are queried, which categories are on, the safe search level and the interface language form a preference set. This set is mostly kept in a browser cookie; some installations also let you carry the same set with a preference string embedded in the link.
From a measurement point of view this is both a convenience and a trap. It is a convenience, because if you can carry preferences in the link, you can set up the same conditions on two different machines. It is a trap, because a preference set sitting in a cookie ages without you noticing: a source you turned off months ago is still off, and you attribute the missing result to some other cause.
The right approach is to treat the preference set as part of the measurement. Before starting a series, list which sources are on, write down the category selection, note the safe search level. Do not touch this set within the same series. If you are going to try a new set, record it as a separate series.
Preferences
Where it is stored
Throughout the series
Enabled source list
Cookie or link string
Kept fixed; if it changes, a new series is opened
Category selection
Cookie or tab selection
Stay in the same category for every measurement
Safe search level
Cookie
Written into the record line
Interface language
Cookie
Considered separately from the source language preference
The simplest way to separate session state from the measurement is a separate browser profile. The cookies, extensions and content blocker rules accumulated in your everyday profile reshape the page for you; the measurement profile should be kept outside that accumulation. Also verify at the start of every series that your exit has really changed, using the my IP address tool.
Which sources feed the results page?
A merged results page is not made up of a single list. General web sources, image and video sources, news sources, academic sources and map sources are queried separately; the returned lists are ranked and placed on a single page. If some of the sources do not respond, the page still loads, only incomplete.
This behaviour calls for care in measurement. When you run the same query two days apart, the difference you see may stem not from a change in source ranking but from a source failing to respond at that moment. The interface usually shows which source each result came from; recording this information is the only way to understand later where the difference came from.
The source distribution also determines the question of pace. A single query turns into multiple requests in the background; therefore running ten queries an hour does not mean sending ten requests an hour to the sources. If you run your own installation, take this multiplier into account and keep the settings that limit outbound requests enabled.
Most sources respond to heavy traffic from a meta layer with their own limits. When you run into these limits, the thing to do is not to add more addresses but to bring the query budget down to a realistic level. If outbound requests need to be distributed across a pool, datacenter exits are the first option to look at in terms of cost.
DIAGRAMDistribution of a single query across sources
You can scroll the diagram horizontally to inspect it
The numbers are relative weights, not real measurements; the distribution changes entirely depending on which categories are enabled.
An exit plan for your SearXNG installation
If you are going to route your own instance's outbound traffic, datacenter exits are economical; if you need country variety, a residential pool comes into play.
Choose whichever you need from our residential proxies, datacenter proxies, IPv6 and ISP solutions. Every plan comes with unlimited options, 99.9% uptime, rotating proxies, sticky sessions and 24/7 support. Ideal for web scraping, ad verification, SEO monitoring and digital data collection.
ISP ProxyStatic Turkish IPs registered to an ISP
ISP-registered static Türkiye IPs; they combine datacenter speed with the reputation of a real carrier. Ideal for long sessions and low-ping use.
Where do the map category and business results come from?
In this architecture, local results come from a separate category. The general web list is fed by one source and map and place results by another; the two are not subject to the same ranking logic. If you are not seeing a business card, the first place to look is not your proxy setting but whether the map category is enabled.
Where the location information comes from is another matter. Map sources mostly look at the place name inside the query: when you type a city or district name, the results cluster in that area. The country of the exit address does not necessarily play a decisive role here; adding a place name to the query is a far stronger signal than a hint on the network side.
Browser location permission is a third input and works independently of the proxy. If you grant the permission, the browser may share your real location; this leads you to see a set of local results you did not expect while using a country exit. Keeping location permission off in the measurement profile eliminates two conflicting signals from the outset.
Verify at the start of every series that the map category is enabled.
Write the place name inside the query; do not rely on the network hint.
Turn off browser location permission in the measurement profile.
Add which source a business card came from to the record line.
Track local results as a series separate from the general web list.
If you are going to compare the local surface of different countries, see the location list for country options, and for fixed exits on the European side Germany proxy page for more details.
Why should narrow screen and wide screen be measured separately?
This layer's interface uses a responsive layout: the same result set is drawn in different arrangements depending on window width. On a wide screen some blocks move into a side column; on a narrow screen the same blocks drop into the main flow or go into a collapsed section. Even if the order of the results has not changed, the layout you see on screen has.
That is why writing only "in third place" in the measurement log is insufficient. Unless you write down at which width you looked, two records are not comparable. The soundest method is to run the two widths as separate series: one series at a fixed desktop width, the other at a fixed narrow width.
There is a second distinction on the device side. A proxy defined in a mobile device's Wi-Fi settings covers only that network; when you switch to mobile data the setting is disabled and the request goes out directly. If you are measuring with a phone, verify your exit before every measurement, otherwise one of your records will be with a proxy and another without.
Device emulation in the browser's developer tools is a practical middle way: it fixes the window width and lets you run two series on the same machine. But emulation does not reproduce a real phone's network behaviour; if you want to see the difference on the network side, you need to measure with a real device. For cases that require an exit from a mobile carrier network, the mobile proxy page covers the subject separately.
DIAGRAMSharing the measurement budget across series
You can scroll the diagram horizontally to inspect it
This is an example budget split, not a measured distribution; divide it again according to your own comparison goal.
Running your own instance versus using a ready-made one
The difference between the two setups is less technical than it is a matter of control. With a ready-made instance you install nothing; in return you do not know which sources are enabled, where outbound requests exit from, or how the server limits requests. The same instance may be configured differently tomorrow, and there is no way for you to notice.
With your own installation, the configuration is yours: you choose the source list, you write the outbound connection settings, you enable the limiter. In return you take on running a server, keeping up with updates, and how the server's address looks to the sources.
If you route outbound traffic through a single exit in your own installation, remember that this exit goes to all sources with the same address. A heavy sequence of requests leaving a single server produces a pattern that is easy to distinguish on the source side. Defining a separate exit per source is possible, but it increases the complexity and cost of the setup.
Setup and verification: testing the two links separately
Testing the first link is easy. Define the exit in your browser profile, open the instance and verify your exit. Both HTTP proxy and SOCKS5 work on this link; the difference appears in where the domain name is resolved. In setups where resolution is done on the client side, the target name is visible to your local resolver — details where DNS is resolved in SOCKS5 the article.
Testing the second link is only possible on your own installation. After defining the outbound connection proxy in the configuration, verify from the server-side logs that the requests going to the sources really pass through that exit. If you did not restart the service after writing the configuration, the old setting keeps working; this is the most frequently seen silent error.
Running a system-wide tunnel and a browser-level proxy at the same time makes it unclear which request goes out from where. If you are measuring, leave a single layer; stacking two layers makes diagnosis impossible.
Limits, cost and the appropriate-use framework
What this layer provides is that your query does not go to the source engines directly from your browser. That is a valuable distinction, but not an unlimited one. The source engines still see a request; it just comes from a different address. The privacy claim ends at the network layer and does not cover the rest of your browser's behaviour.
The cost side is mostly small. Results pages are text-heavy, and as long as you keep the image category off, the data transferred stays limited. On the other hand, remember that a single query turns into multiple requests in the background: when calculating quota, base it on the estimated number of requests, not the number of queries. For the calculation method, bandwidth calculation article.
The appropriate-use framework is clear. The source engines' terms of service and robots.txt directives also apply to requests sent through a meta layer; putting a layer in between does not remove that obligation. If you are considering data collection at scale, looking into the official interfaces is the first step.
Finally, not every scenario requires a proxy. If you are running a normal search from your own country, there is no benefit in putting a layer in between; you only add latency and complexity. A proxy makes sense when you need to see another country's result surface, exit a corporate network with a fixed address, or make a measurement setup repeatable.
Frequently asked questions about SearXNG and proxies
01Are SearX and SearXNG the same thing?
SearXNG is the maintained version of the project long known as SearX. The architectural idea is the same: it has no index of its own, it distributes the query to source engines and merges the lists. The proxy setup on this page applies to both names.
02If I set a country exit in my browser, will the source engines see that country?
No. Your browser's exit is only visible on the link between you and the instance. The address the source engines see belongs to the server hosting the instance. If you want to measure a regional view, you need to change the instance's outbound connection setting, and that is only possible on your own installation.
03Can I route my own instance's outbound requests through a proxy?
Yes. The outbound connection settings in the configuration accept HTTP and SOCKS5 exits; socks5h the form also leaves domain name resolution to the proxy side. Remember to restart the service after the change, otherwise the old setting keeps working.
04Why can't I see map and business results?
The first place to look is whether the map category is enabled; if this category is off, local blocks are never queried. The second possibility is that the query contains no place name — writing a place name is a far stronger signal than a country hint on the network side.
05Why does the same query give different results two days apart?
The most common reason is that a source could not respond at that moment; the page still loads, but incomplete. The interface usually shows which source each result came from, and recording this information lets you tell later where the difference came from.
06Should I use a ready-made instance or my own installation?
For one-off use, a ready-made instance is enough. If you are building a repeatable measurement setup, you need your own installation: only then are the source list, the outbound exit and the request limit written down and fixed. In return, you take on the burden of running a server.
07Can I measure the narrow-screen view with browser emulation?
For seeing the layout difference, yes; it fixes the window width and lets you run both series on the same machine. But emulation does not reproduce a real phone's network behaviour. If you are measuring the difference on the network side, you need to work with a real device.
08Does using this layer override the source engines' rules?
No. The source engines' terms of service and robots.txt directives remain valid even when you put a layer in between. If you are considering data collection at scale, the right step is to first look into the engine's official access interfaces.