SearXNG est-il sûr ? Ce qu’il masque vraiment

SearXNG est-il sûr ? Réponse courte

SearXNG est sûr dans un sens et ne l’est pas dans l’autre. La question « SearXNG est-il sûr ? » n’a donc de réponse qu’une fois que vous avez précisé de qui vous cherchez à vous cacher. SearXNG est un métamoteur de recherche : il prend votre requête, l’envoie à Google, Bing, DuckDuckGo et aux autres moteurs que vous avez activés, puis regroupe les résultats dans une seule page. Les moteurs voient l’instance. L’instance vous voit.

Sur une instance publique gérée par un tiers, cette personne reçoit toutes les requêtes que vous saisissez, en clair. Rien sur sa page de présentation ne permet de vérifier ce qu’elle en fait. Sur votre propre serveur, les moteurs en amont voient l’adresse de votre serveur au lieu de celle de votre domicile. Cet échange constitue l’essentiel de la protection de la vie privée. Sa valeur dépend entièrement du serveur sur lequel l’instance fonctionne.

Cela ne masque pas vos recherches à votre propre réseau. Votre fournisseur d’accès à Internet (FAI) voit toujours une connexion vers l’instance. Votre résolveur DNS (système de noms de domaine) voit toujours le nom d’hôte. Gardez cette limite à l’esprit pour la suite.

Ce que SearXNG change pour une requête de recherche

Si vous utilisez directement Google, Google reçoit votre adresse IP, vos cookies, votre en-tête User-Agent et la page d’origine, le tout associé à un profil qui reste lié à vos activités au-delà de la session. SearXNG s’interpose. Sa documentation décrit les deux opérations qu’il effectue : « supprimer les données privées des requêtes envoyées aux services de recherche » et « générer un profil de navigateur aléatoire pour chaque requête ». Vos cookies ne sont jamais transmis à un moteur. Vos préférences sont stockées dans votre propre navigateur, et non dans un compte sur le serveur.

Deux en-têtes de réponse sont activés par défaut, et tous deux ont une fonction réelle :

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

Referrer-Policy: no-referrer signifie que, lorsque vous cliquez sur un résultat, le site de destination ne sait jamais quelle page de recherche vous a envoyé vers lui, car le navigateur omet l’en-tête Referer. X-Robots-Tag: noindex, nofollow empêche votre instance et ses pages de résultats d’apparaître dans les index des moteurs de recherche.

SearXNG ne modifie pas la requête elle-même. Celle-ci arrive complète et lisible sur l’instance, car TLS (transport layer security) y est terminé. Tout ce qui suit découle de ce fait.

Sur une instance publique, l’opérateur voit toutes les requêtes

La documentation du projet l’indique clairement : les utilisateurs d’une instance publique « doivent faire confiance à l’administrateur de cette instance » et ne peuvent pas savoir « si leurs requêtes sont journalisées, agrégées, puis envoyées ou vendues à un tiers ». Une mention d’absence de logs sur une page d’accueil reste une simple déclaration. Depuis l’extérieur, il est impossible de la vérifier. Il faut donc faire confiance à l’opérateur, ou renoncer.

La journalisation est également la solution la plus simple, car la configuration par défaut fournie place votre requête dans l’URL :

server:
  method: "GET"

Avec GET, la requête est transmise dans ?q=..., sur la ligne de requête HTTP. Tout reverse proxy standard écrit cette ligne dans son access log. Les requêtes sont donc enregistrées sans que personne ait besoin de décider explicitement de les journaliser :

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

Sur votre propre instance, vérifiez-le vous-même :

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

Vos recherches s’y trouvent, car le format de log combined de nginx écrit $request, c’est-à-dire la ligne de requête complète, chaîne de requête comprise. SearXNG n’a aucun contrôle sur ce point. Passer l’instance à method: "POST" place la requête dans le corps de la requête HTTP. Elle n’apparaît alors plus dans l’access log ni dans l’historique du navigateur. La documentation indique honnêtement que POST présente des inconvénients qui « limitent fortement la facilité d’utilisation pour l’utilisateur final », notamment avec le bouton Précédent du navigateur. C’est un compromis que vous choisissez délibérément.

Deux conséquences en découlent pour toute instance publique. L’opérateur peut lire vos requêtes, même s’il n’avait pas l’intention de les collecter. Une sauvegarde ou une intrusion permet d’accéder aux mêmes logs.

