SearXNG è sicuro? Chi vede davvero le tue ricerche

SearXNG è sicuro? La risposta breve

SearXNG è sicuro in una direzione e non lo è nell’altra. Per questo, la domanda «SearXNG è sicuro?» ha una risposta solo dopo aver chiarito da chi vuoi nasconderti. SearXNG è un metamotore di ricerca: prende la tua query, la invia a Google, Bing, DuckDuckGo e agli altri motori che hai abilitato, quindi unisce i risultati ricevuti in un’unica pagina. I motori vedono l’istanza. L’istanza vede te.

Su un’istanza pubblica gestita da una persona che non conosci, quella persona riceve ogni query che digiti, in chiaro, e nulla nella relativa pagina informativa può dimostrare come la utilizzi. Sul tuo server, i motori upstream vedono l’indirizzo del server invece di quello di casa tua. Questo scambio costituisce l’intera storia della privacy e vale esattamente quanto il server su cui viene eseguito.

Nessuna parte di questo sistema nasconde le tue ricerche alla tua rete. Il tuo provider di servizi Internet (ISP) vede comunque una connessione all’istanza. Il tuo resolver DNS (domain name system) vede comunque il nome host. Tieni presente questo limite mentre leggi il resto.

Cosa cambia SearXNG in una richiesta di ricerca

Quando esegui una ricerca direttamente su Google, Google riceve il tuo indirizzo IP, i cookie, l'header User-Agent e la pagina di provenienza, tutti associati a un profilo che rimane attivo oltre la sessione. SearXNG si interpone tra te e il motore di ricerca. La documentazione descrive le due operazioni principali: «rimuovere i dati privati dalle richieste inviate ai servizi di ricerca» e «generare un profilo browser casuale per ogni richiesta». I cookie non vengono mai inoltrati a un motore di ricerca. Le preferenze vengono memorizzate nel tuo browser, non in un account sul server.

Due header di risposta vengono forniti per impostazione predefinita e svolgono entrambi una funzione concreta:

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

Referrer-Policy: no-referrer significa che, quando fai clic su un risultato, il sito di destinazione non può sapere quale pagina di ricerca ti ha indirizzato, perché il browser omette l'header Referer. X-Robots-Tag: noindex, nofollow impedisce che la tua istanza e le relative pagine dei risultati vengano incluse negli indici dei motori di ricerca.

SearXNG non modifica la query. La query arriva all'istanza completa e leggibile, perché TLS (Transport Layer Security) termina sull'istanza. Tutti i punti seguenti derivano da questo fatto.

Su un'istanza pubblica, l'operatore vede ogni query

La documentazione del progetto lo dichiara chiaramente: gli utenti di un'istanza pubblica «devono fidarsi dell'amministratore dell'istanza» e non possono sapere «se le loro richieste vengono registrate, aggregate e inviate o vendute a terzi». Una dichiarazione di assenza di log nella pagina iniziale resta una dichiarazione. Dall'esterno non è possibile verificarla: o ci si fida, oppure no.

La registrazione nei log è anche la soluzione più semplice, perché la configurazione predefinita distribuita inserisce la query nell'URL:

server:
  method: "GET"

Con GET, la query viene trasmessa come ?q=... nella riga della richiesta. Un normale reverse proxy scrive questa riga nel proprio access log, quindi le query vengono registrate senza che nessuno debba decidere esplicitamente di registrarle:

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

Sulla tua istanza puoi verificarlo direttamente:

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

Le tue ricerche compaiono nel log perché il formato di log combined di nginx scrive $request, cioè l'intera riga della richiesta, inclusa la query string. SearXNG non può intervenire su questo comportamento. Impostare l'istanza su method: "POST" sposta la query nel corpo della richiesta, impedendo così che compaia nell'access log e nella cronologia del browser. La documentazione dichiara correttamente che POST presenta svantaggi che «limitano gravemente la facilità d'uso per l'utente finale», soprattutto per quanto riguarda il pulsante Indietro del browser. È un compromesso scelto consapevolmente.

