Connection Refused, revisited

I was going to re-open a previous thread [Connection Refused] but I don’t see how to do that, so I’m starting a fresh thread to revisit this situation.

Quick backstory: two of my child sites hosted on Bluehost seemingly suddenly disconnected from my MainWP dashboard and cannot reconnect. When I run the “Test Connection” option during the “add site” process, the error I receive is “Connection Refused”. I have never had any other (out of 50+) child sites produce this specific error.

I have gone through as much of the standard troubleshooting steps as I have found, including adding my Dashboard’s IP to the Allow list in Wordfence, completely disabling/removing Wordfence, checking .htaccess for additional security rules, and reaching out to Bluehost to ensure there are no hosting firewall blocks in place. After being escalated to the more technical branch of support, I received the following response:

From case review, I understand that we have whitelisted the IPs of MainWP service for your website, however I have readded IP 169.59.11.40 to whitelist. If there are any additional IPs available for MainWP, please let us know so that we can try whitelisting them all. This should be the only constraint from hosting server end if the connection issue is located from hosting server as I looked into the help article from MainWP regarding the “connection timeout error” issue I found here:
[Can’t connect Website, getting the "Connection timed out" error message! - MainWP Documentation]

Additionally, I verified that there were no blocks that I could locate for MainWP Child plugin on the server logs. Also, from the troubleshooting steps mentioned in above article, I would suggest you to check if any security plugin is installed and if there are some security rules left by them and to make sure no custom security rules in the file.

Since the IPs are already whitelisted on our end, I would suggest contacting [MainWP Support] as suggested by them in the same help article above. If there are any specific details that MainWP Support has for us to check or to update on our server end, please do let us know so that we can definitely look into it and help you further accordingly.

There are no proxies in place that I know of, not using CDN such as Cloudflare, nothing else that I can tell would put a block between these two sites. If I’m missing something or you have additional things I should check, please let me know.

There are 2 sites giving me this “connection refused” error. One had recently been migrated to Bluehost when the error arose (although it had connected fine after initial migration). The other had no changes made to it around the time of the sudden disconnect and refuse to reconnect.

Thanks for putting up with me dredging this back up - I’d really like to bring these sites back into my automation routine rather than resorting to my workaround of simply logging into them directly once a week. Thanks in advance.

1 Like

Hey @SunfireWeb

This really looks like a firewall issue. The connection refused, error 443, is a very common indicator for it.

The Connection Test from my test Dashboard is successful, which suggests that only your Dashboard is blocked.

Can you ask the support of the host where your Dashboard is located to run a tracert test to the child site so we can see where exactly connection is breaking?

And you can also ask Bluehost support to run a tracert test from the child site to the Dashboard URL just so we have the information how the connection is working in that direction as well.

And can you also send me the System Report via a personal message? Just click my name and then the Message button.

Thanks for the quick reply, Bojan. I also appreciate your testing from a different dashboard.

I have a request back over to Bluehost and have started a chat with the host for my Dashboard site.

I will send you a direct message with the System Report.

2 Likes

Tracert from child site host to my dashboard, as performed by Bluehost:

traceroute to mainwp.hitsaru.com (169.59.11.40), 30 hops max, 60 byte packets
 1  10.25.72.21 (10.25.72.21)  0.475 ms  0.354 ms  0.262 ms
 2  162-214-41-3.unifiedlayer.com (162.214.41.3)  0.479 ms  0.570 ms  0.483 ms
 3  po7.prvspn001.net.unifiedlayer.com (162.144.240.106)  0.393 ms po7.prvspn002.net.unifiedlayer.com (162.144.240.110)  0.576 ms  0.472 ms
 4  * * *
 5  69-195-64-100.unifiedlayer.com (69.195.64.100)  1.240 ms  1.231 ms  1.148 ms
 6  162-215-195-140.unifiedlayer.com (162.215.195.140)  16.441 ms  16.525 ms  16.526 ms
 7  162-215-195-129.unifiedlayer.com (162.215.195.129)  20.417 ms  20.349 ms  20.256 ms
 8  ce-0-19-0-2.r00.lsanca07.us.bb.gin.ntt.net (168.143.228.172)  16.468 ms  16.309 ms  16.252 ms
 9  * ae-5.r24.lsanca07.us.bb.gin.ntt.net (129.250.3.16)  16.771 ms ae-6.r25.lsanca07.us.bb.gin.ntt.net (129.250.3.237)  18.043 ms
