Fatal de memoria recurrente en Joomla (antiguo.feadulta.com) — Registry.php, disparado por bots #168
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Sintoma
/php_errors.logregistra un PHP Fatal recurrente enantiguo.feadulta.com(Joomla legacy post-cutover), 15-47 veces/dia:Investigacion (agente Opus, 2026-07-08)
/errors/*.bz2), el mismo error ya ocurria 15-47 veces/dia desde primeros de junio (ej. 30-jun: 47, 6-jul: 46). El 8-jul (dia delmva/web/antiguo/) tuvo 17, por debajo de la media.errors.logesta saturado de bloqueos ModSecurity "DDoS Attack (discovery)" desde rangos de IP de Cloudflare. El patron de horas (pares separados ~20s, luego huecos irregulares) es tipico de bot, no de proceso periodico.caching='0'enconfiguration.php). Cada request bots incluida reconstruia toda la pagina desde cero, aumentando la presion de memoria en el binding recursivo deRegistry.php:814(bindData(), recursion sobre arrays/objetos anidados al cargar config/params). Codigo Joomla core (vendor), no custom de feadulta.Acciones
caching='0'->'1', conservative caching,cache_handler=fileya estaba OK). Backup delconfiguration.phporiginal en/entrada/configuration.php.bak-20260708-precachingen el servidor. Verificado: sitio responde 200 con contenido real tras el cambio, cache generando ficheros en/web/antiguo/cache/*(mod_menu, com_k2_extended, com_content, etc.), sin errores nuevos en el log tras el cambio. Esto reduce la frecuencia pero no elimina la causa raiz (no arregla la recursion en si).antiguo.feadulta.comes un sitio en retirada (solo sirve de fallback tras el cutover a WordPress) y no tiene por que estar expuesto a rastreo agresivo. Pedimos a Inma que revise en el dashboard de Cloudflare:antiguo.feadulta.com(challenge o bloqueo a bots no verificados).robots.txtconDisallow: /paraantiguo.feadulta.com(evita que crawlers "legitimos" tipo Googlebot sigan indexando el legacy).Nota
Si se quiere localizar la URL exacta que dispara el fatal (para bloquearla puntualmente en vez de bots en general), haria falta el access log de
antiguo.feadulta.com(no accesible desde la jaula SSH, pedir a cdmon) o analytics de Cloudflare en los timestamps de los fatales.Punto 2 (reducir exposición del legacy a bots vía Cloudflare) — HECHO y verificado
Tope del plan free: Cloudflare solo permite 5 custom rules y ya estaban las 5, así que no pudimos crear una regla nueva. Lo resolvimos editando una existente.
Hallazgo: la regla "Permitir bing" (Skip) en realidad permite muchos rastreadores en TODAS partes, incluido
antiguo:bing, Google, duck, yahoo, ecosia, archive, Slurp, ahrefs, semrush, Collaborator, openai(+ rutaswp-cron.php/admin-ajax.php). Por el orden de reglas (Skip corta la cadena antes de llegar a "bloquear bots 1/2"), esos crawlers estaban entrando al Joomla viejo sin freno → era una fuente clara del fatal del #168.Cambio aplicado: a esa regla le añadimos al final
and (not http.host eq "antiguo.feadulta.com")(envolviendo el OR original entre paréntesis). Así, enantiguoesos rastreadores ya no se permiten → caen en "bloquear bots 1" (cf.client.bot) y se bloquean. Enwwwtodo sigue igual (SEO intacto).Verificado desde fuera:
antiguo.feadulta.com/es/www.feadulta.com/…Complementa tu activación de la caché de Joomla. Los grandes buscadores dejan de rastrear el archivo.
Notas / cabos:
cf.client.bot) podría colarse aún; si quieres rematarlo, unrobots.txtconDisallow: /o cabeceranoindexsolo enantiguo(lado servidor) lo cerraría del todo — pero con esto la presión ya baja mucho.Por nuestra parte, cerrado. 🎯