Is SearXNG veilig? Privacy en risico's uitgelegd

Is SearXNG veilig? Het korte antwoord

SearXNG is in de ene richting veilig en in de andere onveilig; de vraag "is SearXNG veilig" kan daarom pas beantwoord worden als u aangeeft voor wie u zich wilt verbergen. SearXNG is een metazoekmachine: deze neemt uw zoekopdracht, stuurt deze door naar Google, Bing, DuckDuckGo en alle andere zoekmachines die u heeft ingeschakeld, en voegt de resultaten vervolgens samen op één pagina. De zoekmachines zien de instantie. De instantie ziet u.

Op een publieke instantie die door een vreemde wordt beheerd, ontvangt diegene elke zoekopdracht die u typt in platte tekst, en niets op hun 'over'-pagina kan bewijzen wat zij daarmee doen. Op uw eigen server zien de upstream-zoekmachines het adres van uw server in plaats van uw thuisadres. Die uitwisseling vormt het hele privacyverhaal, en het is precies zoveel waard als de server waarop het draait.

Niets hiervan verbergt uw zoekgedrag voor uw eigen netwerk. Uw internetprovider (ISP) ziet nog steeds een verbinding met de instantie. Uw DNS-resolver (domain name system) ziet nog steeds de hostnaam. Houd deze grens in gedachten terwijl u de rest leest.

Wat SearXNG verandert aan een zoekopdracht

Wanneer u direct via Google zoekt, ontvangt Google uw IP-adres, uw cookies, uw User-Agent-header en de pagina waar u vandaan kwam. Dit alles wordt gekoppeld aan een profiel dat langer bestaat dan de sessie zelf. SearXNG fungeert als tussenpersoon. De documentatie beschrijft de twee acties die het onderneemt: "het verwijderen van privégegevens uit verzoeken die naar zoekmachines worden gestuurd" en "het genereren van een willekeurig browserprofiel voor elk verzoek". Uw cookies worden nooit doorgestuurd naar een zoekmachine. Uw voorkeuren worden opgeslagen in uw eigen browser in plaats van in een account op de server.

Standaard worden er twee response headers meegestuurd, die beide een specifieke functie hebben:

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

Referrer-Policy: no-referrer betekent dat wanneer u op een resultaat klikt, de doelsite nooit te weten komt vanaf welke zoekpagina u kwam, omdat de browser de Referer-header weglaat. X-Robots-Tag: noindex, nofollow houdt uw instantie en de bijbehorende resultaatpagina's buiten zoekindexen.

Wat SearXNG niet verandert, is de zoekopdracht zelf. Deze komt volledig en leesbaar aan bij de instantie, omdat TLS (transport layer security) daar wordt beëindigd. Elk punt hieronder vloeit voort uit dat ene feit.

Op een publieke instantie ziet de beheerder elke zoekopdracht

De eigen documentatie van het project zegt het duidelijk: gebruikers van een openbare instance "moeten de beheerder van die instance vertrouwen" en kunnen niet weten "of hun verzoeken worden gelogd, samengevoegd en naar een derde partij verzonden of aan een derde partij verkocht". Een claim op een landingspagina dat er geen logs worden bijgehouden, blijft een claim. Van buitenaf kunt u dit niet testen. Het is dus vertrouwen of niets. Sommige openbare instances draaien bovendien nog steeds de oorspronkelijke Searx in plaats van deze fork. Dat is relevant, omdat Searx sinds 2023 geen codecommit meer heeft ontvangen en niet-onderhouden zoeksoftware nog een extra onderdeel is dat u blind moet vertrouwen.

Logging is bovendien de weg van de minste weerstand, omdat de standaardconfiguratie uw zoekopdracht in de URL plaatst:

server:
  method: "GET"

Bij GET reist de zoekopdracht als ?q=... in de request line. Elke standaard reverse proxy schrijft die request line naar het access log, waardoor de zoekopdrachten worden vastgelegd zonder dat iemand expliciet besluit om ze op te slaan:

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)"

Controleer het zelf op uw eigen instantie:

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

Uw zoekopdrachten staan daarin omdat het combined logformaat van nginx $request schrijft, wat de volledige request line inclusief de query string is. SearXNG heeft hier geen invloed op. Het overschakelen van de instantie naar method: "POST" verplaatst de zoekopdracht naar de request body, waardoor deze niet langer in het access log en de browsergeschiedenis verschijnt. De documentatie is eerlijk over het feit dat POST nadelen heeft die "het gebruiksgemak voor de eindgebruiker ernstig beperken", voornamelijk met betrekking tot de terug-knop van de browser. Het is een bewuste afweging.