10  ae-0.a02.lsanca07.us.bb.gin.ntt.net (129.250.2.186)  16.371 ms ae-1.a02.lsanca07.us.bb.gin.ntt.net (129.250.3.234)  16.288 ms  15.930 ms
11  xe-1-0-1.bbr02.cs01.lax01.networklayer.com (198.172.90.82)  16.157 ms  16.191 ms  16.108 ms
12  f1.10.35a9.ip4.static.sl-reverse.com (169.53.16.241)  17.201 ms  17.117 ms  17.338 ms
13  ae2.cbs01.dr01.dal04.networklayer.com (169.45.18.6)  48.669 ms  47.082 ms  46.398 ms
14  ae2.dar02.dal13.networklayer.com (169.45.18.39)  48.055 ms  67.017 ms  47.846 ms
15  8b.76.30a9.ip4.static.sl-reverse.com (169.48.118.139)  45.667 ms 81.76.30a9.ip4.static.sl-reverse.com (169.48.118.129)  47.156 ms 85.76.30a9.ip4.static.sl-reverse.com (169.48.118.133)  46.903 ms
16  dd.76.30a9.ip4.static.sl-reverse.com (169.48.118.221)  45.915 ms db.76.30a9.ip4.static.sl-reverse.com (169.48.118.219)  45.596 ms d5.76.30a9.ip4.static.sl-reverse.com (169.48.118.213)  45.562 ms
17  hs7.name.tools (169.59.11.40)  47.462 ms  46.213 ms  47.318 ms

They said it was run from the Bluehost account IP, 162.241.224.224

Still waiting to hear back from the host for my Dashboard.

Thanks for the update @SunfireWeb

Let’s wait and see what the tracert from the Dashboard will show.

1 Like

Still waiting. Other host’s auto-reply indicated a high volume of requests, and that trying to bump it up by replying would actually push it DOWN the queue, so I am just waiting…

1 Like

Reply from host of my mainwp dashboard:

When our Sys Admin tried traceroute was failing and seemed to be disabled on external server.
Here are the wget/curl results:

# wget http://adaptivesportsnw.org
--2022-06-24 20:24:01-- http://adaptivesportsnw.org/
Resolving adaptivesportsnw.org (adaptivesportsnw.org)... 162.241.224.224
Connecting to adaptivesportsnw.org (adaptivesportsnw.org)|162.241.224.224|:80... failed: Connection refused

# wget https://adaptivesportsnw.org
--2022-06-24 20:22:52-- https://adaptivesportsnw.org/
Resolving adaptivesportsnw.org (adaptivesportsnw.org)... 162.241.224.224
Connecting to adaptivesportsnw.org (adaptivesportsnw.org)|162.241.224.224|:443... failed: Connection refused.

