wp-admin taking 50 to 150 seconds per page: outbound requests that never come back

In one paragraph: when the public site is fast but every wp-admin page takes close to a minute or more, WordPress is usually waiting on requests to outside servers that never answer. On this store the server could not reach api.wordpress.org at all, and a plugin kept calling an update server that no longer existed. Blocking those calls brought admin pages from 47 to 151 seconds down to about one second while the hosting company fixed the network.

Symptoms

A WooCommerce store whose front end loaded normally.
Every admin page took between 47 and 151 seconds. The dashboard, plugins and updates screens were the worst.
Nothing in the PHP error log explained it. The pages did not fail, they just waited.

Why the admin and not the front end

WordPress, themes and plugins check for updates, licences and news from the admin area. Those checks are HTTP requests to other servers. When the other side answers, they take milliseconds and are cached. When the connection just hangs, every page waits for the timeout, and some plugins run their check again on every admin page.

How to diagnose it

Test from the server itself. Over SSH:
```
curl -sS -m 10 -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.wordpress.org/core/version-check/1.7/
```
A healthy server answers 200 in well under a second. Ours timed out on both IPv4 and IPv6.
List the external calls. If the admin opens at all, the Query Monitor plugin shows every HTTP API call with its duration. Look for calls that take 5, 10 or 20 seconds.
When you have no tools. Shared hosts often have no ss or netstat. Connections stuck in the SYN_SENT state still appear in /proc/net/tcp with the state code 02, and their remote address is written in hexadecimal. Decoding it tells you which server PHP is waiting for.

On this store we found two problems at once: api.wordpress.org unreachable from that server, and a premium import and export plugin calling its own update server on every admin page. That host no longer existed, and each call waited about 20 seconds.

The temporary fix

A small must-use plugin that refuses requests to the hosts that hang. WordPress gets an immediate error instead of waiting:

<?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 also has a built-in switch, WP_HTTP_BLOCK_EXTERNAL, combined with WP_ACCESSIBLE_HOSTS for the hosts you still allow. The filter above is narrower: it blocks only what is broken.

With it in place, admin pages opened in about one second.

The real fix

Blocking api.wordpress.org also blocks update notices and security updates, so it cannot stay. The fix belongs to the hosting company: outbound access from that server has to be restored. Until then we updated WordPress core by uploading the package by hand. The block comes out as soon as the server can reach the outside again. For the dead update server, the plugin vendor has to fix it, or the plugin has to be replaced.

Checklist

Fast front end, slow admin: test outbound HTTP from the server first.
Find the exact hosts that hang before blocking anything.
Block only those hosts, and write down why.
Ask the host to fix outbound access and remove the block afterwards.
Keep core and plugins updated by hand while updates cannot run.

Questions we get about this

Is it safe to block api.wordpress.org?

Only for a short time. You stop receiving update notices, including security releases, so it has to be removed as soon as the network is fixed.

Can a CDN or cache plugin fix a slow admin?

No. The admin is not cached, and the delay is in requests your server makes to other servers.

Why did it get worse over time?

Plugins that cannot complete their update check never cache a result, so they try again on the next page, and the next one.