¿Es seguro SearXNG? Quién ve tus búsquedas

¿Es seguro SearXNG? La respuesta breve

SearXNG es seguro en una dirección y no lo es en la otra. Por eso, la pregunta «¿es seguro SearXNG?» sólo tiene respuesta cuando se especifica de quién se quiere ocultar la actividad. SearXNG es un metabuscador: toma la consulta, la envía a Google, Bing, DuckDuckGo y a los demás motores que haya habilitado, y después combina las respuestas en una sola página de resultados. Los motores ven la instancia. La instancia le ve a usted.

En una instancia pública administrada por un desconocido, ese desconocido recibe todas las consultas que escriba, en texto sin cifrar. Nada de lo que aparezca en su página informativa puede demostrar qué hace con ellas. En su propio servidor, los motores externos ven la dirección de su servidor en lugar de la dirección de su domicilio. Ese cambio resume toda la protección de privacidad y vale exactamente lo mismo que el servidor donde se ejecuta.

Nada de esto oculta sus búsquedas de su propia red. Su proveedor de servicios de Internet (ISP) sigue viendo una conexión con la instancia. Su resolvedor DNS (sistema de nombres de dominio) sigue viendo el nombre de host. Tenga presente ese límite mientras lee el resto.

Qué cambia SearXNG en una solicitud de búsqueda

Si busca directamente en Google, Google recibe su dirección IP, sus cookies, la cabecera User-Agent y la página de procedencia. Todos estos datos quedan asociados a un perfil que sobrevive a la sesión. SearXNG se sitúa entre ambos. Su documentación describe las dos funciones que realiza: «eliminar los datos privados de las solicitudes dirigidas a los servicios de búsqueda» y «generar un perfil de navegador aleatorio para cada solicitud». Sus cookies nunca se reenvían a un motor de búsqueda. Sus preferencias se almacenan en su propio navegador, no en una cuenta del servidor.

De forma predeterminada se envían dos cabeceras de respuesta. Ambas cumplen una función real:

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

Referrer-Policy: no-referrer significa que, cuando hace clic en un resultado, el sitio de destino nunca sabe qué página de búsqueda lo remitió, porque el navegador omite la cabecera Referer. X-Robots-Tag: noindex, nofollow impide que su instancia y sus páginas de resultados aparezcan en los índices de los buscadores.

Lo que SearXNG no cambia es la consulta. La consulta llega completa y legible a la instancia porque TLS (seguridad de la capa de transporte) termina allí. Todo lo que se explica a continuación se deriva de ese hecho.

En una instancia pública, el operador ve todas las consultas

La propia documentación del proyecto lo dice claramente: los usuarios de una instancia pública «tienen que confiar en el administrador de esa instancia» y no pueden saber «si sus solicitudes se registran, agregan y envían o venden a un tercero». Una afirmación de que no se guardan registros en una página de presentación sigue siendo sólo una afirmación. Desde el exterior no hay forma de comprobarla, así que sólo queda confiar o no usarla. Algunas instancias públicas también siguen ejecutando el Searx original en lugar de este fork. Esto es importante porque Searx no ha recibido ningún commit de código desde 2023 y el software de búsqueda sin mantenimiento es otro componente en el que confiarías a ciegas.

El registro también es la opción que requiere menos esfuerzo, porque el valor predeterminado incluido pone la consulta en la URL:

server:
  method: "GET"

Con GET, la consulta viaja como ?q=... en la línea de solicitud. Cualquier reverse proxy normal escribe esa línea de solicitud en su registro de acceso. Por tanto, las consultas quedan registradas sin que nadie tenga que decidir registrarlas:

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

En su propia instancia, compruébelo:

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

Sus búsquedas aparecen ahí porque el formato de registro combined de nginx escribe $request, que es la línea de solicitud completa, incluida la cadena de consulta. SearXNG no puede intervenir en esto. Cambiar la instancia a method: "POST" mueve la consulta al cuerpo de la solicitud. Así deja de aparecer en el registro de acceso y en el historial del navegador. La documentación reconoce que POST tiene desventajas que «restringen considerablemente la facilidad de uso para el usuario final», sobre todo por el botón Atrás del navegador. Es una decisión con consecuencias que se toma de forma deliberada.

