SearXNG è sicuro? Chi vede davvero le tue ricerche

SearXNG è sicuro? La risposta breve

SearXNG è sicuro in una direzione e non lo è nell’altra. 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 in un’unica pagina. I motori vedono l’istanza. L’istanza vede te.

Su un’istanza pubblica gestita da una persona sconosciuta, quella persona riceve ogni query che digiti, in testo semplice. Nulla nella relativa pagina informativa può dimostrare come utilizzi quei dati. Sul tuo server, i motori upstream vedono l’indirizzo del server invece di quello di casa tua. Questo scambio costituisce l’intera protezione della privacy, che vale esattamente quanto il server su cui l’istanza è in esecuzione.

Nulla di tutto questo 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

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

Due header di risposta sono attivi 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 dei risultati ti ha indirizzato, perché il browser omette l'header Referer. X-Robots-Tag: noindex, nofollow impedisce che la tua istanza e le pagine dei risultati vengano incluse negli indici dei motori di ricerca.

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

In un'istanza pubblica, il gestore vede ogni query

La documentazione del progetto lo dichiara chiaramente: gli utenti di un'istanza pubblica «devono fidarsi dell'amministratore di quell'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 principale resta una dichiarazione. Dall'esterno non è possibile verificarla: o ci si fida, oppure non si usa il servizio. Alcune istanze pubbliche eseguono ancora Searx originale invece di questo fork. È un aspetto rilevante, perché Searx non riceve commit di codice dal 2023 e un software di ricerca non mantenuto è un ulteriore componente di cui ci si fiderebbe senza poterlo verificare.

La registrazione nei log è anche la soluzione che richiede meno lavoro, 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. Qualsiasi reverse proxy ordinario scrive quella 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, verifica direttamente:

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

Le tue ricerche sono presenti perché il formato di log combined di nginx scrive $request, cioè la riga completa della richiesta, inclusa la query string. SearXNG non può intervenire su questo comportamento. Impostando l'istanza su method: "POST", la query viene spostata nel corpo della richiesta; di conseguenza non compare più nell'access log né 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. Il gestore può leggere le tue query, anche se non aveva intenzione di raccoglierle. Un backup o una compromissione del server consente 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ù l'indirizzo IP di casa insieme alla query. Riceve l'indirizzo IP del tuo server insieme alla query. Non può associare quella ricerca al tuo account con sessione attiva, al tuo telefono o al profilo pubblicitario associato alla connessione della tua abitazione. La procedura di configurazione è descritta nella guida per eseguire una propria istanza SearXNG su un VPS.

È importante chiarire che cosa non è cambiato. I motori vedono ancora il testo della query, l'orario, la lingua e la regione richieste, oltre alla sequenza complessiva delle ricerche effettuate nell'arco di mesi, tutto raggruppato sotto un unico indirizzo stabile. Se sei l'unico utente, quell'indirizzo rappresenta 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 modalità, ma richiedono un'attività separata.

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

Quattro osservatori non sono interessati da nessuna di queste modifiche.

• 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 richiesta di risoluzione per quel nome host. Monitorala sul client con sudo tcpdump -ni any port 53 mentre carichi la pagina: compare 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 noleggiata non elimina questo accesso, perché il sistema in esecuzione contiene la chiave.
• Chiunque disponga dell'accesso root all'istanza vede tutto. Questo include te e chiunque riesca a ottenere l'accesso in seguito.

Raggiungere l'istanza come servizio onion Tor elimina i primi due elementi, perché non esiste un nome host pubblico da risolvere né un campo SNI da leggere. La guida per aggiungere un servizio onion v3 a un VPS descrive la configurazione e le perdite di informazioni che altrimenti collegherebbero quell'indirizzo all'IP pubblico del tuo server.

Ce n'è un altro 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 continuamente con Google e Bing. Questo è un modello di traffico, non una query, ma fornisce comunque informazioni.

A questo punto entra in gioco la VPN. Una VPN (virtual private network) trasferisce ciò che vede il tuo ISP a ciò che vede il provider VPN. Non cambia nulla per chi gestisce l'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 ti blocca e cosa significa realmente un 429

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

Il primo è il tuo limiter, che risponde con HTTP 429. Si tratta della protezione antiali bot di SearXNG, 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 previsto per l'uso pubblico.

Il limiter esegue diversi controlli. 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, caricato da un browser reale. Quando un controllo rileva un'anomalia, SearXNG restituisce 429 e scrive una riga ERROR nel logger botdetection.

Quindi 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 corrisponde contemporaneamente a due controlli. Per questo gli script e gli agenti AI ricevono un 429 da un'istanza che funziona correttamente in un browser. È il primo aspetto da correggere prima di indirizzare la funzione di ricerca di un agente alla propria istanza. L'elenco completo delle cause e delle impostazioni è disponibile nella guida ai rate limit e agli errori 429 di SearXNG.