Sur votre propre VPS, les moteurs voient votre serveur au lieu de vous

Exécutez votre propre instance sur un VPS (serveur privé virtuel), et le changement est simple à résumer. Google ne reçoit plus l’adresse IP de votre domicile avec votre requête. Il reçoit l’adresse IP de votre serveur avec votre requête. Il ne peut pas associer cette recherche à votre compte connecté, à votre téléphone ou au profil publicitaire associé à la connexion de votre foyer. La mise en place est décrite dans le guide pour exécuter votre propre instance SearXNG sur un VPS.

Soyez clair sur ce qui n’a pas changé. Les moteurs voient toujours le texte de la requête, son horaire, la langue et la région demandées, ainsi que la structure de tout ce que vous recherchez au fil des mois, le tout regroupé sous une même adresse stable. Si vous êtes le seul utilisateur, cette adresse correspond à un flux par personne, sans nom associé. Pour empêcher ce regroupement, l’instance doit accéder aux moteurs via un proxy sortant ou via Tor. SearXNG prend en charge ces deux options, mais leur configuration constitue une tâche distincte.

Ce que votre FAI, votre résolveur et votre hébergeur voient encore

Quatre observateurs ne sont pas concernés par ces mesures.

• Votre FAI voit une connexion TLS vers l’adresse IP de votre instance. Il voit également le nom d’hôte dans le champ SNI (indication du nom du serveur), qui est envoyé en clair pendant la négociation. Il ne voit pas la requête.
• Votre résolveur DNS voit la résolution de ce nom d’hôte. Surveillez-la depuis le client avec sudo tcpdump -ni any port 53 pendant le chargement de la page : la requête d’enregistrement A vers votre instance apparaît.
• Votre fournisseur de VPS gère le matériel. Il peut donc lire le disque et la mémoire de la machine virtuelle. Le chiffrement du disque à l’intérieur d’une VM louée ne change rien, car le système en cours d’exécution détient la clé.
• Toute personne disposant de root sur l’instance voit tout. Cela vous inclut, ainsi que toute personne qui y accéderait ultérieurement.

Il y a un autre observateur souvent oublié. Les requêtes sortantes de votre serveur sont visibles depuis le réseau du serveur. Votre fournisseur peut donc voir que votre machine communique avec Google et Bing toute la journée. Il s’agit d’un profil de trafic, et non d’une requête, mais cela fournit tout de même des informations.

C’est à ce moment que la question du VPN se pose. Un VPN (réseau privé virtuel) déplace ce que voit votre FAI vers ce que voit l’entreprise qui exploite le VPN. Il ne change rien pour l’opérateur de l’instance ni pour les moteurs, car ceux-ci communiquent avec votre serveur, et non avec vous. Les deux solutions sont comparées correctement dans la comparaison entre un VPS et un VPN.

Pourquoi SearXNG vous bloque et ce que signifie réellement une erreur 429

Deux événements différents sont souvent décrits comme « SearXNG m’a bloqué », et leurs corrections ne sont pas les mêmes.

Le premier cas concerne votre propre limiteur, qui vous répond avec HTTP 429. Il s’agit de la protection contre les bots de SearXNG, désactivée par défaut :

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

Depuis août 2026, le limiteur nécessite une base de données Valkey et lit ses règles dans /etc/searxng/limiter.toml. Définissez également server.public_instance: true si des personnes externes utilisent réellement le serveur, car cette option vaut false par défaut et contrôle le comportement prévu pour une utilisation publique.

Le limiteur effectue plusieurs vérifications. http_user_agent considère comme un bot un User-Agent absent ou correspondant à des outils connus comme curl et wget. http_accept considère comme un bot toute requête dont l’en-tête Accept ne contient pas text/html. link_token considère un client comme suspect s’il ne récupère jamais l’URL /client<token>.css, qu’un navigateur réel charge. Lorsqu’une vérification se déclenche, SearXNG renvoie une erreur 429 et écrit une ligne ERROR dans son logger botdetection.

Ce comportement est donc attendu :

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

