Wordpress site experiencing ERR_CONNECTION_REFUSED

January 18, 2017 2.4k views
WordPress Ubuntu 16.04

Hello,

I have a 1 click install of Wordpress on Ubuntu 16.04 that is now experiencing ERRCONNECTIONREFUSED when accessing the site via IP address. This occurred after logging into the wordpress admin account from two separate computers at the same time (different physical locations, different IP addresses). The error is happening at only one of these location's wifi network. The site loads fine elsewhere - I even tested with my phone on a data connection with success, but as soon as I connect to the wifi here, the page will stop loading and shows the error.

What I did to try to fix:
I cleared cookies in browser. This didn't help.
I then reset the Authentication Keys and Salts in the wp-config.php file. This didn't help either.

I'm not sure how to proceed and my searches haven't been helpful yet. What's going on, and how can I regain access?

4 Answers

@amanabdulalim

There could be a number of things associated with that error, ranging from local connection issues to your IP being blocked by the web servers firewall, with a few other potential in-between.

So, let's start with a few basic questions:

1). Are you able to login to the web server as root or your sudo user (i.e. SSH)?

2). Can you connect to your server using SFTP and access your web root?

If no to the above, chances are that your IP has been blocked if there's an active firewall. That would definitely explain why you can access the website from other locations but not your own. To unblock your IP, there's only a few options.

Option #01: Login to as root via SSH from another location and from the command line, run:

sudo ufw status

If that returns enabled, then run:

sudo ufw disable

For security, you don't want to permanently disable the firewall, but if your IP is blocked, this should allow you to get back in.

Option #02: Contact DigitalOcean Support by submitting a support ticket from the control panel and let them know that your IP appears to be blocked and that you would like to see if they can login to the server and remove the block for you.

NOTE: If you've setup an SSH Key on the Droplet, you may be forced to do #01 though as their support team may not be able to login since your Droplet wouldn't be setup with a root password and root login at that point, would be disabled.

Restarting Your Web Server

If your IP isn't blocked, try restarting the web server using either:

service apache2 restart

or, if you're using NGINX,

service nginx restart

Delete the .htaccess File

In some cases, the .htaccess file used by Apache and created by WordPress can create issues. The easiest thing to do in such a potential case is to simply delete it and them login to the WordPress Admin and simply save your permalinks. By clicking save, it'll generate a new .htaccess file for you with the correct parameters.

Check Server Logs

If your IP isn't blocked and the web server doesn't seem to be the issue, we need to fall back and check your log files. Since you're using WordPress, there should be an error log in your home directory (i.e. where index.php resides for your WordPress installation). We should check the last 20-30 lines of that file to see if we can identify another issue.

@jtittle Thank you for the response. Your suggestions unfortunately didn't help, but I made an interesting discovery which I outlined towards the end of this reply.

To answer your questions, yes, I am able to login via SSH and connect via SFTP without any issue. This was how I managed to make edits to wp-config.php.

Option 1 was not successful. The firewall was active, so I deactivated it and still was unable to access the site. I'll be contacting the support team and see if they have any leads.

I also tried restarting my apache server, and deleting then recreating the .htaccess via permalink save on my phone. No luck.

I was unable to locate the server logs on the home WordPress directory, any pointers there?

I did discover something interesting after some more searching for a solution. It's possible that this is an ISP block. I tried running a tracepath command on my droplet and my output stopped here before terminating:
...
4: be-10007-sur03.[my city.state.area].comcast.net 31.888ms
5: be-231-ar01.[nearby city.state.area].comcast.net 33.360ms
6: lag-14.ear3.[my city]1.level3.net 38.650ms
7: no reply
8: ae-1-3501.ear2.[nearby city]1.level3.net 94.633ms asymm 7
9: [redacted IP address] 93.737ms asymm 11
10: no reply
11: no reply
....
30: no reply
31: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500

I'm not sure if I'm reading this right but it appears to hang once getting through Comcast's data centers, leading me to believe that Comcast may be blocking the site. This may explain why my other location and my phone's data connection works fine. I'll be trying to contact Comcast about this too.

@amanabdulalim

When you logged in via SSH/SFTP, did you login from the same location you're having these issues? If so, then it's not an IP block. If your IP was blocked by the firewall or, for one reason or another, by Comcast, you wouldn't be able to login at all.

That being said, it is possible that you're having connection issues from your current location, which can be identified by the trace you've ran. Seeing * * * as a reply within the first 5 or so hops is normal (it happens here with Charter Communications as well), though from 10-11 and onward, that, to me, is a sign of connectivity issues.

It's hard to say whether it's on DigitalOceans' end or an issue with Comcast, but it does appear that there is packet loss from what you've provided, so I would get in touch with DigitalOcean first and provide them with the full trace (with the IP's -- they need the full report, and all info) before bothering with Comcast (unless you're sure it's a local internet issue as their CS team isn't really trained to ID blocks or even issues unless they know of an outage and it shows on-screen -- I've spent more time on the phone with them than I'd like to have).

So first things first, get in touch with DO by submitting a ticket and providing the full trace.

I'm sure you already solved this but DO told me to whitelist my IP with:

iptables -I INPUT -s <allowed_ip> -j ACCEPT 
ufw allow from <allowed_ip> 
Have another answer? Share your knowledge.