De aquí se derivan dos consecuencias para cualquier instancia pública. El operador puede leer sus consultas, aunque no tuviera intención de recopilarlas. Una copia de seguridad o una intrusión permite acceder al mismo registro.

En tu propio VPS, los motores ven tu servidor en lugar de verte a ti

Ejecuta tu propia instancia en un VPS (servidor privado virtual) y el cambio es sencillo de explicar. Google ya no recibe la dirección IP de tu conexión doméstica junto con la consulta. Recibe la dirección IP de tu servidor. No puede asociar esa búsqueda a tu cuenta con sesión iniciada, a tu teléfono ni al perfil publicitario asociado a tu conexión doméstica. La puesta en marcha se explica en la guía para ejecutar tu propia instancia de SearXNG en un VPS.

Debes tener claro qué no ha cambiado. Los motores siguen viendo el texto de la consulta, la hora, el idioma y la región que solicitaste, además del patrón de todo lo que buscas durante meses, agrupado bajo una única dirección estable. Si eres el único usuario, esa dirección representa un flujo asociado a una sola persona, aunque no incluya su nombre. Para romper esa agrupación, la instancia debe acceder a los motores mediante un proxy de salida o a través de Tor. SearXNG admite ambas opciones, pero requieren un trabajo independiente.

Qué siguen viendo tu ISP, tu resolver y tu proveedor

Cuatro observadores no se ven afectados por nada de esto.

• Tu ISP ve una conexión TLS a la dirección IP de tu instancia y ve el nombre de host en el campo SNI (indicación del nombre de servidor), que se envía en texto claro durante el handshake. No ve la consulta.
• Tu resolver DNS ve la búsqueda de ese nombre de host. Puedes observarla en el cliente con sudo tcpdump -ni any port 53 mientras cargas la página; aparecerá la solicitud del registro A de tu instancia.
• Tu proveedor de VPS administra el hardware, por lo que puede leer el disco y la memoria de la máquina virtual. El cifrado del disco dentro de una VM alquilada no evita esto, porque el sistema en ejecución conserva la clave.
• Cualquiera que tenga root en la instancia lo ve todo. Eso te incluye a ti y también a quien consiga acceso más adelante.

Acceder a la instancia como servicio onion de Tor elimina los dos primeros puntos, porque no hay un nombre de host público que resolver ni un campo SNI que leer. La guía para añadir un servicio onion v3 a un VPS explica la configuración y las fugas que, de otro modo, podrían relacionar esa dirección con la IP pública de tu servidor.

Hay otro aspecto que suele olvidarse. Las solicitudes salientes de tu servidor son visibles desde la propia red del servidor, por lo que tu proveedor puede ver que tu máquina se comunica con Google y Bing durante todo el día. Eso es un patrón de tráfico, no una consulta, pero también proporciona información.

Aquí aparece la cuestión de la VPN. Una VPN (red privada virtual) traslada lo que ve tu ISP a lo que ve la empresa de VPN. No cambia nada para el operador de la instancia ni para los motores, porque los motores se comunican con tu servidor, no contigo. Ambos casos se comparan correctamente en el análisis comparativo entre un VPS y una VPN.

Por qué SearXNG te bloquea y qué significa realmente un 429

Hay dos eventos distintos que suelen describirse como «SearXNG me bloqueó». Cada uno requiere una solución diferente.

El primero es que tu propio limitador te responde con HTTP 429. Esta es la protección contra bots de SearXNG y está desactivada de forma predeterminada:

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

Desde agosto de 2026, el limitador necesita una base de datos Valkey y lee sus reglas de /etc/searxng/limiter.toml. Configura también server.public_instance: true si realmente hay personas ajenas que usan el servidor, porque de forma predeterminada es false y controla el comportamiento destinado al uso público.

El limitador ejecuta varias comprobaciones. http_user_agent considera un bot un User-Agent no definido o uno que coincide con herramientas conocidas como curl y wget. http_accept considera un bot una petición cuyo encabezado Accept no contiene text/html. link_token marca un cliente como sospechoso cuando nunca solicita la URL /client<token>.css que carga un navegador real. Cuando se activa una comprobación, SearXNG devuelve 429 y escribe una línea ERROR en su registrador botdetection.

Por tanto, esto falla, y es el comportamiento esperado:

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

curl envía User-Agent: curl/8.5.0 y Accept: */*, por lo que se activan dos comprobaciones a la vez. Por eso los scripts y los agentes de IA reciben un 429 de una instancia que funciona correctamente en un navegador. Esto es lo primero que debes corregir antes de configurar la capacidad de búsqueda de un agente para que use tu propia instancia. La lista completa de causas y ajustes está en la guía sobre los límites de tasa de SearXNG y los errores 429.

Hay un problema del limitador que conviene identificar. Detrás de un reverse proxy, SearXNG ve la dirección del proxy en lugar de la dirección del visitante, a menos que se confíe explícitamente en ese proxy:

[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 lista predeterminada incluye un proxy situado en el mismo host. Un proxy en una red Docker independiente llega desde una dirección como 172.18.0.5, que no está en la lista. Por tanto, todos los visitantes se cuentan como un único cliente y el primer usuario con mucha actividad bloquea a los demás. Añade esa subred a trusted_proxies.

El segundo tipo de bloqueo ocurre en el upstream. Un motor determina que una dirección de datacenter que ejecuta muchas búsquedas es un scraper y deja de responder a tu servidor. En ese caso no recibes un 429. Recibes una página de resultados en la que faltan los resultados de ese motor y se registra un fallo asociado a él. Después de varios fallos, SearXNG suspende temporalmente el motor. La causa es la dirección desde la que funciona tu VPS. Por tanto, la solución depende de elegir otros motores y esperar, no de modificar el limitador.

¿Compartir una instancia con desconocidos ayuda o perjudica?

Ambas cosas, en direcciones opuestas. Por eso la respuesta no es sencilla. El anonimato funciona como un efecto de multitud. En una instancia pública con mucha actividad, su consulta sale de la misma dirección que las consultas de miles de personas. Ningún motor puede aislarla del conjunto. En su instancia de un solo usuario, todas las consultas procedentes de esa dirección son suyas. Los motores reciben una secuencia limpia de consultas de una sola persona, pero sin un nombre asociado.

En el lado del operador ocurre lo contrario. Una multitud grande significa que un desconocido conserva las consultas en texto plano de toda la multitud, incluidas las suyas. En su propio servidor, usted conserva sus consultas y las de nadie más.

Por tanto, elija según la amenaza que realmente tenga. ¿Le preocupa la elaboración de perfiles publicitarios y el seguimiento entre sitios? La multitud ofrece una buena protección y el riesgo asociado al operador es reducido. ¿Le preocupa que una persona o empresa concreta pueda leer una búsqueda específica que realizó? La multitud no ayuda en absoluto, porque el operador ve el texto sin cifrar. Una opción intermedia adecuada es una instancia para un grupo reducido de personas conocidas. Obtiene una multitud pequeña y un operador que puede verificar, porque el operador es usted.

¿Los resultados de SearXNG son mejores que los de Google?

No. SearXNG no tiene un índice propio, por lo que todos los resultados de la página proceden de un motor ascendente, y el límite de calidad es el de los motores que haya habilitado. Si deshabilita Google y Bing, la calidad disminuye ese mismo día, porque la mayor parte de la cobertura web general procedía de ellos.

Lo que cambia es el procesamiento que se aplica a sus búsquedas. Ningún sistema crea un perfil publicitario a partir de la consulta ni reordena los resultados según lo que hizo clic la semana pasada. Esto tiene efectos en ambos sentidos, porque la personalización también aporta contexto local. Una búsqueda como "pharmacy open now" ofrece resultados menos precisos a través de SearXNG, ya que el motor no tiene ninguna señal de ubicación de su servidor aparte del centro de datos donde está alojado. Configure la región en las preferencias cuando necesite resultados locales.

Dos opciones determinan cuánto expone su instancia mientras consulta esos resultados. image_proxy es false de forma predeterminada, por lo que las miniaturas se cargan directamente desde los sitios que las alojan y esos sitios ven la dirección de su navegador. Si establece image_proxy: true, las miniaturas pasan por la instancia, a cambio de consumir más ancho de banda y memoria. Además, formats sólo se distribuye como html, por lo que una solicitud JSON (JavaScript object notation) se rechaza con 403 Forbidden:

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

Si habilita json en una instancia pública, habrá publicado una API gratuita para scraping. Es la forma más rápida de conseguir que los motores de los que depende bloqueen la dirección de su servidor. Manténgala deshabilitada o protéjala mediante autenticación.

Dónde termina la protección de la privacidad de SearXNG

SearXNG oculta de los motores de búsqueda quién realiza la consulta. No oculta de tu red lo que estás haciendo. De esto se derivan cuatro límites.

• Tu tráfico no cambia en ningún otro lugar aparte del cuadro de búsqueda. Todo lo demás que hace la máquina sale de tu red exactamente como antes.
• Un usuario en un servidor es un identificador estable para todos los motores. El identificador no incluye ningún nombre, y ese es todo el beneficio.
• El operador de cualquier instancia lee la consulta como texto sin cifrar. Ser tú mismo el operador es la única versión que puedes verificar.
• Tus propios registros de acceso reconstruyen el historial que intentabas evitar. Léelos y cambia a method: "POST" si prefieres que permanezcan vacíos.

SearXNG cambia de lugar al observador. No elimina la observación. Decide qué observador te preocupa, elige la instancia que corresponda y no consideres un frontend de búsqueda como software de anonimato.

FAQ

¿Es seguro usar SearXNG en una instancia pública?

Es seguro frente a los motores de búsqueda, pero no frente al operador. La consulta llega a ese servidor como texto sin cifrar, y la documentación del proyecto indica que los usuarios «tienen que confiar en el administrador de esa instancia» y no pueden saber «si sus solicitudes se registran, agregan y envían o venden a terceros». Con el valor predeterminado incluido de method: "GET", la consulta también queda en el registro de acceso del reverse proxy como parte de la línea de solicitud, tanto si el operador quería registrarla como si no. Use una instancia pública para búsquedas ordinarias cuando le preocupe la elaboración de perfiles publicitarios. No escriba en ella nada que no entregaría a su propietario.

¿SearXNG oculta mis búsquedas a mi proveedor de Internet?

El texto de la consulta queda oculto. La actividad, no. Su proveedor ve una conexión TLS con la dirección de su instancia y el nombre de host en el campo SNI de texto sin cifrar del handshake, y su resolvedor DNS ve la consulta de ese nombre de host. Ninguno ve qué ha buscado, porque la conexión está cifrada. SearXNG no es una VPN y no protege ninguna otra actividad de su equipo.

¿Por qué SearXNG devuelve un error 429?

El error 429 procede del limitador de la propia instancia. Es una protección contra bots, no un mensaje de Google. Sus comprobaciones marcan una solicitud cuyo encabezado Accept carece de text/html y un User-Agent que no está definido o coincide con herramientas como curl y wget. Una tercera comprobación, el token de enlace, marca un cliente que nunca solicita la URL /client<token>.css que carga un navegador. Si el reverse proxy no está incluido en trusted_proxies dentro de /etc/searxng/limiter.toml, todos los visitantes se cuentan como un solo cliente. Por tanto, un usuario con mucha actividad bloquea a los demás. Cuando un motor ascendente bloquea directamente su servidor, los resultados de ese motor simplemente desaparecen de la página y no recibe ningún error 429.

¿El alojamiento propio de SearXNG empeora los resultados de búsqueda?

A veces, por dos motivos importantes. Los resultados proceden de motores ascendentes, por lo que una dirección de centro de datos que los motores limitan implica que responden menos motores y que la página contiene menos resultados. Además, se elimina la clasificación personalizada. Esto evita la reordenación basada en anuncios, pero también elimina la intención local. Por ello, las búsquedas sensibles a la ubicación ofrecen respuestas menos relevantes hasta que configure su región en las preferencias.