wp-admin tardando de 50 a 150 segundos por página: peticiones externas que nunca vuelven

En un párrafo: cuando la web pública va rápida pero cada página del wp-admin tarda cerca de un minuto o más, WordPress suele estar esperando peticiones a servidores externos que nunca responden. En esta tienda el servidor no podía llegar a api.wordpress.org de ninguna forma, y un plugin no paraba de llamar a un servidor de actualizaciones que ya no existía. Bloquear esas llamadas bajó las páginas del panel de 47 a 151 segundos a alrededor de un segundo, mientras el hosting arreglaba la red.

Síntomas

Una tienda WooCommerce cuya parte pública cargaba con normalidad.
Cada página del panel tardaba entre 47 y 151 segundos. Escritorio, plugins y actualizaciones eran las peores.
Nada en el registro de errores de PHP lo explicaba. Las páginas no fallaban, solo esperaban.

Por qué el panel y no la web

WordPress, los temas y los plugins comprueban actualizaciones, licencias y novedades desde el panel. Esas comprobaciones son peticiones HTTP a otros servidores. Cuando el otro lado responde, tardan milisegundos y se guardan en caché. Cuando la conexión se queda colgada, cada página espera hasta el tiempo límite, y algunos plugins repiten la comprobación en cada página del panel.

Cómo diagnosticarlo

Prueba desde el propio servidor. Por SSH:
```
curl -sS -m 10 -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.wordpress.org/core/version-check/1.7/
```
Un servidor sano responde 200 en bastante menos de un segundo. El nuestro agotaba el tiempo tanto por IPv4 como por IPv6.
Lista las llamadas externas. Si el panel llega a abrir, el plugin Query Monitor muestra cada llamada de la HTTP API con su duración. Busca llamadas de 5, 10 o 20 segundos.
Cuando no tienes herramientas. Los hostings compartidos a menudo no tienen ss ni netstat. Las conexiones atascadas en estado SYN_SENT siguen apareciendo en /proc/net/tcp con el código de estado 02, y su dirección remota está en hexadecimal. Decodificarla te dice a qué servidor está esperando PHP.

En esta tienda encontramos dos problemas a la vez: api.wordpress.org inaccesible desde ese servidor, y un plugin premium de importación y exportación que llamaba a su propio servidor de actualizaciones en cada página del panel. Ese servidor ya no existía y cada llamada esperaba unos 20 segundos.

La solución temporal

Un pequeño plugin must-use que rechaza las peticiones a los hosts que se cuelgan. WordPress recibe un error inmediato en lugar de esperar:

<?php
/* Plugin Name: Block hanging external hosts (temporary) */
add_filter( 'pre_http_request', function ( $pre, $args, $url ) {
	$blocked = array( 'api.wordpress.org', 'update.example-plugin.com' );
	$host    = wp_parse_url( $url, PHP_URL_HOST );
	if ( in_array( $host, $blocked, true ) ) {
		return new WP_Error( 'http_blocked', 'Temporarily blocked: ' . $host );
	}
	return $pre;
}, 10, 3 );

WordPress también tiene un interruptor propio, WP_HTTP_BLOCK_EXTERNAL, combinado con WP_ACCESSIBLE_HOSTS para los hosts que sigues permitiendo. El filtro de arriba es más preciso: solo bloquea lo que está roto.

Con él activo, las páginas del panel abrieron en un segundo aproximadamente.

La solución de verdad

Bloquear api.wordpress.org también bloquea los avisos de actualización y las actualizaciones de seguridad, así que no puede quedarse así. La solución le corresponde al hosting: hay que restablecer el acceso de salida de ese servidor. Mientras tanto actualizamos el núcleo de WordPress subiendo el paquete a mano. El bloqueo se quita en cuanto el servidor vuelve a llegar al exterior. Para el servidor de actualizaciones muerto, lo tiene que arreglar el fabricante del plugin, o hay que sustituir el plugin.

Lista de comprobación

Web rápida, panel lento: prueba primero el HTTP de salida desde el servidor.
Localiza exactamente los hosts que se cuelgan antes de bloquear nada.
Bloquea solo esos hosts y apunta por qué.
Pide al hosting que arregle el acceso de salida y quita el bloqueo después.
Mantén el núcleo y los plugins actualizados a mano mientras las actualizaciones no funcionen.

Preguntas que nos hacen sobre esto

¿Es seguro bloquear api.wordpress.org?

Solo durante poco tiempo. Dejas de recibir avisos de actualización, también los de seguridad, así que hay que quitarlo en cuanto se arregle la red.

¿Una CDN o un plugin de caché arreglan un panel lento?

No. El panel no se cachea, y el retraso está en las peticiones que tu servidor hace a otros servidores.

¿Por qué fue empeorando con el tiempo?

Los plugins que no consiguen completar su comprobación de actualizaciones nunca guardan un resultado en caché, así que lo vuelven a intentar en la página siguiente, y en la otra.