# curl -vv adaptivesportsnw.org
* About to connect() to adaptivesportsnw.org port 80 (#0)
* Trying 162.241.224.224...
* Connection refused
* Failed connect to adaptivesportsnw.org:80; Connection refused
* Closing connection 0
curl: (7) Failed connect to adaptivesportsnw.org:80; Connection refused

# curl -vv https://adaptivesportsnw.org
* About to connect() to adaptivesportsnw.org port 443 (#0)
* Trying 162.241.224.224...
* Connection refused
* Failed connect to adaptivesportsnw.org:443; Connection refused
* Closing connection 0
curl: (7) Failed connect to adaptivesportsnw.org:443; Connection refused

Please let us know if you have any additional questions and we will be happy to help!

I responded explaining that we’re trying to find out WHERE the connection is being refused which is why we requested the tracert specifically. I also notified them that the remote has confirmed there is no block on their end that should prevent this connection.

Any other thoughts or suggestions?

1 Like

We learned that the child site is unreachable even when their Sys Admins tried to do wget and curl the child site. So that rules out MainWP Dashboard as a potential culprit and confirms that the issue is with the Child site.

But you are correct. The reason we asked for tracert was so that we could see where exactly is connection breaking. And then to present that information to the host of the child site.

Would you mind asking them again to perform tracert?

1 Like

Thanks for clarifying that process of elimination (that the issue is the Child Site and not the dashboard) - that helps a lot, since I actually have 2 child sites hosted on Bluehost that are presenting the same symptoms.

I have asked, once again, for the tracert from the Dashboard host and will share the feedback I get.

1 Like

The dashboard host says the tracert “failed outright as soon as it was attempted” and provided no further explanation or output. I have asked for additional information, but I don’t think they’re going to give me much else to go on.

Additionally, I just migrated another client site to Bluehost and it is now giving me the same “Connection Refused” when I try to reconnect it to the dashboard.

So it’s definitely something with Bluehost… I will check with them again.

1 Like

Thanks for the update. Let us know if you get any information from Bluehost.

Btw, another user who has been struggling with the same issue as you has had their Bluehost child sites reconnect by themselves a couple of days ago. So it’s possible that Bluehost is working on the issue.

2 Likes

Ah, interesting.

Anyhow, I have just re-opened my previous ticket with Bluehost and added some additional details. During the process of providing data, I included the list of IP addresses (from the DNS records) of all the child sites that get the “connection refused” message and I noticed they were all in the 162.241… range whereas the child site that is on Bluehost but has no trouble connecting to my Dashboard is in the 162.144… range. It’s possible there’s something at that first range that’s refusing my connections - we’ll see what Bluehost says.

1 Like

Just keeps getting interesting, and more frustrating.

Host of MainWP dashboard attempted a tracert to another Bluehost-hosted client (that I normally don’t have issues with connecting in MainWP) and provided this output:

[[email protected] ~]# traceroute 162.144.97.210
traceroute to 162.144.97.210 (162.144.97.210), 30 hops max, 60 byte packets
send: Operation not permitted

And Bluehost has tried to blame this inability to connect on Wordfence, again. They tell me to disable it and try connecting again (which I’ve done more than once with no change) rather than escalate me to someone who can look at things from a higher level (which I’ve requested since I mentioned the pattern spotted in the IP addresses).

But since the tracert fails while MainWP stays connected for the site in the 162.144 range, I’m not sure tracert will give us much to go on…

Admittedly, I’m getting rather frustrated with Bluehost’s “support” and am considering suggesting my clients move to another host. Until then, I will continue logging into the sites directly since I can’t seem to get the Dashboard talking to the Child sites.

Any other thoughts here?

1 Like

What’s odd to me is the tracert “send: Operation not permitted” error message.
This means that the tracert was actually prevented from running on the hosting server. Not that the Bluehost server blocked it at some point.

The reason we tried getting them to run tracert is so that we could see a full list of network hops and to verify at which hop exactly was the connection blocked.

I’m not a networking expert, but from quick Googling, it seems that tracert will give this error when there’s a misconfiguration with iptables, which is something the host should be able to help with.

It would be nice to have tracert information so you can provide it to Bluehost, but it’s an open question if they would be willing and able to fix the issue on their end even then.

Thing was, when they did a tracert to google.com, they did not get the “Operation not permitted” message… So I really don’t know what’s up on the Dashboard host’s end.

Like I said, I feel like this has become more trouble than it’s worth, trying to troubleshoot between three different support channels. Either I will stop recommending Bluehost, or I will find a new host for my own Dashboard.

Does MainWP recommend any specific hosts for their Dashboard?

1 Like

We have a list of select hosting sites with details about known compatibility issues, with couple of them having no known issues: Hosting Compatibility - MainWP Documentation

1 Like

Thanks. I’ll look into these options and see what makes sense to move.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.