Is SearXNG safe? What it actually hides

Is SearXNG safe? The short answer

SearXNG is safe in one direction and unsafe in the other, so the question "is SearXNG safe" only has an answer once you say who you are hiding from. SearXNG is a metasearch engine: it takes your query, sends it out to Google, Bing, DuckDuckGo and whatever other engines you enabled, then merges what comes back into one results page. The engines see the instance. The instance sees you.

On a public instance run by a stranger, that stranger receives every query you type, in plain text, and nothing on their about page can prove what they do with it. On your own server, the upstream engines see your server's address instead of your home address. That swap is the whole privacy story, and it is worth exactly as much as the server it runs on.

No part of this hides your searching from your own network. Your internet service provider (ISP) still sees a connection to the instance. Your DNS (domain name system) resolver still sees the hostname. Keep that boundary in view while you read the rest.

What SearXNG changes about a search request

Search Google directly and Google receives your IP address, your cookies, your User-Agent header and the page you came from, all tied to a profile that outlives the session. SearXNG stands in between. Its documentation describes the two things it does: "removing private data from requests going to search services" and "generating a random browser profile for every request". Your cookies are never forwarded to an engine. Your preferences are stored in your own browser rather than in an account on the server.

Two response headers ship on by default, and both do real work:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer means that when you click a result, the destination site never learns which search page sent you, because the browser omits the Referer header. X-Robots-Tag: noindex, nofollow keeps your instance and its result pages out of search indexes.

What SearXNG does not change is the query itself. It arrives at the instance complete and readable, because TLS (transport layer security) is terminated there. Every point below follows from that one fact.

On a public instance, the operator sees every query

The project's own documentation says it plainly: users of a public instance "have to trust the administrator of that instance", and they cannot know "whether their requests are logged, aggregated, and sent or sold to a third party". A no-logs claim on a landing page is a claim. From the outside there is no way to test it, so it is trust or nothing.

Logging is also the path of least effort, because the shipped default puts your query in the URL:

server:
  method: "GET"

With GET, the query travels as ?q=... in the request line. Any ordinary reverse proxy writes that request line to its access log, so the queries are recorded without anyone deciding to record them:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

On your own instance, look for yourself:

sudo tail -n 5 /var/log/nginx/access.log

Your searches are in there because nginx's combined log format writes $request, which is the full request line including the query string. SearXNG never gets a say in it. Switching the instance to method: "POST" moves the query into the request body, so it stops appearing in the access log and in browser history. The documentation is honest that POST has disadvantages that "severely restrict the ease of use for the end user", mostly around the browser back button. It is a trade you make on purpose.

Two consequences follow for any public instance. The operator can read your queries whether or not they meant to collect them. A backup or a break-in reaches the same log.

On your own VPS, the engines see your server instead of you

Run your own instance on a VPS (virtual private server) and the change is simple to state. Google no longer receives your home IP address with your query. It receives your server's IP address with your query. It cannot connect that search to your logged-in account, to your phone, or to the advertising profile attached to your household connection. The build itself is covered in the guide to running your own SearXNG instance on a VPS.

Be clear about what did not change. The engines still see the query text, the timing, the language and region you asked for, and the shape of everything you search across months, all grouped under one stable address. If you are the only user, that address is a per-person stream with no name on it. Breaking the grouping requires the instance to reach the engines through an outbound proxy or through Tor, which SearXNG supports and which is a separate piece of work.

What your ISP, your resolver and your host still see

Four observers are unaffected by any of this.

• Your ISP sees a TLS connection to your instance's IP address, and it sees the hostname in the SNI (server name indication) field, which is sent in cleartext during the handshake. It does not see the query.
• Your DNS resolver sees the lookup for that hostname. Watch it on the client with sudo tcpdump -ni any port 53 while you load the page, and the A record request for your instance appears.
• Your VPS provider runs the hardware, so it can read the disk and the memory of the virtual machine. Disk encryption inside a rented VM does not remove this, because the running system holds the key.
• Anyone with root on the instance sees everything. That includes you, and it includes whoever gets in later.

There is one more that people forget. Your server's outbound requests are visible from the server's own network, so your provider can see that your machine talks to Google and Bing all day. That is a traffic pattern rather than a query, and it still says something.

This is where the VPN question arrives. A VPN (virtual private network) moves your ISP's view over to the VPN company's view. It changes nothing about the instance operator and nothing about the engines, because the engines are talking to your server and not to you. The two are compared properly in the breakdown of a VPS against a VPN.

Why SearXNG blocks you, and what a 429 really means

Two different events both get described as "SearXNG blocked me", and they have different fixes.

The first is your own limiter answering you with HTTP 429. This is SearXNG's bot protection, and it is off by default:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

As of August 2026 the limiter needs a Valkey database and reads its rules from /etc/searxng/limiter.toml. Set server.public_instance: true as well if strangers really do use the box, since it is false by default and gates the behaviour meant for public use.

The limiter runs several probes. http_user_agent treats an unset User-Agent, or one matching known tools like curl and wget, as a bot. http_accept treats a request whose Accept header does not contain text/html as a bot. link_token marks a client suspicious when it never fetches the /client<token>.css URL that a real browser loads. When a probe fires, SearXNG returns 429 and writes an ERROR line to its botdetection logger.

So this fails, and it is supposed to:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

