Cómo corregir errores CAPTCHA de SearXNG

Qué significa un error CAPTCHA de SearXNG

Los errores CAPTCHA de SearXNG proceden de los motores que consulta la instancia. El servidor solicitó resultados a un motor, el motor respondió con una página de desafío en lugar de resultados y SearXNG registró un error para ese motor porque no había contenido que analizar en la respuesta. La instancia funciona correctamente. Una máquina que usted no controla decidió que la solicitud no parecía proceder de una persona.

Este hecho determina todas las soluciones que se describen a continuación. La decisión se tomó en el hardware del propio motor, por lo que nada en su settings.yml puede anularla. Puede cambiar la dirección desde la que sale la solicitud, los motores que consulta y el comportamiento de la instancia cuando un motor empieza a rechazar solicitudes.

Dos fallos que parecen iguales y cómo diferenciarlos

El primer fallo se produce cuando su propia instancia responde HTTP 429 (demasiadas solicitudes) al navegador. Es el limitador de SearXNG, la capa de detección de bots situada delante del endpoint de búsqueda. Se ejecuta en su servidor y puede configurarlo usted. el limitador que devuelve 429 a sus propios usuarios es un problema distinto, con una configuración diferente, y ninguna de las indicaciones siguientes se aplica a ese caso.

El segundo fallo se produce en el upstream. La página de resultados carga con normalidad, pero faltan uno o más motores en los resultados o aparece un aviso de error. Su instancia no rechazó ninguna solicitud. Un motor rechazó a su servidor.

• Si la página no carga o el endpoint de búsqueda responde 429, revise el limitador.
• Si la página carga, pero los resultados son escasos o un motor aparece marcado con un error, revise el upstream y siga leyendo.

Ambos fallos pueden producirse en la misma instancia y pueden influirse entre sí, porque un limitador configurado con demasiada permisividad deja pasar tráfico que aumenta la tasa de consultas salientes. Diagnostíquelos por separado.

¿Por qué los motores de SearXNG devuelven errores de CAPTCHA en un VPS y no en mi portátil?

La causa es la dirección desde la que procede la solicitud. Tu conexión doméstica tiene una dirección de un rango de un ISP (proveedor de servicios de Internet) para consumidores, que se comparte con el tiempo entre muchas personas normales. Tu VPS tiene una dirección de un rango de un centro de datos, y esos rangos están publicados: cualquiera puede consultar qué direcciones pertenecen a un proveedor de hosting. Un motor que quiere impedir el acceso de los scrapers empieza por tratar como sospechosas las solicitudes procedentes de rangos de hosting, porque en esos rangos hay muy pocas solicitudes realizadas por una persona con un navegador.

La dirección no es el único factor. Tu instancia envía una solicitud por motor para cada búsqueda del usuario, de modo que incluso un número reducido de usuarios genera desde una sola dirección una tasa de solicitudes que ninguna persona genera por sí sola. SearXNG no mantiene una sesión con el motor ni envía una cookie de larga duración, por diseño, así que cada solicitud llega sin historial previo. Además, la dirección puede tener un historial que tú no creaste, porque los proveedores reutilizan las direcciones y el inquilino anterior pudo haber hecho scraping desde ella durante meses.

El rechazo no siempre aparece como un fallo evidente. Un motor puede responder con 403, con 429 o con HTTP 200 y una página de desafío en el cuerpo de la respuesta. Este último caso confunde, porque una comprobación del código de estado indica que el motor funciona mientras SearXNG obtiene cero resultados de la respuesta. Por eso debes leer el informe de errores de tu propia instancia en lugar de usar curl contra el motor y revisar la línea de estado.

Consulta lo que informa tu instancia antes de cambiar nada

Cada corrección siguiente empieza con el nombre del motor que falla y el motivo que la instancia registró para él. SearXNG muestra ambos datos. La página /stats enumera los motores con sus recuentos de errores y su fiabilidad. /stats/errors devuelve los detalles del error en formato JSON, que resulta más fácil de guardar y comparar la semana siguiente. Ábrelos en el navegador que uses normalmente para la instancia.

El registro del contenedor contiene los mismos eventos a medida que se producen. El nombre del servicio indicado aquí es el que se usa en el archivo compose publicado con la documentación del contenedor. Usa el tuyo si es diferente.

docker compose logs -f core

Ejecuta una búsqueda que falle mientras sigues el registro. Deberías ver una entrada del motor que falla cuando se ejecuta la búsqueda. Anota el nombre del motor y la cadena de motivo exacta que imprimió tu instancia. No copies el nombre de un motor de una publicación de blog, incluida esta. El conjunto de motores que bloquean direcciones de centros de datos cambia de un mes a otro. El motor que falla en tu caso puede funcionar perfectamente para quien escribió la publicación que estás leyendo.

