Fixing slow wp-cron requests on servers behind NAT routing

So we’ve been having a weird problem with WordPress installs on supposedly fast linux VMs running very slowly. It was mainly noticeable on server requests for the Dashboard by logged in users. After a bit of analysis using New Relic, we narrowed it down to external web requests taking a long time.

The trouble was, these requests were mainly pointed back to the server itself. For instance:

htp://myserver.com/wp-cron.php?doing_wp_cron=12345678

The actual load on Nginx & PHP processes was practically non-existent. PHP was just waiting for it’s cURL requests to come back. How strange.

As it turns out, the server was receiving all it’s network traffic via NAT, which meant that while myserver.com resolved to, say, 194.100.99.98 (an external IP), all the actual box was aware of was it’s internal IP, say 10.11.12.13. The external was never directly configured as one of it’s network interfaces. This meant that requests like the above had to make a round trip all around the network and back again before they’d get processed. Not good.

Our solution was to setup an alias for the loopback interface so the external IP would behave exactly the same as 127.0.0.1 when it was requested internally, and so never leave the box:

[bash]
vi /etc/sysconfig/network-scripts/ifcfg-lo:1

DEVICE=lo:1
IPADDR=194.100.99.98
NETMASK=255.255.255.255
NETWORK=194.100.99.98
ONBOOT=yes
NAME=loopback194
[/bash]

“service network restart” or a quick reboot and job done!

This was on CentOS 6.5 btw, but I’m sure it’s pretty similar for Ubuntu or any other flavour of Linux.