Dit heeft twee gevolgen voor elke publieke instantie. De beheerder kan uw zoekopdrachten inzien, ongeacht of deze de intentie had om ze te verzamelen. Een back-up of een inbreuk op de server geeft toegang tot hetzelfde logbestand.

Op uw eigen VPS zien de zoekmachines uw server in plaats van u

Draai uw eigen instantie op een VPS (virtual private server) en de verandering is eenvoudig uit te leggen. Google ontvangt niet langer uw IP-adres thuis bij uw zoekopdracht. Het ontvangt het IP-adres van uw server bij uw zoekopdracht. Het kan die zoekopdracht niet koppelen aan uw ingelogde account, aan uw telefoon of aan het advertentieprofiel dat aan uw huishoudelijke verbinding is gekoppeld. De opbouw zelf wordt behandeld in de handleiding voor het draaien van uw eigen SearXNG-instantie op een VPS.

Wees duidelijk over wat er niet is veranderd. De zoekmachines zien nog steeds de zoektekst, het tijdstip, de taal en de regio waar u om vroeg, en het patroon van alles waar u maandenlang naar zoekt, allemaal gegroepeerd onder één stabiel adres. Als u de enige gebruiker bent, is dat adres een persoonlijke stroom zonder naam. Om deze groepering te doorbreken, moet de instantie de zoekmachines bereiken via een uitgaande proxy of via Tor, wat SearXNG ondersteunt en wat een afzonderlijke taak is.

Wat uw ISP, uw resolver en uw host nog steeds zien

Vier partijen blijven buiten schot bij deze maatregelen.

• Uw ISP ziet een TLS-verbinding met het IP-adres van uw instance en ziet de hostnaam in het SNI-veld (server name indication), dat tijdens de handshake in leesbare tekst wordt verzonden. De ISP ziet de query zelf niet.
• Uw DNS-resolver ziet de opzoekopdracht voor die hostnaam. Monitor dit op de client met sudo tcpdump -ni any port 53 terwijl u de pagina laadt; de A-recordaanvraag voor uw instance verschijnt dan.
• Uw VPS-provider beheert de hardware en kan daarom de schijf en het geheugen van de virtuele machine inzien. Schijfversleuteling binnen een gehuurde VM lost dit niet op, omdat het draaiende systeem de sleutel in het geheugen houdt.
• Iedereen met root-toegang op de instance ziet alles. Dat geldt voor u, maar ook voor iedereen die later toegang verkrijgt.

Het benaderen van de instance als een Tor onion service sluit de eerste twee punten uit, aangezien er geen publieke hostnaam is om op te lossen en geen SNI-veld om uit te lezen. De handleiding voor het toevoegen van een v3 onion service aan een VPS behandelt de configuratie, inclusief de lekken die dat adres anders aan het publieke IP-adres van uw server zouden koppelen.

Er is nog een punt dat vaak wordt vergeten. De uitgaande verzoeken van uw server zijn zichtbaar vanaf het netwerk van de server zelf; uw provider kan dus zien dat uw machine de hele dag met Google en Bing communiceert. Dit is een verkeerspatroon in plaats van een specifieke query, maar het geeft nog steeds informatie prijs.

Hier komt de vraag over een VPN aan de orde. Een VPN (virtual private network) verplaatst het perspectief van uw ISP naar dat van de VPN-aanbieder. Het verandert niets aan de positie van de instance-beheerder en niets aan de zoekmachines, omdat de zoekmachines communiceren met uw server en niet met u. Beide opties worden correct vergeleken in de vergelijking tussen een VPS en een VPN.

Waarom SearXNG u blokkeert en wat een 429-foutmelding werkelijk betekent

Er zijn twee verschillende situaties die beide worden omschreven als "SearXNG blokkeert mij", en ze vereisen elk een andere oplossing.

De eerste situatie is wanneer uw eigen limiter antwoordt met een HTTP 429-foutmelding. Dit is de bot-beveiliging van SearXNG, die standaard is uitgeschakeld:

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

Sinds augustus 2026 vereist de limiter een Valkey-database en leest deze de regels uit /etc/searxng/limiter.toml. Stel ook server.public_instance: true in als onbekenden daadwerkelijk gebruikmaken van uw server, aangezien dit standaard op false staat en het gedrag voor openbaar gebruik regelt.

De limiter voert verschillende controles uit. http_user_agent classificeert een ontbrekende User-Agent, of een User-Agent die overeenkomt met bekende tools zoals curl en wget, als een bot. http_accept classificeert een verzoek waarvan de Accept-header niet text/html bevat als een bot. link_token markeert een client als verdacht wanneer deze nooit de /client<token>.css-URL ophaalt die een echte browser wel laadt. Wanneer een controle wordt geactiveerd, stuurt SearXNG een 429-foutmelding terug en schrijft het een ERROR-regel naar de botdetection-logger.