Si la página de resultados no muestra ningún error, pero los resultados son escasos, comprueba display_error_messages para ese motor. Su valor predeterminado es true. Una instancia que lo haya desactivado oculta el único mensaje que necesitas.

Cómo SearXNG reintenta y suspende un motor que falla

SearXNG no sigue intentando acceder a un motor que rechaza las solicitudes. Un motor que falla queda suspendido y, mientras está suspendido, se omite por completo. Por eso, un motor averiado puede convertirse en un motor que desaparece sin ningún mensaje.

Hay dos capas que controlan este comportamiento. Ambas se encuentran en search: dentro de settings.yml. Confirme estos nombres y valores de clave en searx/settings.yml para la versión que realmente ejecuta antes de pegar nada. Han cambiado entre versiones y el ejemplo de la página de documentación de configuración todavía muestra suspensiones más largas que las del archivo que SearXNG carga realmente. En la versión distribuida en searx/settings.yml el 17 de octubre de 2026, los valores predeterminados son:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 180
    SearxEngineCaptcha: 3600
    SearxEngineTooManyRequests: 180
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

La primera capa gestiona los fallos normales, como un tiempo de espera agotado. La suspensión comienza en ban_time_on_fail segundos y aumenta con cada fallo consecutivo, hasta max_ban_time_on_fail. De forma predeterminada, el límite es de dos minutos. Por tanto, un motor inestable se recupera por sí solo en unos minutos después de que desaparece el problema.

La segunda capa gestiona los fallos tratados en esta guía. Cuando SearXNG identifica la respuesta como un desafío o un rechazo, en lugar de un error genérico, aplica la entrada correspondiente de suspended_times. La mayoría de esos valores son mucho mayores. 180 segundos son tres minutos para un rechazo simple o un 429. 3600 es una hora para un CAPTCHA genérico. 86400 es un día completo. 604800 es una semana. 1296000 son quince días. Las claves con el prefijo cf_ se aplican cuando el desafío se identifica como un desafío de Cloudflare. Las claves con recaptcha_ se aplican cuando se identifica como reCAPTCHA.

Esto explica el síntoma que más tiempo hace perder. Encuentra la causa, la corrige y el motor sigue sin devolver resultados durante una hora o durante varios días después de un desafío de Cloudflare. El motor todavía está suspendido. La suspensión se mantiene en el proceso en ejecución. Por eso, reiniciar el contenedor la elimina y la siguiente búsqueda vuelve a intentar acceder al motor. En este caso basta con reiniciar. Antes de empezar a reconstruir imágenes sin motivo, conviene saber cuándo basta con reiniciar y cuándo es necesario volver a crear el contenedor. Si el motor vuelve a fallar inmediatamente después del reinicio, la corrección no funcionó.

Hay que prestar atención a una configuración individual de cada motor. retry_on_http_error reintenta una solicitud cuando el motor responde con los códigos de estado que se indican. Si un motor está bloqueando el acceso, los reintentos envían más tráfico al sistema que ya ha determinado que el servidor es un bot. Déjelo sin cambios, salvo que esté solucionando un problema con un motor que realmente presenta fallos intermitentes.

Documentación del túnel SSH ascendente y lo que no corrige

Comprobada el 17 de octubre de 2026, la documentación de administración de SearXNG responde a este problema con un túnel manual. Abra un proxy SOCKS a través de su servidor, configure el navegador de escritorio para usarlo y responda el desafío manualmente mientras el motor ve la dirección del servidor.

ssh -q -N -D 8080 user@example.org

-D 8080 abre un servidor SOCKS local en el puerto 8080 que reenvía el tráfico a través de la conexión SSH. -N no ejecuta ningún comando remoto y -q mantiene la salida silenciosa, por lo que un túnel operativo no muestra nada y no termina. Compruébelo desde un segundo terminal:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

El primer comando debe mostrar la dirección de su servidor y el segundo, la dirección de su equipo. Si ambas respuestas son idénticas, la solicitud no está pasando por el túnel. Después, configure los ajustes de red del navegador para usar un proxy SOCKS5 en 127.0.0.1, en el puerto 8080. Cargue el mismo comprobador de direcciones en el navegador para confirmar que muestra el servidor y visite el motor que le está presentando el desafío. Responda allí al desafío.