Da questo derivano due conseguenze per qualsiasi istanza pubblica. L'operatore può leggere le tue query, anche se non intendeva raccoglierle. Un backup o una compromissione del server consentono di accedere allo stesso log.

Sul tuo VPS, i motori vedono il server invece di te

Esegui la tua istanza su un VPS (virtual private server) e il cambiamento è semplice da descrivere. Google non riceve più il tuo indirizzo IP di casa insieme alla query. Riceve l'indirizzo IP del tuo server insieme alla query. Non può collegare quella ricerca al tuo account con sessione attiva, al tuo telefono o al profilo pubblicitario associato alla connessione della tua abitazione. La procedura di installazione è descritta nella guida per eseguire una propria istanza SearXNG su un VPS.

È importante chiarire che cosa non cambia. I motori vedono ancora il testo della query, l'orario, la lingua e la regione richieste, oltre alla sequenza e alla forma di tutte le ricerche che esegui nell'arco di mesi, raggruppate sotto un unico indirizzo stabile. Se sei l'unico utente, quell'indirizzo identifica un flusso associato a una singola persona, anche se non contiene il suo nome. Per interrompere questo raggruppamento, l'istanza deve raggiungere i motori tramite un proxy in uscita o Tor. SearXNG supporta entrambe le opzioni, ma si tratta di un'attività separata.

Cosa continuano a vedere il tuo ISP, il resolver e il tuo host

Quattro osservatori non sono influenzati da nessuno di questi interventi.

• Il tuo ISP vede una connessione TLS all'indirizzo IP della tua istanza e vede il nome host nel campo SNI (server name indication), inviato in chiaro durante l'handshake. Non vede la query.
• Il tuo resolver DNS vede la ricerca di quel nome host. Monitorala sul client con sudo tcpdump -ni any port 53 mentre carichi la pagina: comparirà la richiesta del record A per la tua istanza.
• Il provider VPS gestisce l'hardware, quindi può leggere il disco e la memoria della macchina virtuale. La cifratura del disco all'interno di una VM a noleggio non risolve il problema, perché il sistema in esecuzione contiene la chiave.
• Chiunque disponga dell'accesso root sull'istanza vede tutto. Questo include te e chiunque riesca a ottenere l'accesso in seguito.

C'è un altro elemento che spesso viene dimenticato. Le richieste in uscita del server sono visibili dalla rete del server stesso, quindi il provider può vedere che la tua macchina comunica con Google e Bing per tutto il giorno. Si tratta di un modello di traffico, non di una query, ma fornisce comunque informazioni.

A questo punto entra in gioco la domanda sulla VPN. Una VPN (virtual private network) trasferisce ciò che vede il tuo ISP a ciò che vede il provider VPN. Non cambia nulla per il gestore dell'istanza e non cambia nulla per i motori di ricerca, perché sono i motori a comunicare con il tuo server, non con te. Il confronto corretto tra le due soluzioni è riportato in il confronto tra un VPS e una VPN.

Perché SearXNG blocca le richieste e cosa significa davvero un 429

Due eventi diversi vengono descritti come “SearXNG mi ha bloccato”, ma richiedono correzioni diverse.

Il primo consiste nella risposta del limiter locale con HTTP 429. Questa è la protezione antobot di SearXNG ed è disattivata per impostazione predefinita:

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

Ad agosto 2026 il limiter richiede un database Valkey e legge le regole da /etc/searxng/limiter.toml. Imposta anche server.public_instance: true se il server viene utilizzato davvero da utenti esterni, perché per impostazione predefinita è false e controlla il comportamento destinato all’uso pubblico.

Il limiter esegue diverse verifiche. http_user_agent considera un bot una richiesta con User-Agent non impostato oppure corrispondente a strumenti noti come curl e wget. http_accept considera un bot una richiesta il cui header Accept non contiene text/html. link_token considera sospetto un client che non richiede mai l’URL /client<token>.css, che un browser reale carica. Quando una verifica rileva un problema, SearXNG restituisce 429 e scrive una riga ERROR nel logger botdetection.

Pertanto questo comando fallisce, come previsto:

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

