SearXNG est-il sûr pour vos recherches ?

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 inconnu, cette personne reçoit chaque requête que vous saisissez, en clair. Rien sur sa page de présentation ne peut prouver 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. Ce remplacement constitue toute 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 auprès de votre propre réseau. Votre fournisseur d’accès à Internet (FAI) voit toujours une connexion vers l’instance. Votre résolveur DNS (domain name system) 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 interrogez directement Google, Google reçoit votre adresse IP, vos cookies, votre en-tête User-Agent et la page d’origine de la requête. Toutes ces données sont associées à un profil qui survit à la session. SearXNG s’interpose entre les deux. Sa documentation décrit les deux opérations effectuées : « 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 jouent un rôle réel :

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 la terminaison TLS (Transport Layer Security) y est effectuée. Tous les points ci-dessous découlent de ce fait.

Sur une instance publique, l’opérateur voit chaque requête

La documentation du projet le dit 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 affirmation d’absence de journaux sur une page d’accueil reste une affirmation. Depuis l’extérieur, il est impossible de la vérifier : il faut donc faire confiance, ou renoncer. Certaines instances publiques exécutent encore le Searx d’origine plutôt que ce fork, ce qui est important, car Searx n’a reçu aucun commit de code depuis 2023 et un logiciel de recherche qui n’est plus maintenu est un élément supplémentaire auquel vous faites confiance sans pouvoir le vérifier.

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 sous la forme de ?q=... dans la ligne de requête. Tout reverse proxy standard écrit cette ligne de requête dans son access log. Les requêtes sont donc enregistrées sans que personne n’ait besoin de décider 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 apparaissent dans ce fichier, car le format de log combined de nginx écrit $request, c’est-à-dire la ligne de requête complète, query string 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 donc 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 compromission donne accès au même log.

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

Exécutez votre propre instance sur un VPS (serveur privé virtuel). 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 relier cette recherche à votre compte connecté, à votre téléphone ni au profil publicitaire associé à votre connexion domestique. 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, l’heure, la langue et la région demandées, ainsi que le profil de l’ensemble de vos recherches sur plusieurs mois, le tout regroupé sous une même adresse stable. Si vous êtes le seul utilisateur, cette adresse correspond à un flux individuel qui ne porte pas votre nom. 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 mise en place constitue une tâche distincte.

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

Quatre observateurs ne sont pas affectés par tout cela.

• 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), transmis en clair pendant le handshake. Il ne voit pas la requête.
• Votre résolveur DNS voit la résolution de ce nom d’hôte. Sur le client, surveillez-la 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 concerne, mais aussi toute personne qui y accéderait ultérieurement.

Accéder à l’instance comme à un service onion Tor supprime les deux premières sources de visibilité. Il n’y a alors aucun nom d’hôte public à résoudre ni aucun champ SNI à lire. Le guide pour ajouter un service onion v3 à un VPS décrit la configuration ainsi que les fuites qui permettraient sinon de relier cette adresse à l’IP publique de votre serveur.

Il y en a une autre que l’on oublie souvent. Les requêtes sortantes de votre serveur sont visibles depuis le réseau du serveur lui-même. Votre fournisseur peut donc voir que votre machine communique toute la journée avec Google et Bing. Il s’agit d’un profil de trafic plutôt que d’une requête, mais il révèle tout de même certaines informations.

C’est à ce moment que se pose la question du VPN. Un VPN (réseau privé virtuel) déplace ce que voit votre FAI vers ce que voit l’entreprise qui fournit le VPN. Il ne change rien pour l’opérateur de l’instance ni pour les moteurs de recherche, car ceux-ci communiquent avec votre serveur et non avec vous. La comparaison correcte entre les deux est présentée dans l’analyse comparative d’un VPS et d’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é ». Ils ne se corrigent pas de la même façon.

Le premier est votre propre limiteur, qui vous répond avec une erreur 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