Ahora, la parte importante. Cuatro factores limitan este método. La cookie que entrega el motor queda en el navegador de escritorio, y SearXNG no tiene acceso a las cookies del navegador. Por tanto, lo único que puede ayudar a su instancia es lo que el motor registre para esa dirección. Ese registro caduca según un plazo que el motor decide y no publica. El procedimiento no automatiza ninguna tarea, así que tendrá que volver al teclado la próxima vez. Además, en una instancia que utilizan otras personas, la tasa de consultas que activó el desafío sigue activa, por lo que el desafío volverá a aparecer.

Úselo para poner en funcionamiento una instancia esta tarde. No diseñe una instancia que dependa de este método.

Solución duradera: desactive o ajuste el peso de los motores que bloquean el servicio

La solución duradera más sencilla es dejar de consultar un motor que no puede atender a su servidor. Su settings.yml comienza con use_default_settings: true en la imagen del contenedor. Esto significa que una entrada en engines: con un name coincidente sólo sobrescribe las claves que especifique y conserva el resto de la definición predeterminada.

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

disabled: true desactiva el motor de forma predeterminada, pero lo mantiene en la página de preferencias. Así, un usuario que lo necesite puede volver a activarlo para sus propias búsquedas. inactive: true lo elimina por completo de la configuración del usuario. Esto es lo adecuado para un motor que nunca funcionará desde su dirección. weight realiza otra función: ajusta cuánto cuentan los resultados de ese motor cuando SearXNG los combina y ordena. Un peso inferior a 1 permite conservar un motor marginal sin dejar que ocupe los primeros resultados.

Reinicie el contenedor después de editar la configuración y ejecute varias búsquedas. Después, vuelva a comprobar /stats. Una página de estadísticas limpia, con seis motores operativos, es más útil que una página llena de errores con veinte.

Solución duradera: enviar las solicitudes salientes a través de un proxy

SearXNG puede enviar sus solicitudes salientes a los motores a través de un proxy. Esto cambia la dirección que ve el motor. Configúrelo globalmente en outgoing: o por motor cuando el problema afecte sólo a uno.

outgoing:
  request_timeout: 3.0
  extra_proxy_timeout: 10
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

Prefiera socks5h:// a socks5:// cuando quiera que el proxy resuelva el nombre de host, porque h hace que el nombre se envíe al proxy en lugar de resolverse en el servidor. Aumente también el tiempo de espera. request_timeout tiene un valor predeterminado de 3.0 segundos. Un proxy añade un viaje de ida y vuelta a cada solicitud, por lo que los motores que antes respondían a tiempo pueden empezar a fallar por tiempo de espera. extra_proxy_timeout existe precisamente para este caso y añade segundos cuando se utiliza un proxy. Escríbalo como un número entero, por ejemplo 10. A diferencia de request_timeout, que acepta decimales, extra_proxy_timeout es un entero en el esquema de configuración. Por eso se rechaza un valor como 10.0 como settings.yml no válido, aunque el ejemplo comentado de la página de documentación de la configuración de solicitudes salientes lo escriba de esa forma.

Costes de un proxy:

• El operador del proxy ve a qué motores consulta su instancia y cuándo. TLS (seguridad de la capa de transporte) mantiene los términos de búsqueda fuera de sus registros porque la consulta está dentro de la solicitud cifrada, pero puede leer la forma y la temporización de su tráfico.
• La dirección de salida compartida se comparte con todos los demás usuarios que pagan por ella. Si realizan scraping, usted hereda su reputación, a veces antes de superar el bloqueo que intentaba evitar.
• Las redes de proxies residenciales baratos suelen estar formadas por dispositivos de consumidores cuyos propietarios no aceptaron conscientemente transportar tráfico. Sepa qué está comprando.
• using_tor_proxy: true enruta el tráfico a través de Tor, pero las direcciones de los nodos de salida se publican por completo, y un motor que desafía rangos de centros de datos suele desafiar los nodos de salida al menos con la misma intensidad.
• Las búsquedas pasan a depender de un servicio externo al servidor. Ese servicio puede fallar según su propio calendario y llevarse consigo los resultados.

Un proxy desplaza el bloqueo en lugar de eliminarlo, y la privacidad de su instancia pasa a incluir a un tercero. Si una política de privacidad reducida es el motivo por el que aloja el servicio usted mismo, compare esa ventaja con lo que una instancia autoalojada oculta realmente y lo que no antes de contratar cualquier servicio.

Solución duradera: ejecutar intencionadamente un conjunto más pequeño de motores

La opción que más se suele ignorar es aceptar menos motores. El valor de SearXNG está en la combinación de resultados, y una combinación de seis motores que responden siempre es mejor que veinte de los que la mitad quedan suspendidos durante horas o días. Supervise /stats durante una semana y conserve los motores que mantengan un historial correcto desde su dirección.

