¿Es seguro SearXNG? Qué oculta realmente

¿Es seguro SearXNG? Respuesta breve

SearXNG es seguro en un sentido y no lo es en el otro. Por eso, la pregunta «¿es seguro SearXNG?» sólo tiene respuesta cuando se especifica de quién se intenta ocultar la actividad. SearXNG es un metabuscador: toma la consulta, la envía a Google, Bing, DuckDuckGo y los demás motores que haya habilitado, y 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, esa persona recibe todas las consultas que escribe, en texto sin cifrar, y nada de lo que figure 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 intercambio constituye toda la protección de privacidad, y su valor depende por completo del servidor donde se ejecuta.

Nada de esto oculta sus búsquedas a 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 este 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, todo asociado 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 enviadas a los servicios de búsqueda» y «generar un perfil de navegador aleatorio para cada solicitud». Las 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.

Dos cabeceras de respuesta se envían de forma predeterminada y 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 envió, porque el navegador omite la cabecera Referer. X-Robots-Tag: noindex, nofollow impide que los motores de búsqueda indexen su instancia y sus páginas de resultados.

Lo que SearXNG no cambia es la consulta. La consulta llega completa y legible a la instancia, porque allí termina TLS (seguridad de la capa de transporte). Todos los puntos siguientes se derivan de ese hecho.

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

La 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 ausencia de registros en una página de inicio sigue siendo sólo una afirmación. Desde el exterior no hay forma de comprobarla. Sólo queda confiar o no usarla.

El registro también es la opción que requiere menos esfuerzo, porque el valor predeterminado distribuido incluye 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, por lo que deja de aparecer en el registro de acceso y en el historial del navegador. La documentación reconoce que POST tiene desventajas que «restringen gravemente 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 usted toma de forma intencionada.

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 su propio VPS, los motores ven el servidor en lugar de verlo a usted

Ejecute su propia instancia en un VPS (servidor privado virtual). El cambio es sencillo: Google ya no recibe la dirección IP de su domicilio junto con la consulta. Recibe la dirección IP de su servidor. No puede asociar esa búsqueda con su cuenta iniciada, su teléfono ni el perfil publicitario vinculado a la conexión de su hogar. La configuración se explica en la guía para ejecutar su propia instancia de SearXNG en un VPS.

Tenga claro qué no ha cambiado. Los motores siguen viendo el texto de la consulta, la hora, el idioma y la región que solicitó, además del patrón de todo lo que busca durante meses, agrupado bajo una única dirección estable. Si es el único usuario, esa dirección forma un flujo individual sin su nombre. Para evitar 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.

Lo que siguen viendo tu ISP, tu resolver y tu proveedor de hosting

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 del servidor), que se envía en texto claro durante el handshake. No ve la consulta.
• Tu resolver DNS ve la consulta para ese nombre de host. Obsérvala 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 elimina este riesgo, porque el sistema en ejecución contiene 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.

Hay otro observador 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. Esto es un patrón de tráfico, no una consulta, pero sigue revelando 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 respecto al operador de la instancia ni respecto a los motores, porque los motores se comunican con tu servidor y no contigo. Ambos se comparan correctamente en el análisis de un VPS frente a una VPN.

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

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

El primero es tu propio limitador, que 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. Define también server.public_instance: true si realmente hay usuarios externos que utilizan el servidor, porque su valor predeterminado es false y controla el comportamiento destinado al uso público.

El limitador ejecuta varias comprobaciones. http_user_agent considera un bot una solicitud con el User-Agent sin definir o con un valor que coincide con herramientas conocidas, como curl y wget. http_accept considera un bot una solicitud cuyo encabezado Accept no contiene text/html. link_token marca como sospechoso a un cliente que 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, como debe ser:

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. Es lo primero que debe corregir antes de apuntar la capacidad de búsqueda de un agente a su propia instancia. La lista completa de causas y ajustes está en la guía sobre los límites de tasa y los errores 429 de SearXNG.

Hay una trampa del limitador que conviene destacar. Detrás de un reverse proxy, SearXNG ve la dirección del proxy en lugar de la dirección del visitante, a menos que confíe 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 en el mismo host. Un proxy en una red Docker independiente llega desde una dirección como 172.18.0.5, que no está incluida en la lista. Por tanto, todos los visitantes se cuentan como un único cliente y el primer usuario con mucha actividad bloquea a todos los demás. Añada esa subred a trusted_proxies.