Dit faalt dus, en dat is ook de bedoeling:

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

curl verstuurt User-Agent: curl/8.5.0 en Accept: */*, waardoor er direct twee controles worden geactiveerd. Dit is de reden waarom scripts en AI-agents een 429-foutmelding krijgen van een instantie die in een browser prima werkt. Dit is het punt dat u moet corrigeren voordat u de zoekfunctie van een agent op uw eigen instantie richt. De volledige lijst met oorzaken en instellingen staat in de handleiding over SearXNG rate limits en 429-fouten.

Eén valkuil bij de limiter verdient extra aandacht. Achter een reverse proxy ziet SearXNG het adres van de proxy in plaats van dat van de bezoeker, tenzij die proxy als vertrouwd is gemarkeerd:

[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 = []

De standaardlijst dekt een proxy op dezelfde host. Een proxy in een apart Docker-netwerk komt binnen vanaf een adres zoals 172.18.0.5, dat niet in de lijst staat. Hierdoor wordt elke bezoeker geteld als één client en sluit de eerste actieve gebruiker iedereen anders buiten. Voeg dat subnet toe aan trusted_proxies.

Het tweede type blokkade vindt plaats bij de upstream-provider. Een zoekmachine besluit dat een datacenter-adres dat veel zoekopdrachten uitvoert een scraper is en stopt met het beantwoorden van uw server. U krijgt hiervoor geen 429-foutmelding. U krijgt een resultatenpagina waarbij de resultaten van die specifieke zoekmachine ontbreken en er een foutmelding bij staat. SearXNG zal de zoekmachine na herhaaldelijke fouten tijdelijk opschorten. De oorzaak is het IP-adres van uw VPS; de oplossing ligt daarom in de keuze van zoekmachines en geduld, in plaats van in de instellingen van de limiter.

Helpt of schaadt het delen van een instance met vreemden?

Beide, in tegengestelde richtingen, wat de reden is dat het antwoord ambigu aanvoelt. Anonimiteit is een effect van de massa. Op een drukke publieke instance vertrekt uw zoekopdracht vanaf hetzelfde adres als de zoekopdrachten van duizenden andere mensen, waardoor geen enkele zoekmachine de uwe uit de stapel kan vissen. Op uw instance voor één gebruiker is elke zoekopdracht vanaf dat adres van u, en ontvangen de zoekmachines een schone stroom van één persoon zonder gekoppelde naam.

Aan de kant van de beheerder werkt het andersom. Een grote groep betekent dat een vreemde de zoekopdrachten in platte tekst van de hele groep in handen heeft, inclusief die van u. Uw eigen server betekent dat u uw eigen zoekopdrachten beheert en die van niemand anders.

Kies daarom op basis van de dreiging waar u daadwerkelijk mee te maken heeft. Maakt u zich zorgen over advertentieprofilering en cross-site tracking? De massa vangt dat goed op en het risico van de beheerder is klein. Maakt u zich zorgen dat één specifiek persoon of bedrijf een specifieke zoekopdracht van u zou kunnen inzien? De massa helpt hier totaal niet, omdat de beheerder de ruwe tekst ziet. Een goede middenweg is een instance voor een handvol mensen die u kent. U krijgt een kleine groep en een beheerder die u kunt verifiëren, aangezien u zelf de beheerder bent.

Zijn de resultaten van SearXNG beter dan die van Google?

Nee. SearXNG beschikt niet over een eigen index, dus elk resultaat op de pagina is afkomstig van een upstream-zoekmachine. De kwaliteit is daardoor begrensd door de zoekmachines die u heeft ingeschakeld. Schakelt u Google en Bing uit, dan daalt de kwaliteit direct, omdat het merendeel van de algemene webdekking van hen afkomstig is.

Wat wel verandert, is de verwerking van uw gegevens. Er wordt geen advertentieprofiel opgebouwd op basis van uw zoekopdracht en de resultaten worden niet opnieuw gerangschikt op basis van waar u vorige week op heeft geklikt. Dit werkt in twee richtingen, aangezien personalisatie ook lokale relevantie biedt. Een zoekopdracht als "apotheek nu open" levert via SearXNG minder relevante resultaten op, omdat de zoekmachine geen locatiegegevens van uw server heeft, behalve het datacenter waar deze zich bevindt. Stel de regio in bij de voorkeuren wanneer lokale resultaten belangrijk zijn.

Twee instellingen bepalen hoeveel informatie uw instantie lekt terwijl u de resultaten bekijkt. image_proxy staat standaard op false, waardoor miniaturen rechtstreeks worden geladen vanaf de sites die ze hosten en die sites het adres van uw browser zien. Door image_proxy: true in te stellen, worden deze via de instantie geleid, wat ten koste gaat van bandbreedte en geheugen. En formats is standaard ingesteld op html, waardoor een JSON (JavaScript object notation) verzoek wordt geweigerd met 403 Forbidden:

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

Schakelt u json in op een publieke instantie, dan heeft u een gratis scraping-API gepubliceerd. Dit is de snelste manier om het adres van uw server te laten blokkeren door de zoekmachines waarvan u afhankelijk bent. Houd deze optie uitgeschakeld of beveilig deze met authenticatie.

Waar het privacyverhaal van SearXNG eindigt

SearXNG verbergt voor zoekmachines wie de vraag stelt. Het verbergt voor uw netwerk niet wat u doet. Hieruit volgen vier grenzen.

• Uw verkeer is overal ongewijzigd, behalve in het zoekveld. Al het overige dat de machine doet, verlaat uw netwerk precies zoals voorheen.
• Eén gebruiker op één server is een stabiele identificatie voor elke zoekmachine. Deze identificatie bevat geen naam, en dat is het enige voordeel.
• De beheerder van een willekeurige instantie leest de zoekopdracht als platte tekst. Zelf de beheerder zijn is de enige versie hiervan die u kunt verifiëren.
• Uw eigen toegangslogs reconstrueren het overzicht dat u probeerde te vermijden. Lees deze logs en schakel over naar method: "POST" als u liever heeft dat ze leeg blijven.

SearXNG verplaatst de waarnemer. Het verwijdert de waarneming niet. Bepaal welke waarnemer u bezwaarlijk vindt, kies de bijbehorende instantie en beschouw een zoekinterface niet als anonimiteitssoftware.

FAQ

Is SearXNG veilig om te gebruiken op een publieke instantie?

Het is veilig voor de zoekmachines, maar onveilig voor de beheerder. Uw zoekopdracht bereikt de server als platte tekst en de documentatie van het project stelt dat gebruikers "de beheerder van die instantie moeten vertrouwen" en niet kunnen weten "of hun verzoeken worden gelogd, geaggregeerd en verzonden of verkocht aan een derde partij". Met de standaardinstelling van method: "GET" belandt de zoekopdracht ook in het toegangslogboek van de reverse proxy als onderdeel van de request line, ongeacht of de beheerder dit wilde of niet. Gebruik een publieke instantie voor gewone zoekopdrachten waarbij advertentieprofilering de zorg is. Typ niets in een instantie dat u niet aan de eigenaar zou toevertrouwen.

Verbergt SearXNG mijn zoekopdrachten voor mijn internetprovider?

De tekst van de zoekopdracht is verborgen. De activiteit niet. Uw provider ziet een TLS-verbinding met het adres van uw instantie en de hostnaam in het onversleutelde SNI-veld van de handshake, en uw DNS-resolver ziet de opzoeking voor die hostnaam. Geen van beide ziet waar u naar zocht, omdat de verbinding versleuteld is. SearXNG is geen VPN en biedt geen bescherming voor andere activiteiten van uw machine.

Waarom geeft SearXNG een 429-foutmelding?

Een 429-fout komt van de eigen limiter van de instantie; dit is bot-bescherming en geen bericht van Google. De controles markeren een verzoek waarvan de Accept-header text/html mist, en een User-Agent die niet is ingesteld of overeenkomt met tools zoals curl en wget. Een derde controle, de link-token, markeert een client die nooit de /client<token>.css-URL ophaalt die een browser wel laadt. Achter een reverse proxy die ontbreekt in trusted_proxies in /etc/searxng/limiter.toml, wordt elke bezoeker geteld als één client, waardoor één actieve gebruiker de rest blokkeert. Wanneer een upstream-engine uw server blokkeert, ontbreken de resultaten van die engine simpelweg op de pagina en krijgt u helemaal geen 429-fout.

Worden mijn zoekresultaten slechter door het zelf hosten van SearXNG?

Soms, om twee redenen die het waard zijn om te weten. Resultaten komen van upstream-engines, dus een datacenter-adres dat door engines wordt beperkt, betekent minder antwoordende engines en een minder uitgebreide pagina. Bovendien is gepersonaliseerde rangschikking verdwenen, wat advertentie-gestuurde herordening verwijdert en ook lokale intentie wegneemt, waardoor locatiegevoelige zoekopdrachten zwakkere antwoorden geven totdat u uw regio instelt in de voorkeuren.