Los motores con los que se autentica mediante una clave de API funcionan de otra forma, porque el motor sabe quién es usted y aplica una cuota en lugar de intentar determinar si es una persona. La contrapartida es una cuenta, una clave almacenada en el archivo de configuración y, normalmente, un coste. Para uno o dos motores que sean importantes para usted, suele ser la opción que causa menos problemas.

Tenga en cuenta el resto de sus herramientas al tomar esta decisión. Un motor suspendido no está disponible para nada que lea resultados mediante la API, porque la API JSON que consultan Open WebUI y herramientas similares simplemente devuelve menos resultados en lugar de generar un error que la herramienta pueda detectar. Si algo automatizado depende de su instancia, consulte /stats/errors con una periodicidad definida en lugar de esperar a que alguien se queje de que las respuestas han empeorado.

¿Merece la pena insistir?

Respóndalo contando usuarios. Una instancia para una sola persona envía unas pocas búsquedas al día desde una dirección, una frecuencia que muchos motores nunca cuestionan. Cuando uno sí lo hace, la solución es sencilla: quite ese motor y apenas notará que ha desaparecido. Esa es la experiencia habitual de ejecutar SearXNG para uso personal en un VPS pequeño, y no requiere ningún túnel ni proxy.

Una instancia pública o compartida es otra máquina que ejecuta el mismo software. La frecuencia de las consultas activa los desafíos y aumenta con cada usuario que añade, por lo que aparecen más rápido de lo que cualquier configuración puede compensar. Planifique desde el principio un conjunto de motores más reducido y recuerde que cualquier proxy que añada ahora transportará las búsquedas de otras personas usando su cuenta.

Los clientes automatizados se sitúan entre ambos casos, pero se acercan al más difícil. Un agente que ejecuta varias búsquedas para responder una pregunta genera ráfagas que ningún usuario humano produce, por lo que una instancia a la que conecte agentes de programación y herramientas de investigación encuentra desafíos antes que la misma instancia utilizada manualmente. Si ese es su caso, elija los motores por su fiabilidad y no por su amplitud, y permita que el agente trabaje con resultados que realmente pueda obtener.

La regla es la siguiente: insista con un motor cuando sea la razón por la que aloja el servicio por su cuenta, y elimínelo cuando no lo sea.

FAQ

¿Por qué un motor de SearXNG sigue sin devolver resultados después de corregir el problema?

Porque todavía está suspendido. Cuando SearXNG detecta un desafío o un rechazo de un motor, deja de consultarlo durante el periodo establecido en search.suspended_times. Los valores predeterminados incluidos van de tres minutos a quince días, según el tipo de rechazo. La suspensión se mantiene en el proceso en ejecución, por lo que reiniciar el contenedor la elimina y la siguiente búsqueda vuelve a probar el motor. Si el motor vuelve a fallar justo después del reinicio, la corrección no funcionó.

¿El error de CAPTCHA de un motor es lo mismo que el 429 que devuelve mi instancia?

Se producen en direcciones opuestas. Un 429 que su instancia devuelve al navegador es el limitador propio de SearXNG, que determina que la petición parece automatizada. Puede configurarlo. Un error de CAPTCHA o de bloqueo es un rechazo del motor externo a su servidor. Esa decisión se toma en una infraestructura que usted no controla. Si la página de resultados carga y sólo faltan algunos motores, se trata del segundo caso.

¿Una VPN o un proxy en mi servidor resolverán los CAPTCHA de los motores?

A veces, pero tienen un coste. Enrutar las peticiones salientes mediante outgoing.proxies cambia la dirección que ve el motor. Esto puede eliminar un bloqueo asociado al rango de su centro de datos. El operador del proxy podrá ver qué motores consulta y cuándo. Además, una dirección de salida compartida puede tener asociada la reputación de otros clientes. La latencia adicional también puede provocar tiempos de espera si no aumenta request_timeout y extra_proxy_timeout. Tor está disponible mediante using_tor_proxy, pero sus direcciones de salida son públicas y reciben desafíos con frecuencia.

¿Puedo hacer que SearXNG resuelva el CAPTCHA automáticamente?

No existe ninguna opción para hacerlo. El método que documenta el proyecto es manual: un túnel SSH SOCKS, su propio navegador y su intervención directa en el desafío. Cualquier solución que cree para responder automáticamente a los desafíos incumplirá la política declarada por el motor y dejará de funcionar silenciosamente cada vez que cambie el desafío. Entonces tendrá que mantener un scraper en lugar de ejecutar una instancia de búsqueda. La solución que sigue funcionando es eliminar los motores que bloquean su dirección.