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. Niets op hun 'over'-pagina kan bewijzen wat zij hiermee doen. Op uw eigen server zien de upstream-zoekmachines het adres van uw server in plaats van uw thuisadres. Die uitwisseling vormt de kern van het privacyverhaal en 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 waarvandaan u kwam. Al deze gegevens worden gekoppeld aan een profiel dat langer bestaat dan de sessie zelf. SearXNG fungeert als tussenpersoon. De documentatie beschrijft de twee acties die het uitvoert: "het verwijderen van privégegevens uit verzoeken die naar zoekmachines worden verzonden" en "het genereren van een willekeurig browserprofiel voor elk verzoek". Uw cookies worden nooit doorgestuurd naar een zoekmachine. Uw voorkeuren worden in uw eigen browser opgeslagen in plaats van in een account op de server.

Standaard worden 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 zorgt ervoor dat uw instantie en de bijbehorende resultatenpagina's niet in zoekindexen worden opgenomen.

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 documentatie van het project stelt het duidelijk: gebruikers van een publieke instantie "moeten de beheerder van die instantie vertrouwen", en zij kunnen niet weten "of hun verzoeken worden gelogd, geaggregeerd en verzonden of verkocht aan een derde partij". Een 'no-logs'-claim op een landingspagina is slechts een bewering. Van buitenaf is dit niet te verifiëren, dus het is een kwestie van vertrouwen of niets.

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=... mee in de request line. Elke standaard reverse proxy schrijft die request line naar het access log, waardoor zoekopdrachten worden vastgelegd zonder dat iemand expliciet besluit om ze te loggen:

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. Door de instantie om te schakelen naar method: "POST" verplaatst u 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 'vorige'-knop in de browser. Het is een bewuste afweging die u maakt.

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 over maanden heen naar zoekt, allemaal gegroepeerd onder één stabiel adres. Als u de enige gebruiker bent, is dat adres een persoonlijke stroom zonder naam erop. Het doorbreken van deze groepering vereist dat de instantie de zoekmachines bereikt 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; het verzoek voor het A-record van 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 bent u zelf, maar ook iedereen die later toegang tot het systeem verkrijgt.

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 communiceert met Google en Bing. Dit is eerder een verkeerspatroon dan een query, maar het geeft nog steeds informatie prijs.

Hier komt de vraag over een VPN om de hoek kijken. 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. De twee worden correct vergeleken in het overzicht van een VPS versus een VPN.

Waarom SearXNG u blokkeert en wat een 429 werkelijk betekent

Twee verschillende gebeurtenissen worden beide omschreven als "SearXNG blokkeert mij", maar ze vereisen verschillende oplossingen.

De eerste is uw eigen limiter die antwoordt met HTTP 429. Dit is de bot-beveiliging van SearXNG en deze staat standaard uit:

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 de server, aangezien dit standaard op false staat en het gedrag voor publiek gebruik reguleert.

De limiter voert verschillende controles uit. http_user_agent behandelt een niet-ingestelde User-Agent, of een User-Agent die overeenkomt met bekende tools zoals curl en wget, als een bot. http_accept behandelt 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, retourneert SearXNG een 429 en schrijft het een ERROR-regel naar de botdetection-logger.

Dit mislukt 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 overeenkomen. Daarom krijgen scripts en AI-agents een 429 van een instantie die in een browser prima werkt, en dit is het punt dat u moet corrigeren voordat u de zoekfunctie van een agent op uw eigen instantie richt. De volledige set oorzaken en instellingen staat in de handleiding voor SearXNG rate limits en 429-fouten.

Eén valkuil bij de limiter verdient vermelding. Achter een reverse proxy ziet SearXNG het adres van de proxy in plaats van dat van de bezoeker, tenzij die proxy wordt vertrouwd:

[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 bron. Een zoekmachine besluit dat een datacenter-adres dat veel zoekopdrachten uitvoert een scraper is en stopt met het beantwoorden van uw server. U krijgt daarvoor geen 429. U krijgt een resultatenpagina waarbij de resultaten van die specifieke engine ontbreken en een foutmelding wordt genoteerd; SearXNG zal de engine na herhaalde fouten tijdelijk opschorten. De oorzaak is het IP-adres van uw VPS, dus de oplossingen liggen in de keuze van engines 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 verlaat uw zoekopdracht het netwerk vanaf hetzelfde adres als de zoekopdrachten van duizenden anderen, 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 van de hele groep in platte tekst kan inzien, 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 kan lezen? De massa helpt hier totaal niet, omdat de beheerder de ruwe tekst ziet. Een goed middenpad is een instance voor een kleine groep mensen die u kent. U krijgt een kleine massa 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; elk resultaat op de pagina is afkomstig van een upstream-zoekmachine. De kwaliteit is daarom beperkt tot de kwaliteit van de ingeschakelde engines. Schakel Google en Bing uit en de kwaliteit neemt direct af, omdat het grootste deel 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 uw klikgedrag uit het verleden. Dit werkt twee kanten op, aangezien personalisatie ook lokale relevantie biedt. Een zoekopdracht als "apotheek nu open" levert via SearXNG minder relevante resultaten op, omdat de engine geen locatiegegevens van uw apparaat heeft, enkel die van het datacenter waar uw server staat. Stel de regio in de voorkeuren in wanneer lokale resultaten belangrijk zijn.

Twee instellingen bepalen in hoeverre uw instantie gegevens lekt terwijl u de resultaten bekijkt. image_proxy staat standaard op false, waardoor miniaturen rechtstreeks van de hostende websites worden geladen en die sites uw IP-adres zien. Door image_proxy: true in te stellen, worden deze via de instantie geleid, wat extra bandbreedte en geheugen kost. Daarnaast staat formats standaard op html, waardoor een JSON (JavaScript object notation) verzoek wordt geweigerd met een 403 Forbidden:

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

Schakel json in op een publieke instantie en u heeft een gratis scraping-API gepubliceerd. Dit is de snelste manier om ervoor te zorgen dat het IP-adres van uw server wordt geblokkeerd 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 niet voor uw netwerk wat u doet. Hieruit volgen vier grenzen.

• Uw verkeer is overal ongewijzigd, behalve in het zoekveld. Al het andere dat de machine doet, verlaat uw netwerk precies zoals voorheen.
• Eén gebruiker op één server is een stabiele identificatie voor elke zoekmachine. De 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 juist wilde vermijden. Lees ze, 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 instantie die daarbij past, 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 die 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" komt de zoekopdracht ook in het toegangslogboek van de reverse proxy terecht als onderdeel van de request-regel, ongeacht of de beheerder dit wilde of niet. Gebruik een publieke instantie voor algemene zoekopdrachten waarbij advertentieprofilering de voornaamste zorg is. Typ niets in een instantie dat u niet aan de eigenaar ervan zou toevertrouwen.

Verbergt SearXNG mijn zoekopdrachten voor mijn internetprovider?

De tekst van de zoekopdracht is verborgen. De activiteit zelf 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 beiden 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-beveiliging 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, het 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 ontvangt u helemaal geen 429-fout.

Worden mijn zoekresultaten slechter door SearXNG zelf te hosten?

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