Cómo alojar Whoogle por cuenta propia en 2026: privacidad, límites de solicitudes y configuración del proxy

Un contenedor de Whoogle puede aparecer en verde aunque la tarea que les importa a los usuarios esté fallando. En Whoogle, ese fallo oculto suele deberse a que el upstream bloquea la IP o a que las variables de entorno del proxy son incorrectas. Esta guía considera como prueba de aceptación «enviar búsquedas con la configuración normal y de privacidad, verificar los enlaces de resultados, probar un proxy upstream y activar el límite de solicitudes elegido» y construye el despliegue de atrás hacia delante a partir de ese resultado.

Whoogle cumple una función específica en el stack: ofrecer resultados de búsqueda de Google sin anuncios, tracking ni JavaScript del cliente. Por tanto, la cuestión en producción no es si el puerto 5000 responde una vez, sino si el estado, las dependencias y la dirección pública siguen siendo coherentes después de un reinicio, una actualización y una restauración.

Define primero qué significa que Whoogle funcione correctamente

Un diagrama útil de Whoogle muestra la ruta pública, el puerto privado 5000, el límite del estado y todos los requisitos de soporte. Indica qué flechas transportan credenciales y cuáles corresponden al tráfico normal de los usuarios. El requisito externo de Whoogle es disponer de acceso HTTPS saliente y de una IP de servidor estable que los proveedores de búsqueda acepten. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio entrante.

Valida el diagrama con una acción real: envía búsquedas con la configuración normal y de privacidad, verifica los enlaces de resultados, prueba un proxy upstream y activa el límite de solicitudes elegido. La presión probablemente provendrá del bloqueo de las búsquedas upstream, la reputación de la IP del servidor, las consultas simultáneas y la latencia del proxy; monitoriza esa ruta en lugar de tratar todas las solicitudes HTTP como equivalentes.

Configura la ruta de Whoogle sin falsear el uso de HTTPS

Evita definir orígenes públicos temporales y permanentes para Whoogle. En su lugar, publica la interfaz de búsqueda mediante HTTPS con límites de solicitudes medidos, apunta el nombre DNS elegido a la ruta de la plataforma y usa el proxy únicamente hacia el puerto 5000.

Ejecuta esta acción desde fuera del host: envía búsquedas con la configuración normal y de privacidad, verifica los enlaces de resultados, prueba un proxy upstream y activa el límite de solicitudes elegido. Si falla el ingress, la guía de resolución de problemas de 502 cubre los errores relacionados con el puerto y el listener. Si Whoogle recibe la solicitud, pero el upstream bloquea la IP o las variables de entorno del proxy son incorrectas, las evidencias ya apuntan más allá del proxy.

Haz reproducible el arranque de Whoogle

El primer contenedor debe ser fácil de eliminar y recrear. Mantén los datos fuera de la capa escribible, vincula el puerto 5000 solo donde el proxy pueda acceder a él y pasa la configuración en tiempo de ejecución.

docker run -d \
  --name whoogle \
  --restart unless-stopped \
  -p 127.0.0.1:5000:5000 \
  -v whoogle-data:/config \
  -e WHOOGLE_CONFIG_PASSWORD=replace-with-a-long-random-value \
  benbusby/whoogle-search:latest

Fija la imagen después de la prueba inicial. Lee el primer error de arranque en lugar del mensaje final de reinicio, verifica cada montaje con docker inspect y sigue los logs mientras envías búsquedas con la configuración normal y de privacidad, verificas los enlaces de resultados, pruebas un proxy upstream y activas el límite de solicitudes elegido. Esta secuencia distingue un comando de imagen incorrecto de un problema de dependencias o permisos.

Logs que responden a la siguiente pregunta

En Whoogle, monitoriza una transacción en lugar de un proceso: envía búsquedas con la configuración normal y de privacidad, verifica los enlaces de resultados, prueba un proxy upstream y activa el límite de solicitudes elegido. Combina su latencia y tasa de errores con el bloqueo de las búsquedas upstream, la reputación de la IP del servidor, las consultas simultáneas y la latencia del proxy para que una alerta identifique el componente limitado.

El ensayo de actualización debe contemplar que los cambios en el marcado upstream y las nuevas versiones de Whoogle pueden romper el parsing sin que el contenedor deje de estar saludable. Restaura, migra y ejecuta la transacción antes de sustituir la versión en producción. Si el upstream bloquea la IP o las variables de entorno del proxy son incorrectas, no borres los datos para que el arranque aparezca en verde; compara la versión, las variables, los montajes y la accesibilidad de las dependencias, en ese orden.

Convierte la prueba de humo de Whoogle en una comprobación de release

Crea una fixture pequeña y desechable de Whoogle y consérvala para cada release. La fixture debe ejecutar el flujo de trabajo real: enviar búsquedas con la configuración normal y de privacidad, verificar los enlaces de resultados, probar un proxy upstream y activar el límite de solicitudes elegido. Registra el digest de la imagen, el hostname externo, la dirección de la dependencia y el resultado esperado para que otro operador pueda repetir la prueba más adelante sin tener que interpretar esta guía.