curl envoie User-Agent: curl/8.5.0 et Accept: */*, ce qui déclenche deux vérifications simultanément. C’est pourquoi les scripts et les agents IA reçoivent une erreur 429 d’une instance qui fonctionne correctement dans un navigateur. C’est le premier point à corriger avant de configurer la compétence de recherche d’un agent pour utiliser votre propre instance. La liste complète des causes et des réglages se trouve dans le guide des limites de débit et des erreurs 429 de SearXNG.

Un piège du limiteur mérite d’être signalé. Derrière un reverse proxy, SearXNG voit l’adresse du proxy au lieu de celle du visiteur, sauf si ce proxy est approuvé :

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

La liste par défaut couvre un proxy exécuté sur le même hôte. Un proxy placé dans un réseau Docker distinct arrive depuis une adresse telle que 172.18.0.5, qui ne figure pas dans la liste. Tous les visiteurs sont alors comptés comme un seul client, et le premier utilisateur très actif bloque tous les autres. Ajoutez ce sous-réseau à trusted_proxies.

Le second type de blocage se produit en amont. Un moteur considère qu’une adresse de datacenter qui exécute de nombreuses recherches est celle d’un scraper et cesse de répondre à votre serveur. Vous ne recevez pas d’erreur 429 dans ce cas. Vous obtenez une page de résultats où les résultats de ce moteur sont absents, avec un échec indiqué pour celui-ci. Après plusieurs échecs, SearXNG suspend temporairement le moteur. La cause vient de l’adresse utilisée par votre VPS. Les corrections consistent donc à choisir d’autres moteurs et à patienter, pas à modifier le limiteur.

Partager une instance avec des inconnus : est-ce utile ou nuisible ?

Les deux, mais dans des directions opposées. C’est pourquoi la réponse est difficile à trancher. L’anonymat repose sur un effet de foule. Sur une instance publique très utilisée, votre requête provient de la même adresse que les requêtes de milliers d’autres personnes. Aucun moteur ne peut donc facilement isoler la vôtre. Sur votre instance mono-utilisateur, toutes les requêtes provenant de cette adresse sont les vôtres. Les moteurs reçoivent alors un flux propre provenant d’une seule personne, sans nom associé.

Du côté de l’opérateur, le fonctionnement est inverse. Une foule nombreuse signifie qu’un tiers détient les requêtes en clair de tous les utilisateurs, y compris les vôtres. Sur votre propre serveur, vous détenez vos requêtes et celles de personne d’autre.

Choisissez donc en fonction de la menace qui vous concerne réellement. Vous craignez le profilage publicitaire et le suivi intersites ? La foule protège bien contre cela, et le risque lié à l’opérateur reste limité. Vous craignez qu’une personne ou une entreprise précise puisse lire une recherche précise que vous avez effectuée ? La foule ne vous aide pas du tout, car l’opérateur voit le texte brut. Une bonne solution intermédiaire consiste à utiliser une instance pour quelques personnes que vous connaissez. Vous bénéficiez d’une petite foule et d’un opérateur que vous pouvez vérifier, puisque l’opérateur, c’est vous.

Les résultats de SearXNG sont-ils meilleurs que ceux de Google ?

Non. SearXNG ne possède pas son propre index. Chaque résultat affiché vient donc d’un moteur en amont, et la qualité maximale dépend de celle des moteurs que vous avez activés. Si vous désactivez Google et Bing, la qualité baisse le jour même, car ils fournissent la majeure partie de la couverture générale du Web.

Ce qui change, c’est le traitement qui vous est appliqué. Aucun service ne crée de profil publicitaire à partir de la requête et aucun ne réordonne les résultats selon ce sur quoi vous avez cliqué la semaine dernière. Cela fonctionne dans les deux sens, car la personnalisation prend aussi en compte l’intention locale. Une recherche comme « pharmacie ouverte maintenant » donne des résultats moins pertinents avec SearXNG, car le moteur ne dispose d’aucun signal de localisation pour votre serveur, hormis le datacenter où il se trouve. Définissez la région dans les préférences lorsque les résultats locaux sont importants.

Deux paramètres déterminent la quantité d’informations divulguées par votre instance pendant que vous consultez ces résultats. image_proxy vaut false par défaut. Les miniatures sont donc chargées directement depuis les sites qui les hébergent, et ces sites voient l’adresse de votre navigateur. En définissant image_proxy: true, vous les faites transiter par l’instance, au prix d’une consommation accrue de bande passante et de mémoire. De plus, formats est fourni uniquement avec html. Une requête JSON (JavaScript object notation) est donc refusée avec l’erreur 403 Forbidden :

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

Activez json sur une instance publique et vous aurez publié une API gratuite de scraping. C’est le moyen le plus rapide de faire bloquer l’adresse de votre serveur par les moteurs dont vous dépendez. Laissez ce paramètre désactivé ou protégez-le par une authentification.

Limites de la confidentialité offerte par SearXNG

SearXNG dissimule votre identité aux moteurs de recherche. Il ne dissimule pas vos activités à votre réseau. Quatre limites en découlent.

• Votre trafic reste inchangé partout, sauf dans la zone de recherche. Tout le reste de l’activité de la machine sort de votre réseau exactement comme avant.
• Un utilisateur sur un serveur donné constitue un identifiant stable pour chaque moteur. Cet identifiant ne contient aucun nom, et c’est tout l’intérêt de cette configuration.
• L’opérateur de toute instance peut lire la requête en clair. Être vous-même l’opérateur est la seule version de ce fonctionnement que vous pouvez vérifier.
• Vos propres journaux d’accès reconstituent l’historique que vous cherchiez à éviter. Consultez-les, puis passez à method: "POST" si vous préférez qu’ils restent vides.

SearXNG déplace l’observateur. Il ne supprime pas l’observation. Déterminez quel observateur vous préoccupe, choisissez l’instance correspondante et ne considérez pas une interface de recherche comme un logiciel d’anonymat.

FAQ

SearXNG est-il sûr à utiliser sur une instance publique ?

Il est sûr vis-à-vis des moteurs de recherche, mais pas vis-à-vis de l’opérateur. Votre requête atteint ce serveur en clair, et la documentation du projet indique que les utilisateurs « doivent faire confiance à l’administrateur de cette instance » et ne peuvent pas savoir « si leurs requêtes sont journalisées, regroupées, puis envoyées ou vendues à un tiers ». Avec la valeur par défaut fournie de method: "GET", la requête apparaît également dans le journal d’accès du reverse proxy, dans la ligne de requête, que l’opérateur l’ait voulu ou non. Utilisez une instance publique pour des recherches ordinaires si votre préoccupation concerne le profilage publicitaire. N’y saisissez rien que vous ne remettriez pas à son propriétaire.

SearXNG masque-t-il mes recherches à mon fournisseur d’accès à Internet ?

Le texte de la requête est masqué. L’activité ne l’est pas. Votre fournisseur voit une connexion TLS vers l’adresse de votre instance, ainsi que le nom d’hôte dans le champ SNI en clair de la négociation. Votre résolveur DNS voit également la résolution de ce nom d’hôte. Aucun des deux ne voit ce que vous avez recherché, car la connexion est chiffrée. SearXNG n’est pas un VPN et ne protège rien d’autre sur votre machine.

Pourquoi SearXNG renvoie-t-il une erreur 429 ?

L’erreur 429 vient du limiteur de l’instance elle-même. Il s’agit d’une protection contre les bots, pas d’un message de Google. Ses sondes signalent une requête dont l’en-tête Accept ne contient pas text/html, ainsi qu’un User-Agent absent ou correspondant à des outils comme curl et wget. Une troisième sonde, le jeton de lien, signale un client qui ne récupère jamais l’URL /client<token>.css chargée par un navigateur. Derrière un reverse proxy absent de trusted_proxies dans /etc/searxng/limiter.toml, tous les visiteurs sont comptés comme un seul client. Un utilisateur actif peut donc bloquer tous les autres. Lorsqu’un moteur en amont bloque votre serveur, ses résultats disparaissent simplement de la page et vous n’obtenez aucune erreur 429.

L’auto-hébergement de SearXNG dégrade-t-il mes résultats de recherche ?

Parfois, pour deux raisons importantes. Les résultats proviennent de moteurs en amont. Une adresse de datacenter que ces moteurs limitent signifie que moins de moteurs répondent et que la page contient moins de résultats. Le classement personnalisé disparaît également. Cela supprime le réordonnancement piloté par la publicité, mais aussi la prise en compte du contexte local. Les recherches sensibles à la localisation renvoient donc des réponses moins pertinentes tant que vous n’avez pas défini votre région dans les préférences.