Why can't /wp-login.php be load balanced?

A few things to check on:

Review wp_salt. Make sure all of the web servers are running on the same set of salts in the wp-config.php file. Ideally, these should be mirrored from a single location.
Review is_ssl() and make sure this function is properly detecting SSL across all of your web servers. I’ve seen this little function cause a lot of headaches when the load balancer makes an internal connection on port 80 to the web server. If is_ssl() doesn’t detect this (due to load balancing) it may cause this problem; i.e., possible cookie protocol changes.

One quick solution is to check for the forwarded protocol in wp-config.php

if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
        && strcasecmp( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) === 0 ) {
    $_SERVER['HTTPS'] = 'on'; // Convince WordPress.
}

Review the $_SERVER['REMOTE_ADDR'] environment variable and make sure this is being populated in the same way across all web servers. There are many plugins for WordPress that will use this, not considering a load balanced scenario.

Easiest way to check is to dump the <?php phpinfo(); on a few web servers and check if they are all setting this properly. Or does the actual IP address end up in HTTP_X_FORWARDED_FOR, HTTP_CLIENT_IP, or something else? In short, avoid confusing plugins by fixing REMOTE_ADDR.
Make sure system time is in sync across all web servers.
Look more closely at any plugins that have the goal of preventing brute-force attacks, as these are more likely to be doing some strict validation; e.g., testing user-agent, IP addr, changes in ip address, etc. Their job is to not be fooled, but sometimes they produce false-positives.

If problems persist, please post a list of the active plugins you’re running and the Nginx configuration you mentioned. FastCGI params would be good to look at, along with any proxy configuration you may or may not have.

Related Posts: