客户网站在中国大陆，迭代几轮并引入若干新插件后，后台性能急剧下降，后台风吹草动，前台页面立刻纹丝不动。
Query Monitor显示出站HTTP API CALLS，意料中的api.wordpress.org，my.elementor.com至少能返回HTTP 200 OK，另有4个插件的更新远端被Connection Reset，2个不间断超时且有超时重试设置，更糟糕的是2个插件的作者决定自己做upgrade check，有一个插件（功能需要，但实现欠妥）把500ms的HTTP请求（到国内三方服务API）写进WP前台HOOK。
一轮试验下来，发现普通加速方法效果不好，后台请求仍超时只是频率有所降低，前台请求反而变慢。
客户每天都要频繁登录操作后台，在找到合适线路的跳板服务器之前（待选项里可能只剩香港），不得已先用：
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
这会切断网站后台到外网的所有请求，后台立刻变得飞快，但也有代价。
有些插件的运行时就像没网络玩不了的所谓“单机游戏”，这个看情况，影响核心功能的，考虑加白名单，让它过，只影响更新的，先Ban掉，要更新的时候再放，好在多数插件似乎都可以先不进白名单。
define( 'WP_ACCESSIBLE_HOSTS', join(',', [
'*.wordpress.org',
'*.imagify.io',
'*.runcloud.io',
'*.weixin.qq.com',
]);因为我们放过到*.wordpress.org的所有请求，绝大多数插件的日常搜索、下载、安装、更新都不受影响（读者可以考虑配合Easy Updates Manager来选择性地启动自动更新），后台因此不会有“飞快”的速度，但至少不再给人“慢”的感觉，这是一种折中平衡的方案。
这个站点的插件数量60+，属于功能相对复杂的项目，国内的WP站点只要插件一多碰到这类问题几乎是必然的，也没有特别干净的解决方法，因为国内服务器避不开网络限制的根本问题，但功能没那么复杂的项目一般不需要这么折腾，也不必过于担心。