403 Forbidden – The page works on all other networks (VPN, mobile, home Wi-Fi), but on our school IP address (185.188.217.37), both domains return a 403 error.
Other Information
The problem started after a large number of students accessed the site at the same time. We suspect our school IP may have been rate-limited or temporarily blacklisted.
We have added Cloudflare protection and the websites are working fine everywhere else, but we need the site to be accessible from school as well — it’s used for testing and academic purposes.
Previously it was showing a typical InfinityFree 403 Forbidden error page.
Now, it’s just a blank white screen – no error, no content.
The same site works fine from other IPs and devices.
It seems like a soft block or silent restriction from the host side, not from the school’s firewall or ISP.
We’ve already configured Cloudflare on the new domain (testi-bgt.com) and everything works fine from other networks.
However, the original IP (from school) still can’t access the site — not even after Cloudflare.
That’s why we suspect the IP got blacklisted earlier before Cloudflare was added.
We’ve checked with the school network administrator and there is no restriction from their side for these domains. Also, other websites are working fine from the same network.
This issue appears only with domains hosted on InfinityFree.
The domains work perfectly from other networks (mobile, home internet, VPN), so it seems like our IP might have been rate-limited or blacklisted temporarily due to the high number of simultaneous accesses.
Just to clarify, we are not using Virgin Media – it’s a local ISP.
Have you tried accessing the site from a different network, using the same ISP as the school, with the same restrictions from the ISP? The reason I mentioned Virgin Media (my ISP) is because if one ISP is blocking the domain, there’s a reasonable chance that others are also blocking it.
Infinity Free & IFastNet tend not to IP block people, even if there are lots of simultaneous contacts.
Might also be worth clearing any browser cache. That can sometimes cause issues.
Yes, we’ve tested the website from multiple networks — including mobile data, home WiFi, VPN — and everything works perfectly only when not using the school IP.
So it’s clearly not a browser cache issue, and not related to the ISP in general.
Also, this same school IP was working fine with the domain until there was a burst of student traffic, so something happened after that moment — likely a rate-limit or automatic temporary block triggered on the host side before Cloudflare was set up.
Now that Cloudflare is active, new IPs work fine — only the school IP remains unable to access the domain. So unless the school magically decided to block it in the same moment as the traffic spike, the most logical cause is a temporary block on InfinityFree or iFastNet side.
We’ve already tested this — multiple devices within the same school network (same IP) cannot access the site.
However, when switching to a different IP (like mobile data, home Wi-Fi, or VPN), the website opens instantly.
So it’s not device-specific, and not a browser or DNS cache issue.
This points clearly to the school IP being blocked or rate-limited, either by InfinityFree/iFastNet before Cloudflare was set up, or potentially a leftover restriction.
Now that Cloudflare is in place, all other IPs work fine — just this one remains affected.
To answer your exact request: Different device Different IP (e.g., mobile hotspot, VPN) Same network/ISP — we only have one static IP at school, so we can’t test different IPs on the same network/ISP.
But to clarify:
That one school IP still cannot access the site.
All other networks (home, mobile, etc.) work without issue, so it’s pretty clearly tied to the school’s static IP being blocked — either by the hosting or earlier firewall triggers.
What is the HTTP response code provided? What are the response headers?
Unless you can prove (Not speculate) otherwise, this sounds like a local firewall / ISP block situation to me. I have yet to see any proof it is otherwise, especially since IPs are rarely blocked (And in my experience those that are don’t return white pages or 403 errors).
Either way, if an IP is blocked by the hosting server, I don’t believe you can make a unblock request
Here’s the error we were getting earlier (screenshot attached) — standard 403 Forbidden from OpenResty. Since then, it just shows a blank white page, no HTTP error message.
We’ve:
Switched domains
Put it fully behind Cloudflare
Verified the site loads fine everywhere except from the school’s static IP
All devices & browsers inside the school give a blank page. VPN or different IP? Loads instantly. So the server clearly responds — just not to that IP.
Not saying it’s definitely InfinityFree, but just trying to rule things out systematically.
Assuming the response code is 403, but can you double check that and also share the response headers?
I’m not quite sure why you are fixated on Cloudflare being a part of this, it is not. Your local firewall/ISP is most likely blocking by hostname, not destination IP. It also does not affect anything on the hosting server side, as Cloudflare still shares the origin IP with the server by default. You can try disabling the send IP to origin setting in cloudflare (I think you have to do a manual header block, not sure as I have never done it), and that will either break everything, or confirm that the block is almost certainly not on the hosting side.
A VPN would hide your destination from your local firewall / ISP if configured correctly, so that does not rule out anything.
EDIT:
The openresty error is usually served by the server (So you are connecting and not getting blocked). Try clearing your cache as that error is temporary and may have been locally cached.
Thanks for the guidance. Unfortunately, I won’t be able to access the school network again until Monday, so I can’t pull the DevTools data just yet. I’ll make sure to get the exact HTTP response code and headers as soon as I’m back on that network and will share them here.
This is odd though. We do have security checks in place to keep out bad IP addresses, but those block connections on the network level. So you would just see a connection timeout or connection reset error or something like that, not a 403 error.
If you are redirected to our 403 page, it means that the request is reaching your website code, which means it’s not blocked by a server rule.
Instead an unexpected 403 Forbidden page is usually the result of a website configuration issue. It might also be caused by browser cache, or a web proxy cache if there is one.
Another reason you might get a 403 error is if your browser is being blocked.
Does your school have a WiFi network you can use? If so, could you try connecting to it with your phone and seeing what happens if you open the site that way? That may tell us more about whether the issue is something on the network level or is affected specifically by the school computers.
Different device
Same network/ISP — we only have one static IP at school, so we can’t test different IPs on the same network/ISP.