En août 2026, le limiteur nécessite une base de données Valkey et lit ses règles depuis /etc/searxng/limiter.toml. Définissez également server.public_instance: true si des utilisateurs externes utilisent réellement le serveur, car sa valeur par défaut est false et ce paramètre contrôle le comportement destiné à un usage public.

Le limiteur effectue plusieurs contrôles. 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 lorsqu’il ne récupère jamais l’URL /client<token>.css qu’un navigateur réel charge. Lorsqu’un contrôle est déclenché, 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 contrôles 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. L’ensemble des causes et des paramètres est décrit 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 situé dans un réseau Docker distinct se connecte 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 actif bloque tous les autres. Ajoutez ce sous-réseau à trusted_proxies.

Le second type de blocage se produit en amont. Un moteur peut considérer qu’une adresse de datacenter qui effectue de nombreuses recherches est celle d’un scraper, puis cesser 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 solutions consistent donc à choisir d’autres moteurs et à patienter, pas à modifier le limiteur.

Partager une instance avec des inconnus aide-t-il ou nuit-il ?

Les deux, dans des directions opposées. C’est pourquoi la réponse semble difficile à trancher. L’anonymat repose sur l’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 isoler la vôtre. Sur votre instance mono-utilisateur, chaque requête provenant de cette adresse est la vôtre. Les moteurs reçoivent un flux propre provenant d’une seule personne, sans nom associé.

Du côté de l’opérateur, c’est l’inverse. Une grande foule signifie qu’un inconnu détient les requêtes en clair de tout le groupe, y compris les vôtres. Avec 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 les limite efficacement, et le risque lié à l’opérateur reste faible. Vous craignez qu’une personne ou une entreprise précise lise 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. Un bon compromis consiste à utiliser une instance pour quelques personnes que vous connaissez. Vous bénéficiez d’une petite foule et vous pouvez vérifier l’opérateur, puisque 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é provient donc d’un moteur en amont, et la qualité maximale dépend 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 profil publicitaire n’est créé à partir de la requête, et les résultats ne sont pas réordonnés selon ce sur quoi vous avez cliqué la semaine dernière. Cela fonctionne dans les deux sens, car la personnalisation fournit aussi des informations sur l’intention locale. Une recherche comme « pharmacie ouverte maintenant » donne des résultats moins pertinents avec SearXNG, car le moteur ne dispose d’aucune information de localisation pour votre serveur, en dehors du 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 que votre instance divulgue 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. Si vous définissez image_proxy: true, l’instance les relaie à votre place, au prix d’une consommation accrue de bande passante et de mémoire. De plus, formats est fourni uniquement avec la valeur 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 de scraping gratuite. C’est le moyen le plus rapide de faire bloquer l’adresse de votre serveur par les moteurs dont vous dépendez. Laissez cette option désactivée ou protégez-la par une authentification.

Où s’arrête la protection de la vie privée offerte par SearXNG

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

• Votre trafic reste inchangé partout, sauf dans la zone de recherche. Tout le reste des activités de la machine quitte 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’avantage.
• L’opérateur de toute instance lit la requête en clair. Être vous-même l’opérateur est la seule configuration 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 la surveillance. 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 arrive en clair sur ce serveur. 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, agrégé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 l’access log du reverse proxy, dans la ligne de requête, que l’opérateur l’ait voulu ou non. Utilisez une instance publique pour les recherches ordinaires lorsque vous cherchez surtout à éviter le profilage publicitaire. N’y saisissez rien que vous ne remettriez pas directement à 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 du handshake. 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 ?

Le code 429 vient du propre limiter de l’instance. 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 aucun code 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. Si ces moteurs limitent une adresse de datacenter, moins de moteurs répondent et la page contient moins de résultats. Le classement personnalisé disparaît également. Cela supprime le réordonnancement fondé sur la publicité, mais aussi la prise en compte des intentions locales. Les recherches dépendant de la localisation donnent donc des résultats moins pertinents tant que vous n’avez pas défini votre région dans les préférences.