All of my sites that use a PHP index return this error. All of my sites that use a HTML index, like https://jri.rf.gd, they do work just fine. Just in case my MacBook was being an (bleep), I tested my sites on other devices, returning the same unusual error. My sites have been online for awhile, so I know that it isn’t a DNS issue. In fact, even with new sites, my Network Provider’s DNS cache resets every day, so I know something’s online either immediately or after 24 hours.
Did you also test it on another network? If all sites on a particular domain suddenly stop working, that could be the result of your internet provider blocking access to the rf.gd or our IP addresses. Free services unfortunately gets abused a lot, and some companies are convinced that this means that all free hosting users are criminals.
It’s probably not a DNS caching issue, but if the rf.gd domain is blacklisted in your DNS resolvers, you still won’t be able to reach it. That’s still a DNS issue.
It seems infrequent with my sites that use a PHP index. I haven’t had an issue with sites that use a HTML index. Seemingly, after using a site of mine with a PHP index, even though my account doesn’t say anything the site stops responding outright.
I have tested my sites on my home network (Spectrum), my school network (Cisco) and my Hotspot (Tracfone) and have had the issue after a bit of use of my site. In particular, my sites that use a PHP index. Spectrum seems to stop access after 10 minutes, Cisco after an hour, and Tracfone after 30 seconds. All other sites with an HTML index remain unaffected.
The IP address your website is on, 185.27.134.60, appears to be having intermittent downtime since the 20th of December. Overall, the uptime over those 1.5 days is just over 60% according to my metrics.
This could be the result of a DDoS attack, but I will ask iFastNet to know for sure.
Who would be attacking 185.27.134.60? I’m hopeful the issue, if there is one, is resolved. I have an FTP client on that IP, https://jftp.rf.gd, and I rely on it because my work device doesn’t support FileZilla.
Thanks for informing me that the issue isn’t originating from my network(s).
Unfortunately, that’s not a small list. It could be someone with a grudge against the owner of a specific website using the free hosting. Or maybe just a carpet bombing on any website that’s about a topic they dislike. Most likely they’re targeting a specific website that just happens to be on that IP address, and the other sites being affected are just collateral damage. That doesn’t make it any less bad though. Some people are malicious, yet have too much time on their hands.
Of course that’s assuming it’s a DDOS attack and not a hardware issue with the server, the data center’s network, or something else.
If there was a (D)DoS attack happening on the server(s), couldn’t the server operator pull a IP table, look for IP’s pulling on the server, and either limit them or stop them?
If there is a (D)DoS attack going on, assuming that the server and everything else isn’t failing, I’m lucky that it isn’t happening on my account (according to statistics). If a (D)DoS was originating from my account, while I would think the account would be flagged and stopped, I would do so anyways and report it.
Again, under assumptions that the hardware is good. I wouldn’t doubt hardware issues would affect things. I have a local server myself (lone-test enviroment) that had it’s PSU fail 3 weeks from this post, causing an outage not noticed until 27 minutes later by my iMac.
I just hope the issues are resolved as soon as possible.
It’s easier to just pull the plug and restart the system once the attack ends. Uses less resources.
Also, most DDoS attacks today use hundreds if not thousands of rotating IP addresses, so blocking them would not do any good. And even if you did block them, the entire point of a DDoS attack is to overwhelm a server, they don’t care if the requests are being blocked.
Here’s an easy solution. Stop the server, claim the server had issues and had to shut down in the Forums, and give it a day. Eventually, it’s gonna have to stop. If a person is (D)DoS’ing a server, and sees that it’s gone, I would think they would stop.
Even if it means taking 100’s of sites down, I think it’s effective.
Today, it seems worse. All of my websites on if0_37911611 return a ERR_TIMED_OUT, the Inspector Console showing a 0B transfer. That’s after I reloaded the page twice! [Because Chrome doesn’t like loading sites from the server unless you load them twice.]
EDIT: I swear, as soon as I say something about my site not responding, suddenly it’s working just fine!
Unfortunately the attackers often still don’t stop right away. Keep in mind that a DDoS attack is a really crude but really effective way to take down a server. The attackers want the server to stay down as long as possible, and won’t let up just because they’ve knocked it down. The only real advantage to taking the entire server or receiving IP addresses offline manually is the fact that it protects the server from being physically damaged from an overload. But the sites are still down which is what the attackers wanted all along.
Unfortunately DDoS attacks are just really difficult to stop. Protection services like Cloudflare can help you against them, but they’re useless if an attack is already reaching the server directly.
