Hace poco de repente dejaron de funcionar todos los pagos automáticos periódicos del servicio de mantenimiento web, con el consiguiente trastorno tanto para mi como para los clientes, pues tocó hacer procesos manuales que nunca gustan y te hacen perder tiempo, especialmente cuando era algo que dabas por hecho.
Tras muchos días de investigación resulta que todo el problema provenía del culpable más sorprendente: CloudFlare. Pero te cuento todo el proceso…
Pagos periódicos de suscripción que no se ejecutan
De repente, un día, en vez de generarse los nuevos pedidos por pagos periódicos de los servicios de mantenimiento, que gestiono con el plugin de suscripciones de Yith, los pedidos no se generaban, y en consecuencia no se cargaban los pagos y no se actualizaban las suscripciones al servicio.
Tras comprobar todos los posibles culpables habituales: plugins, el tema, WordPress, o alguna actualización de los anteriores y comprobar que no era ese el problema, hubo dos herramientas fundamentales que ayudaron a diagnosticar el problema.
Las acciones programadas de WordPress
Lo primero que hice fue pasar por las acciones programadas, donde se muestran todos los procesos de WordPress y sus plugins que se ejecutan de manera recurrente, a través del cron de WordPress o alternativos.
Y lo primero que vi es que había algunas de estas acciones programadas que no se habían ejecutado, estaban con la fecha pasada. En mi caso la más grave era el gancho yswbw_schedule_subscription_payment, precisamente la que lanza el pago de los servicios de suscripción.
Por supuesto, si ejecutaba manualmente el gancho desde las acciones programadas estas se lanzaban, pero no es eso lo que uno espera de un servicio automatizado ¿no?
Ahora bien ¿quién era el culpable de que no se ejecutasen automáticamente estas acciones programadas? Pues el primer sospechoso habitual siempre es el cron de WordPress.
Así que me lancé a hacerme caso a mi mismo y comprobar si estaba funcionando el cron de WordPress o alguna alternativa que tuviese activa. En este caso lo tenía desactivado, pero había creado un cron real, así que en principio debería funcionar, pero la realidad es que no funcionaba.
De todos modos los cambié y dejé activo el cron de WordPress, comprobando que seguían sin funcionar las acciones programadas, ni las de mi plugin de suscripciones ni ninguna otra.
«Crontrolando» el Cron
Visto esto, pasé a la segunda herramienta, WP Crontrol, maravilloso plugin que deberías tener en tus favoritos siempre.
Una vez instalado y activo pude comprobar que, efectivamente, había montones de acciones que no se ejecutaban.
Esto confirmaba el problema, pero no me ofrecía ninguna solución.
Pero, mira por donde, una de las ocasiones en que revisé la pantalla de los eventos cron del plugin WP Crontrol este me recibió con un mensaje de error que, esta vez sí, me daba una pista.
Cuando da gusto ver un error 503
Resulta que había eventos cron que generaban una respuesta de error 503, o de servicio no disponible.
Ahora bien, este tipo de error puede generarse por un montón de posibles causas:
- Scripts
- Plugins
- Temas
- Reglas de seguridad
- Fallos en el servidor
Pero como ya había probado scripts, plugins y temas, pasé a probar si alguna regla de seguridad de la web podría estar bloqueando acciones programadas del cron.
En principio no era nada que hubiese puesto por mi cuenta, ni el plugin de seguridad ni reglas adicionales, así que solo me quedaba un elemento de todo el sistema que no había revisado: CloudFlare, que también tiene herramientas de seguridad, otro de los motivos por los que suelo recomendar esta CDN.
El misterioso Bot Fight Mode de CloudFlare
Revisando la página del Firewall de CloudFlare de repente aparecieron un montón de acciones bloqueadas por el cortafuegos, en los que la ruta era casualmente wp-cron.php.
Entrando más en detalle se podía ver que, efectivamente, había algo llamado Bot Fight Mode que había bloqueado procesos JS provenientes de wp-cron.php.
Pero ¿qué era eso del Bot Fight Mode?
El Bot Fight Mode es una funcionalidad que incluyó CloudFlare en marzo de 2021, con 2 modos:
- Gratuito, para todo tipo de cuentas, también las gratis.
- Super Bot Fight para cuentas de pago, más fácil de gestionar y revisar.
Pero sencillamente yo no recordaba haberlo activado, a no ser que CloudFlare decidiese en su momento activarlo automáticamente para todas las cuentas. En cualquier caso me pasé por la página de configuración de los bots de CloudFlare, y ahí estaba él, todo mono, activado.
La(s) solución(es) al Bot Fight Mode que bloquea acciones programadas del cron de WordPress
Así que tenía por delante 2 posibles soluciones a mi problema:
- Desactivar completamente el Bot Fight Mode – Fácil, solo hay que hacer clic en el selector y problema arreglado.
- Crear una regla para excluir del Bot Fight Mode los procesos sensibles – Algo más complicado, pero tampoco nada del otro mundo.
Inicialmente desactivé el Modo Bot Fight, para comprobar si ya se ejecutaban las acciones programadas.
Y, efectivamente, todo funcionaba ya correctamente.
De todos modos preferí usar el segundo método, dejando activo el modo Bot Fight, que realmente sirve para bloquear muchos intentos de bots de acceder a tu web, pero creando una regla para que no bloquee el cron de mi web.
Además, es muy fácil hacerlo, solo tienes que ir a la sección de Reglas de firewall y crear una regla nueva con varios campos sencillos, como en la siguiente captura:
A partir de este momento, teniendo activo el modo Bot Fight, este permitirá las conexiones de wp-cron.php de las webs indicadas en la regla.
La entrada Acciones programadas que no se ejecutan por culpa del Bot Fight Mode de CloudFlare la publicó primero Fernando Tellado en Ayuda WordPress. No copies contenido, no dice nada bueno de ti a tus lectores.
0 Commentaires