È importante considerare anche un problema del limiter. Se si trova 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 sullo stesso host. Un proxy in una rete Docker separata si presenta con 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 un carico elevato 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 un datacenter, da cui partono molte ricerche, appartiene a uno scraper e smettere di rispondere al server. In questo caso non ricevi un 429. Ricevi una pagina dei risultati in cui mancano i risultati di quell'engine e viene indicato un errore associato a quest'ultimo. Dopo errori ripetuti, SearXNG sospende temporaneamente l'engine. La causa è l'indirizzo su cui risiede il VPS. Le soluzioni consistono quindi nello scegliere un altro engine e nell'attendere, non nel modificare il limiter.

Condividere un'istanza con persone sconosciute aiuta o danneggia la privacy?

Entrambe le cose, in direzioni opposte. Per questo la risposta è difficile da determinare. L'anonimato è un effetto della presenza di una folla. Su un'istanza pubblica molto utilizzata, la tua query proviene dallo stesso indirizzo di migliaia di query di altre persone. Nessun motore può quindi distinguerla dalle altre. Sulla tua istanza per singolo utente, ogni query proveniente da quell'indirizzo è tua. I motori ricevono così un flusso uniforme relativo a una sola persona, senza un nome associato.

Per l'operatore vale il contrario. Una folla numerosa implica che una persona sconosciuta possiede le query in testo normale di tutta la folla, comprese le tue. Sul tuo server possiedi le tue query e quelle di nessun altro.

Scegli quindi in base alla minaccia concreta che devi affrontare. Se temi la profilazione pubblicitaria e il tracciamento tra siti, la folla offre una buona protezione e il rischio legato all'operatore è limitato. Se temi che una determinata persona o azienda possa leggere una specifica ricerca che hai eseguito, la folla non aiuta affatto, perché l'operatore vede il testo in chiaro. Una buona soluzione intermedia 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 nella pagina 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.

Cambia invece il trattamento applicato alla ricerca. 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 fornisce anche informazioni sull'intento locale. Una ricerca come "farmacia aperta ora" restituisce risultati meno pertinenti tramite SearXNG, perché il motore non dispone di un segnale sulla posizione del server oltre al datacenter in cui si trova. Imposta la regione nelle preferenze quando sono necessari risultati locali.

Due impostazioni determinano quante informazioni trasmette 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 browser. Impostando image_proxy: true, le miniature vengono invece inoltrate tramite l'istanza, con un maggiore consumo di banda e memoria. Inoltre, formats viene distribuito soltanto 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. Questo è il modo più rapido per fare bloccare l'indirizzo del 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 richiesta. Non nasconde però alla tua rete ciò che stai facendo. 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 singolo 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 chiaro. Essere tu stesso il gestore è l'unica variante che puoi verificare.
• I tuoi log di accesso 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 corrispondente 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 all'operatore. La query raggiunge quel server in testo non cifrato e la documentazione del progetto specifica che gli utenti «devono fidarsi dell'amministratore di quell'istanza» e non possono sapere «se le loro richieste vengono registrate, aggregate e inviate o vendute a terzi». 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 l'operatore lo volesse o meno. Usa un'istanza pubblica per le ricerche ordinarie, quando il problema è il profiling pubblicitario. Non inserire dati in un'istanza pubblica che non consegneresti al suo proprietario.

SearXNG nasconde le mie ricerche al provider Internet?

Il testo della query viene nascosto. L'attività no. Il provider vede una connessione TLS all'indirizzo della tua istanza e il nome host nel campo SNI in chiaro dell'handshake; il resolver DNS vede la richiesta per quel nome host. Nessuno dei due vede cosa hai 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 stessa. È una protezione contro i bot, non un messaggio di Google. Le sue verifiche segnalano una richiesta il cui header Accept non contiene text/html e un User-Agent non impostato oppure 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 da un 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 molto attivo può quindi bloccare tutti gli altri. Quando invece un motore upstream blocca il server, i risultati di quel motore semplicemente non compaiono nella pagina e non viene restituito alcun errore 429.

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

A volte, per due motivi importanti. I risultati provengono dai motori upstream. Se questi limitano il traffico proveniente dall'indirizzo del datacenter, rispondono meno motori e la pagina contiene meno risultati. Inoltre, il ranking personalizzato non è disponibile. Questo elimina il riordinamento basato sulla pubblicità, ma anche l'intento locale. Le ricerche sensibili alla posizione restituiscono quindi risultati meno pertinenti finché non imposti la tua regione nelle preferenze.