curl sends User-Agent: curl/8.5.0 and Accept: */*, so two probes match at once. That is why scripts and AI agents get a 429 from an instance that works fine in a browser, and it is the thing to fix before pointing an agent's search skill at your own instance. The full set of causes and settings lives in the guide to SearXNG rate limits and 429 errors.

One limiter trap deserves naming. Behind a reverse proxy, SearXNG sees the proxy's address rather than the visitor's, unless that proxy is trusted:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

The default list covers a proxy on the same host. A proxy in a separate Docker network arrives from an address like 172.18.0.5, which is not in the list, so every visitor is counted as one client and the first busy user locks out everybody else. Add that subnet to trusted_proxies.

The second kind of block happens upstream. An engine decides that a datacenter address running many searches is a scraper and stops answering your server. You do not get a 429 for that. You get a results page with that engine's results missing and a failure noted against it, and SearXNG will suspend the engine for a while after repeated failures. The cause is the address your VPS sits on, so the fixes are engine choice and patience rather than anything in the limiter.

Does sharing an instance with strangers help or hurt?

Both, in opposite directions, which is why the answer feels slippery. Anonymity is a crowd effect. On a busy public instance your query leaves the same address as thousands of other people's queries, so no engine can pull yours out of the pile. On your single-user instance every query from that address is yours, and the engines receive a clean one-person stream with no name attached.

The operator side runs the other way. A large crowd means a stranger holds the crowd's plain text queries, yours included. Your own box means you hold your queries and nobody else's.

So choose by the threat you actually have. Worried about ad profiling and cross-site tracking? The crowd handles that well and the operator risk is small. Worried that one specific person or company might read one specific search you ran? The crowd does not help at all, because the operator sees raw text. A good middle path is an instance for a handful of people you know. You get a small crowd and an operator you can verify, since the operator is you.

Are SearXNG results better than Google?

No. SearXNG holds no index of its own, so every result on the page came from an upstream engine, and the ceiling on quality is the ceiling of the engines you enabled. Disable Google and Bing and quality drops the same day, because most of the general web coverage came from them.

What changes is the processing applied to you. Nothing builds an advertising profile from the query, and nothing reorders the results based on what you clicked last week. That cuts in both directions, because personalisation also carries local intent. A search like "pharmacy open now" comes back weaker through SearXNG, since the engine has no location signal for your server beyond the datacenter it sits in. Set the region in preferences when local results matter.

Two settings decide how much your instance leaks while you read those results. image_proxy is false by default, so thumbnails load straight from the sites hosting them and those sites see your browser's address. Setting image_proxy: true routes them through the instance instead, at a cost in bandwidth and memory. And formats ships as html only, so a JSON (JavaScript object notation) request is refused with 403 Forbidden:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

Enable json on a public instance and you have published a free scraping API, which is the quickest way to get your server's address blocked by the engines you depend on. Keep it off, or keep it behind authentication.

Where the SearXNG privacy story ends

SearXNG hides who is asking from the search engines. It does not hide what you are doing from your network. Four boundaries follow from that.

• Your traffic is unchanged everywhere except the search box. Everything else the machine does leaves your network exactly as before.
• One user on one server is a stable identifier to every engine. The identifier carries no name, and that is the entire benefit.
• The operator of any instance reads the query as plain text. Being the operator yourself is the only version of this you can verify.
• Your own access logs rebuild the record you were trying to avoid. Read them, and switch to method: "POST" if you would rather they stayed empty.

SearXNG moves the observer. It does not remove observation. Decide which observer you mind, pick the instance that matches, and do not treat a search front end as anonymity software.

FAQ

Is SearXNG safe to use on a public instance?

It is safe from the search engines and unsafe from the operator. Your query reaches that server as plain text, and the project's documentation states that users "have to trust the administrator of that instance" and cannot know "whether their requests are logged, aggregated, and sent or sold to a third party". With the shipped default of method: "GET", the query also lands in the reverse proxy's access log as part of the request line, whether or not the operator wanted it there. Use a public instance for ordinary searching where ad profiling is the worry. Do not type anything into one that you would not hand to its owner.

Does SearXNG hide my searches from my internet provider?

The query text is hidden. The activity is not. Your provider sees a TLS connection to your instance's address and the hostname in the cleartext SNI field of the handshake, and your DNS resolver sees the lookup for that hostname. Neither sees what you searched for, because the connection is encrypted. SearXNG is not a VPN, and it gives no protection to anything else your machine does.

Why does SearXNG return a 429 error?

429 comes from the instance's own limiter, which is bot protection rather than a message from Google. Its probes flag a request whose Accept header lacks text/html, and a User-Agent that is unset or matches tools like curl and wget. A third probe, the link token, flags a client that never fetches the /client<token>.css URL a browser loads. Behind a reverse proxy that is missing from trusted_proxies in /etc/searxng/limiter.toml, every visitor is counted as one client, so one busy user blocks the rest. When an upstream engine blocks your server instead, that engine's results simply go missing from the page and you get no 429 at all.

Does self-hosting SearXNG make my search results worse?

Sometimes, for two reasons worth knowing. Results come from upstream engines, so a datacenter address that engines throttle means fewer engines answering and a thinner page. And personalised ranking is gone, which removes ad-driven reordering and also removes local intent, so location-sensitive searches return weaker answers until you set your region in preferences.