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