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 insiste indefinidamente con un motor que rechaza sus solicitudes. Un motor que falla queda suspendido y, mientras está suspendido, se omite por completo. Así es como un motor averiado se convierte en un motor que desaparece sin avisar.

Hay dos capas que controlan este comportamiento. Ambas se encuentran en search: dentro de settings.yml. Confirme estos nombres de clave en la documentación de configuración de la versión que realmente ejecuta antes de pegar nada, porque han cambiado entre versiones. Según la documentación disponible el 2 de septiembre de 2026, los valores predeterminados son:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400
    SearxEngineTooManyRequests: 3600
    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 pocos minutos después de que desaparezca 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 como un error genérico, aplica la entrada correspondiente de suspended_times. Esos valores son mucho mayores. 86400 segundos equivalen a un día completo. 604800 equivalen a una semana. 1296000 equivalen a quince días. Las claves con el prefijo cf_ se aplican cuando el desafío se identifica como un desafío de Cloudflare. recaptcha_ se aplica 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 horas. El motor continúa suspendido. La suspensión se mantiene en el proceso en ejecución. Por eso, al reiniciar el contenedor se borra y la siguiente búsqueda vuelve a intentar utilizar el motor. En este caso basta con reiniciarlo. Conviene saber cuándo basta con reiniciar y cuándo hay que volver a crear el contenedor antes de reconstruir imágenes sin necesidad. Si el motor vuelve a fallar inmediatamente después del reinicio, la corrección no funcionó.

Hay una configuración por motor que requiere precaución. 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 realmente intermitente.

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

Comprobada el 2 de septiembre de 2026, la documentación de administración de SearXNG resuelve este problema mediante 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 conexión en silencio, por lo que un túnel correcto no muestra nada ni termina. Compruébelo desde una segunda terminal:

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

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

Ahora, la limitación real. Cuatro factores limitan este método. La cookie que entrega el motor se guarda 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 asociado a la propia dirección. Ese registro caduca según un plazo que decide el motor y que no publica. El procedimiento no automatiza ninguna parte, por lo que tendrá que volver al teclado la próxima vez. Además, en una instancia que utilizan otras personas, el volumen de consultas que activó el desafío continúa, por lo que el desafío vuelve a aparecer.

Úselo para poner una instancia en funcionamiento 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, lo que cambia la dirección que ve el motor. Configúrelo globalmente en outgoing: o por motor cuando sólo uno de ellos presente el problema.

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  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:// frente a socks5:// cuando quiera que el proxy resuelva el nombre de host, porque h indica que el nombre se envía al proxy en lugar de resolverse en el servidor. Aumente también el tiempo de espera. request_timeout tiene un valor predeterminado de 2.0 segundos; un proxy añade un viaje de ida y vuelta a cada solicitud, y los motores que antes respondían a tiempo empiezan a fallar por superar el tiempo de espera. extra_proxy_timeout existe precisamente para esto y añade segundos cuando se usa un proxy.

Costes de usar 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 estructura y los tiempos de su tráfico.
• Una dirección de salida compartida se comparte con todos los demás usuarios que pagan por ella. Si realizan scraping, heredará su reputación, a veces más rápido que el bloqueo que intentaba evitar.
• Las redes económicas de proxies residenciales suelen construirse con 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 íntegramente, y un motor que desafía a los rangos de centros de datos suele desafiar a los nodos de salida con la misma intensidad o más.
• Las búsquedas pasan a depender de un servicio externo al servidor, que 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 el motivo para alojar su propia instancia es mantener una política de privacidad sencilla, compárela con lo que realmente oculta una instancia autogestionada y lo que no antes de contratar ningún servicio.

Solución duradera: ejecute deliberadamente un conjunto más pequeño de motores

La opción que más personas pasan por alto 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 una de veinte en la que la mitad queda suspendida durante todo un día. Supervise /stats durante una semana y conserve los motores que mantengan un historial estable desde su dirección.

Los motores a los que se accede con una clave de API se comportan 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 decidirlo. Un motor suspendido no es visible 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 un error que la herramienta pueda detectar. Si algún proceso automatizado depende de su instancia, consulte /stats/errors periódicamente 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. Estos valores predeterminados van de una hora 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 intentar usar el motor. Si el motor vuelve a fallar justo después del reinicio, la corrección no funcionó.

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

Se producen en direcciones opuestas. Un 429 que la instancia devuelve al navegador significa que el limitador propio de SearXNG ha determinado que la solicitud parecía automatizada. Este límite se puede configurar. Un error de CAPTCHA o de bloqueo significa que un motor externo está rechazando el servidor. La decisión se toma en una infraestructura que 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 solucionará los CAPTCHAs de los motores?

A veces, pero tiene un coste. Encaminar las solicitudes salientes mediante outgoing.proxies cambia la dirección que ve el motor y puede eliminar un bloqueo asociado al rango de direcciones del 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, a menos que aumente 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 la intervención manual en el desafío. Cualquier solución que cree para responder automáticamente a los desafíos incumplirá la política declarada del motor y dejará de funcionar silenciosamente cada vez que cambie el desafío. Eso le obligará a 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.