Argh WordPress Site down due to DNS Misconfiguration


Well the Bluehost site was a pain, but didn’t have this kind of instability. So now trying to figure out what is wrong. This took a long while, but tl;dr, look at your DNS configuration sometime. But here is the debugging and the main notes are to use curl -v extensively to look at Apache2 rewrite, I ended up making my DNS confusing and pointing to a non-existent machine, so here’s the saga, but it is quite mysterious because having a bad IP address doesn’t give very good error messages, it just causes a “Pubish error” in WordPress and if you use a brower, it just hangs. So use curl to figure out what is really being accessed. Ping doesn’t work because Apache2 has redirects that are the level above a ping.

Looking at it, the symptoms are, first check to make sure it really is down

  1. The WordPress to publishing failed with publish failed. Not super good error diagnostics.
  2. I thought it was a clock error because I’m debugging a clock problem too there. But that doesn’t seem to be it.
  3. Went to DigitalOcean and saw that I could login as root.
  4. Tried to run a curl and got a redirection message, a 301 saying it refers to, so I’m beginning to wonder if it is SSH certificate problems
  5. Rebooted the server when it started to say connection refused on the SSH port.
  6. Just trying to get to and get the ERR_TIMED_OUT message from Chrome. When I try to curl it, I get back a null response, so nothing is answering
  7. When I try to curl to the wordpress admin page, I get a 301 that cirect to thye SSL site.

It is now back up, so time to figure out, so here is what I have found:

  1. Seeing if the Apache server is up in the Droplet and run service apache2 status and I get that it is running
  2. Now check the log files in /var/logFirst look at system.log, this looks fine, there is a bunch of blocking from UFW
  3. But when looking at the firewall with uff status it seems OK and allows access to 80 and 443 ports from anywhere
  4. Some else suggest looking a mysql status with service mysql status but this shows as running.

The last time this happened, it had to do with ssl certificates, so off to look at certbot and php redirects:

  1. There are two levels of access control. The highest is in WordPress itself in /var/www/html/.htaccess on the default WordPress Droplet installation. It had a bunch of DenyAccess from iThemes Security to wipe out specific IPs that were attacking the site. Then there is a section on rewrites in mod_rewrite.c. This requires that you understand Apache rewrite rules with a tutorial. But basically, a RewriteRule has a first regular expression like ^index\.php$ which look for the string index.php and nothing else and then the second argument is what to rewrite it to and then there are flags which the most important is [L] which means don’t keep using rewrite rules, just stop here. You can have conditionals so that you can have a series of RewriteCond that says only run the following Rewrite Rules if they are met so RewriteCond ${REQUEST_FILENAME} !-f means if the filename requested isn’t a real file then run the following rules. These all looked fine and were not the source of the redirects.
  2. In /etc/apache2 are the various Apache, here we hit a gold mine. First of all there is a set of configurations in sites-enabled that are symlinked to site-available as you want them. In one of them we have ‘000-tongfamily.conf and at the bottom it says anything with is rewritten to use HTTPS then something created by lets encrypt call 000-tongfamiliy-le-ssl.conf and this has the link to the SSL Certificates and so forth.

So the bug appears to be in the SSL version of

  1. To see if this is the case, let’s create a new SSL-less configuration in /etc/apache2/conf-availablewhere called 000-tongfamily-nossl.conf and comment out these lines, the disable the ssl version with a2dissite 000-tongfamily.conf and a2ensite 000-tongfamily-nossl.conf and then restart apache2 with systemctl reload apache2
  2. At this point both and return null from a curl, so we have validated the problem is not in the configuration. Something is wrong in WordPress.
  3. So now run more diagnostics to see the headers curl -v and we can see the 301 moved message then with curl -v we finally see that it is redirecting to

Suddenly I remember hacking away at the DigitalOcean DNS:

  1. We see that with curl we get a hang and that a ping to leads to some random site. I think I have a misconfigured DNS!
  2. The problem was that I had it pointing to a DigitalOcean Droplet that no longer existed. So the redirection from to was a bad idea with the DNS for correct, but not for the www part.
  3. So fix all this and reenable the site and wait for it too propagate.

Related Posts

© All Right Reserved