El segundo tipo de bloqueo ocurre en un motor externo. Un motor determina que una dirección de un centro de datos que ejecuta muchas búsquedas es un scraper y deja de responder a su servidor. En este caso no recibe un 429. Recibe una página de resultados a la que le faltan los resultados de ese motor y que indica un fallo asociado a él. Tras varios fallos, SearXNG suspende temporalmente el motor. La causa es la dirección en la que está alojado su VPS, por lo que la solución consiste en elegir otros motores y esperar, no en modificar el limitador.

¿Compartir una instancia con desconocidos ayuda o perjudica?

Ambas cosas, en direcciones opuestas. Por eso la respuesta parece difícil de precisar. El anonimato es un efecto de la multitud. En una instancia pública con mucha actividad, sus consultas salen de la misma dirección que las consultas de miles de personas. Ningún motor puede distinguir las suyas del conjunto. En su instancia de un solo usuario, todas las consultas de esa dirección son suyas. Los motores reciben un flujo limpio de una sola persona, 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 equipo, usted conserva sus consultas y las de nadie más.

Por tanto, elija según la amenaza real a la que se enfrente. ¿Le preocupan la creación de perfiles publicitarios y el seguimiento entre sitios? La multitud lo protege bien y el riesgo del operador es pequeño. ¿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 procesar. Una opción intermedia es usar una instancia para un grupo pequeño de personas conocidas. Obtiene una multitud reducida 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 cada resultado de la página procede de un motor externo. El límite de calidad lo marcan los motores que haya habilitado. Si deshabilita Google y Bing, la calidad baja ese mismo día porque la mayor parte de la cobertura general de la web procedía de ellos.

Lo que cambia es el procesamiento aplicado a sus búsquedas. Ningún servicio crea un perfil publicitario a partir de la consulta ni reordena los resultados según lo que hizo clic la semana pasada. Esto tiene ventajas y desventajas, 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 dispone de una señal de ubicación para su servidor más allá 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 costa de un mayor consumo de ancho de banda y memoria. Además, formats sólo se proporciona 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. Esta 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égela con autenticación.

Hasta dónde llega la privacidad de SearXNG

SearXNG oculta de los motores de búsqueda quién realiza la consulta. No oculta de la red lo que usted hace. De ahí se derivan cuatro límites.

• Su tráfico no cambia en ningún otro lugar aparte del cuadro de búsqueda. Todo lo demás que hace el equipo sale de la red exactamente como antes.
• Un usuario en un servidor es un identificador estable para todos los motores. El identificador no contiene ningún nombre, y ese es todo el beneficio.
• El operador de cualquier instancia lee la consulta en texto plano. Ser usted mismo el operador es la única variante que puede verificar.
• Sus propios registros de acceso reconstruyen el registro que intentaba evitar. Léalos y cambie a method: "POST" si prefiere que permanezcan vacíos.

SearXNG desplaza al observador. No elimina la observación. Decida qué observador le preocupa, elija la instancia que corresponda y no trate una interfaz 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 distribuido 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 el perfilado publicitario. 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 a la dirección de su instancia y el nombre de host en el campo SNI de texto sin cifrar del handshake. Además, su resolvedor DNS ve la consulta de ese nombre de host. Ninguno ve lo que buscó, 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 código 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, así como un User-Agent no definido o que 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. Detrás de un reverse proxy que no aparece en trusted_proxies dentro de /etc/searxng/limiter.toml, todos los visitantes se cuentan como un solo cliente. Por eso, un usuario con mucha actividad bloquea al resto. Si un motor upstream bloquea el servidor en su lugar, los resultados de ese motor simplemente desaparecen de la página y no recibe ningún error 429.

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

A veces, por dos motivos importantes. Los resultados proceden de motores upstream. Si esos motores limitan una dirección de datacenter, responden menos motores y la página ofrece menos resultados. Además, se elimina la clasificación personalizada. Esto evita el reordenamiento basado en publicidad, pero también elimina la intención local. Por eso, las búsquedas sensibles a la ubicación devuelven respuestas menos precisas hasta que configure su región en las preferencias.