curl invia User-Agent: curl/8.5.0 e Accept: */*, quindi vengono attivate contemporaneamente due verifiche. Per questo gli script e gli agenti AI ricevono 429 da un’istanza che funziona correttamente in un browser. È questo il problema da correggere prima di indirizzare la funzionalità di ricerca di un agente verso la propria istanza. L’elenco completo delle cause e delle impostazioni è disponibile nella guida ai rate limit e agli errori 429 di SearXNG.

È importante conoscere anche un problema del limiter con i reverse proxy. Dietro un reverse proxy, SearXNG vede l’indirizzo del proxy invece di quello del visitatore, a meno che il proxy non sia considerato attendibile:

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

L’elenco predefinito include un proxy eseguito sullo stesso host. Un proxy in una rete Docker separata arriva da un indirizzo come 172.18.0.5, che non è incluso nell’elenco. Di conseguenza, tutti i visitatori vengono conteggiati come un unico client e il primo utente con molte richieste blocca tutti gli altri. Aggiungi quella subnet a trusted_proxies.

Il secondo tipo di blocco avviene a monte. Un engine può stabilire che un indirizzo di datacenter, dal quale provengono molte ricerche, appartiene a uno scraper e può smettere di rispondere al server. In questo caso non ricevi un 429. Ricevi una pagina di risultati in cui mancano i risultati di quell’engine e viene indicato un errore associato a tale engine. Dopo errori ripetuti, SearXNG sospende temporaneamente l’engine. La causa è l’indirizzo su cui risiede il VPS. Le soluzioni consistono quindi nello scegliere engine diversi e nell’attendere, non nel modificare il limiter.

Condividere un'istanza con estranei è utile o dannoso?

Entrambe le cose, in direzioni opposte. Per questo la risposta non è immediata. L'anonimato è un effetto della folla. Su un'istanza pubblica molto utilizzata, la tua query proviene dallo stesso indirizzo di migliaia di query di altre persone. Nessun motore può distinguerla dalle altre. Sulla tua istanza per un solo utente, ogni query proveniente da quell'indirizzo è tua. I motori ricevono quindi un flusso pulito di un'unica persona, senza un nome associato.

Per l'operatore il rapporto è inverso. Una folla numerosa significa che un estraneo conserva le query in chiaro di tutti, comprese le tue. Sul tuo server conservi le tue query e quelle di nessun altro.

Scegli quindi in base alla minaccia concreta. Temi la profilazione pubblicitaria e il tracciamento tra siti? La folla offre una buona protezione e il rischio legato all'operatore è ridotto. Temi che una persona o un'azienda specifica possa leggere una determinata ricerca che hai eseguito? La folla non aiuta affatto, perché l'operatore vede il testo in chiaro. Un buon compromesso consiste nell'usare un'istanza per un piccolo gruppo di persone che conosci. Ottieni una folla ridotta e un operatore che puoi verificare, perché l'operatore sei tu.

I risultati di SearXNG sono migliori di quelli di Google?

No. SearXNG non dispone di un indice proprio, quindi ogni risultato visualizzato proviene da un motore upstream. La qualità massima dipende dai motori abilitati. Se disabiliti Google e Bing, la qualità diminuisce lo stesso giorno, perché gran parte della copertura generale del Web proveniva da questi motori.

Ciò che cambia è il trattamento applicato alle tue richieste. Nessun componente crea un profilo pubblicitario a partire dalla query e nessun componente riordina i risultati in base a ciò che hai selezionato la settimana scorsa. Questo ha effetti in entrambe le direzioni, perché la personalizzazione include anche l'intento locale. Una ricerca come "farmacia aperta ora" restituisce risultati meno pertinenti tramite SearXNG, perché il motore non dispone di informazioni sulla posizione del tuo server oltre al datacenter in cui si trova. Imposta la regione nelle preferenze quando i risultati locali sono importanti.

Due impostazioni determinano quante informazioni divulga la tua istanza mentre consulti i risultati. image_proxy è false per impostazione predefinita, quindi le miniature vengono caricate direttamente dai siti che le ospitano e questi siti vedono l'indirizzo del tuo browser. Impostando image_proxy: true, le miniature vengono invece inoltrate tramite l'istanza, con un maggiore consumo di larghezza di banda e memoria. Inoltre, formats viene fornito solo come html, quindi una richiesta JSON (JavaScript object notation) viene rifiutata con 403 Forbidden:

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

Abilitando json su un'istanza pubblica, pubblichi un'API gratuita per lo scraping. È il modo più rapido per fare bloccare l'indirizzo del tuo server dai motori da cui dipendi. Lascialo disabilitato oppure proteggilo con l'autenticazione.

Dove termina la tutela della privacy di SearXNG

SearXNG nasconde ai motori di ricerca chi sta effettuando la ricerca. Non nasconde ciò che stai facendo alla tua rete. Da questo derivano quattro limiti.

• Il tuo traffico non cambia in alcun punto, tranne che nella casella di ricerca. Tutto il resto che il computer esegue lascia la rete esattamente come prima.
• Un utente su un unico server è un identificatore stabile per ogni motore di ricerca. L'identificatore non contiene il nome dell'utente, e questo è l'unico vantaggio.
• Il gestore di qualsiasi istanza legge la query in testo normale. Essere tu stesso il gestore è l'unica variante che puoi verificare.
• I tuoi log degli accessi ricostruiscono il registro che cercavi di evitare. Consultali e passa a method: "POST" se preferisci che restino vuoti.

SearXNG sposta l'osservatore. Non elimina l'osservazione. Decidi quale osservatore vuoi evitare, scegli l'istanza più adatta e non considerare un'interfaccia di ricerca un software per l'anonimato.

FAQ

SearXNG è sicuro da usare su un'istanza pubblica?

È sicuro rispetto ai motori di ricerca, ma non rispetto al gestore dell'istanza. La query raggiunge quel server in testo in chiaro e la documentazione del progetto specifica che gli utenti «devono fidarsi dell'amministratore dell'istanza» e non possono sapere «se le loro richieste vengono registrate, aggregate e inviate o vendute a terze parti». Con il valore predefinito distribuito di method: "GET", la query finisce anche nel log degli accessi del reverse proxy come parte della riga della richiesta, indipendentemente dal fatto che il gestore lo volesse o meno. Usate un'istanza pubblica per le ricerche ordinarie, quando il problema è la profilazione pubblicitaria. Non inserite dati che non consegnereste al gestore dell'istanza.

SearXNG nasconde le mie ricerche al provider Internet?

Il testo della query è nascosto. L'attività no. Il provider vede una connessione TLS verso l'indirizzo dell'istanza e il nome host nel campo SNI in chiaro dell'handshake; il resolver DNS vede la richiesta di risoluzione per quel nome host. Nessuno dei due vede che cosa avete cercato, perché la connessione è cifrata. SearXNG non è una VPN e non protegge nessun'altra attività del computer.

Perché SearXNG restituisce un errore 429?

Il codice 429 proviene dal limiter dell'istanza. Si tratta di una protezione contro i bot, non di un messaggio di Google. Le sue verifiche segnalano una richiesta il cui header Accept non contiene text/html e uno User-Agent non impostato o corrispondente a strumenti come curl e wget. Una terza verifica, il token dei link, segnala un client che non recupera mai l'URL /client<token>.css caricato dal browser. Se il reverse proxy non è indicato in trusted_proxies di /etc/searxng/limiter.toml, ogni visitatore viene conteggiato come un unico client. Un solo utente intenso può quindi bloccare tutti gli altri. Se invece un motore upstream blocca il server, i risultati di quel motore semplicemente non vengono mostrati nella pagina e non viene restituito alcun 429.

Il self-hosting di SearXNG peggiora i risultati delle ricerche?

A volte, per due motivi importanti. I risultati provengono dai motori upstream, quindi un indirizzo di un datacenter soggetto a rate limiting da parte dei motori comporta meno motori disponibili e una pagina con meno risultati. Inoltre, il ranking personalizzato viene eliminato. Questo rimuove il riordinamento basato sulla pubblicità e anche l'intento locale. Di conseguenza, le ricerche sensibili alla posizione restituiscono risultati meno pertinenti finché non impostate la regione nelle preferenze.