Ejecuta la fixture tres veces. Primero, usa el despliegue nuevo. Después, sustituye el contenedor sin tocar el estado persistente. Por último, restaura la copia de seguridad en un entorno vacío. La tercera ejecución solo se supera cuando se recuperan la configuración y las preferencias, y un conjunto fijo de consultas sigue produciendo enlaces de resultados utilizables. Durante cada ejecución, captura la latencia y el uso de recursos en torno al bloqueo de las búsquedas upstream, la reputación de la IP del servidor, las consultas simultáneas y la latencia del proxy; esto se convierte en la línea base de las alertas, en lugar de un porcentaje de CPU arbitrario.

Por último, prueba deliberadamente la ruta negativa: deniega temporalmente la ruta de prueba utilizada por el acceso HTTPS saliente y una IP de servidor estable que los proveedores de búsqueda acepten. Confirma que Whoogle falla de forma visible sin corromper el estado, restaura la condición correcta y repite la transacción correcta. Un registro de release que contenga esos cuatro resultados ofrece evidencias más sólidas que las capturas de un dashboard o una respuesta puntual de curl.

Encuentra cada byte persistente de Whoogle

Haz inventario de todos los artefactos persistentes: la configuración y las preferencias de usuario que se almacenen en disco. Monta /config antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Incluye la configuración que modifica la forma de interpretar los datos almacenados, no solo el directorio más grande.

Define la retención, copia las copias de seguridad fuera del host y ejecuta una restauración en un entorno limpio. El ejercicio de Whoogle se completa cuando se recuperan la configuración y las preferencias, y un conjunto fijo de consultas sigue produciendo enlaces de resultados utilizables. Si las snapshots forman parte del plan, utiliza la guía sobre PITR frente a snapshots para documentar qué puede recuperar cada mecanismo.

Protege la parte valiosa de Whoogle

Un despliegue seguro de Whoogle comienza eliminando privilegios. Evita ejecutar un proxy público abierto sin controles contra el abuso; en su lugar, protege cualquier instancia pública con autenticación o controles de tasa y mantén las credenciales del proxy fuera de la imagen.

Sustituye inmediatamente el valor de ejemplo de WHOOGLE_CONFIG_PASSWORD, almacénalo fuera de la imagen y rótalo como una credencial de administrador si queda expuesto. Restringe las rutas administrativas, utiliza DNS privado para las dependencias y revisa cada montaje. Cuando los logs se envíen de forma centralizada, filtra los secretos y el contenido privado antes de que abandonen el servidor.

Qué debería automatizar Dockup para Whoogle

Dockup elimina el trabajo manual relacionado con el reverse proxy y el ciclo de vida de Whoogle. El servicio recibe una ruta HTTPS estable hacia el puerto 5000, la configuración inyectada y almacenamiento persistente durante las sustituciones. Un servidor del cliente conectado sigue el mismo modelo que la infraestructura de cómputo alojada en Dockup.

Después del lanzamiento, cumple el contrato de la aplicación: publica la interfaz de búsqueda mediante HTTPS con límites de solicitudes medidos, permite y verifica el acceso HTTPS saliente y una IP de servidor estable que los proveedores de búsqueda acepten, y ejecuta esta prueba: envía búsquedas con la configuración normal y de privacidad, verifica los enlaces de resultados, prueba un proxy upstream y activa el límite de solicitudes elegido. Así, la experiencia de un clic sigue siendo útil sin ocultar los detalles que hacen que Whoogle sea recuperable y seguro.

Preguntas frecuentes

¿Qué necesita Whoogle para un despliegue en producción?

Enruta el contenedor de Whoogle en el puerto 5000 a través de un único origen HTTPS. El requisito de entrega externo es disponer de acceso HTTPS saliente y de una IP de servidor estable que los proveedores de búsqueda acepten. No consideres que Whoogle está listo hasta que puedas enviar búsquedas con la configuración normal y de privacidad, verificar los enlaces de resultados, probar un proxy upstream y activar el límite de solicitudes elegido.

¿Qué datos de Whoogle deben incluirse en una copia de seguridad?

Persiste /config e incluye la configuración y las preferencias de usuario que se almacenen en disco en el mismo manifiesto de recuperación. Una restauración limpia de Whoogle solo se supera cuando se recuperan la configuración y las preferencias, y un conjunto fijo de consultas sigue produciendo enlaces de resultados utilizables.

¿Whoogle necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Whoogle y mantén el puerto 5000 en la ruta interna. Aplica correctamente la configuración de Whoogle: publica la interfaz de búsqueda mediante HTTPS con límites de solicitudes medidos. En Whoogle, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de Whoogle?

Restaura el estado actual de Whoogle en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, ya que los cambios en el marcado upstream y las nuevas versiones de Whoogle pueden romper el parsing sin que el contenedor deje de estar saludable. Conserva la imagen anterior de Whoogle hasta comprender los límites de migración de datos y rollback.