Skip to main content
If your website, control panel, email and FTP have all stopped working from one network but are fine from mobile data, your public IP address has been blocked by the server firewall.
The fix is a support ticket with your public IP address in it. Find it by visiting ip.me.uk or searching “what is my IP” from the affected network, then open a ticket at https://my.hosting.com. We check the firewall logs and clear the block.Send us the public address, not a local one starting 192.168., 10. or 172..

​
Is it actually a block?

Work through these four in order. They take two minutes and they decide everything that follows.
  1. Check our status page first. If a server-wide incident is running, nothing below will help and no ticket is needed.
  2. Try from mobile data. Turn Wi-Fi off on your phone and load your site or control panel. Working on mobile data but not your usual network is the signature of an IP block.
  3. Hard refresh, or use a private window. Ctrl+F5 on Windows, Cmd+Shift+R on Mac. If a private window works and your normal browser does not, it is your browser cache, not a block.
  4. Check whether it is down for everyone. An external checker such as downforeveryoneorjustme.com tells you whether the site is reachable from outside your network at all.

​
What a block looks like

  • Several unrelated services fail at once — website, control panel, webmail, mail client, FTP, SSH — because the firewall blocks the whole address, not one service
  • Only from one network. Mobile data works
  • Your site is fine for everyone else. Visitors see no problem
  • Error codes: ERR_TIMED_OUT, ERR_CONNECTION_TIMED_OUT or a login page that spins forever. ERR_CONNECTION_RESET and ERR_CONNECTION_REFUSED mean your request reached us and was actively rejected, which also points at the firewall
  • A message saying “Too many incorrect login attempts” is an explicit block
It blocks everyone behind that connection. The firewall blocks a public IP address, so if your office is blocked, every person and device on that office connection loses access at the same time — not just whoever triggered it.

​
What it is not

​
Why it happens

The firewall watches failed logins to the control panel, FTP, SSH and mail, and blocks the source address automatically. It cannot tell a real attack from a device holding an out-of-date saved password, and the second is far more common. The usual cause is a device you have forgotten about, retrying a stale password every few minutes:
  • An old phone or tablet still configured with a password you have since changed
  • A mail client on a machine nobody uses, retrying in the background
  • A colleague on leave whose laptop is retrying from inside a bag
  • A saved credential in a script, a backup job or a website plugin
  • A shared office connection where someone else’s client is failing
Other triggers that are not login failures at all:
  • High request volume. Rapid requests, automated tools, or a vulnerability scanner such as OWASP ZAP will trip the rate limits. Imunify360 raises a CAPTCHA DoS alert and blocks the address
  • Repeated refreshing. Hammering a failing page or login form looks like a brute-force attempt
  • A VPN or corporate proxy whose shared address has been flagged through someone else’s activity
  • Carrier-grade NAT, on Starlink and some mobile networks, where you share a public address with other subscribers and can inherit their block
Do not keep retrying. Temporary blocks escalate. More than four temporary blocks within 24 hours upgrades the address to a permanent block, and continuing to retry while blocked is the quickest way to get there.

​
What to send us

Open a ticket with:
  • Your public IP address from ip.me.uk, taken on the affected network. Include every affected address if more than one office or home connection is involved
  • The domain name and the account or registered email address
  • The exact error — the code, message or a screenshot
  • Which services fail and which still work
  • What you have already checked — that you tried mobile data and a private window. This lets us skip the standard questions and go straight to the logs
We cannot tell you which mailbox caused it. The firewall logs the address that failed, not reliably which mailbox or username was being tried. If you do not know what triggered it, say so and we will clear the block — but the device still needs finding, or it will come back.

​
Fix the cause, or it returns

Clearing a block does nothing if whatever caused it is still running. It will be reapplied within hours.
  1. Find the device. Check every phone, tablet, laptop and server that has the mailbox or account configured, including ones nobody uses day to day.
  2. Correct or remove the saved password everywhere, ideally from a password manager so a change propagates at once.
  3. Reset the password if you are not sure what is stored where, and choose a strong one.
  4. Slow your mail clients down. Set them to check every 10 to 15 minutes rather than using push or instant sync. Persistent connection attempts look like automated activity.
  5. Use SSH keys instead of passwords where you can. A key cannot fail a login the way a stale password does.
If your team works from rotating or dynamic addresses and this keeps happening, a corporate VPN with a static outbound address, or a dedicated static IP, removes the cause rather than treating it.

​
Flushing your DNS cache

If the symptom is the site resolving wrongly rather than timing out, your local DNS cache may be stale:
  • Windows — open Command Prompt and run ipconfig /flushdns
  • macOS — open Terminal and run sudo killall -HUP mDNSResponder, then enter your password
  • Any device — switching to a public resolver such as Google Public DNS (8.8.8.8 and 8.8.4.4) or Cloudflare (1.1.1.1) bypasses an ISP cache that is out of date

​
What we can and cannot do

Permanent whitelisting is not available on shared or reseller hosting. Firewall rules are managed server-wide, so we cannot add a standing exception for one account. We can clear a block; we cannot stop the rules applying to you.

​
On an unmanaged server

The firewall is yours, and we cannot see inside your server to check it. Clear the block with whichever tool you installed: Locked out of SSH entirely? Use the HTML5 serial console in the Hosting Panel to reach the command line out of band — see Using the SolusVM control panel.

​
If your IP is not blocked

If we confirm the firewall is clear and you still cannot connect:
  • Test from a completely different network, not just a different device on the same one
  • Disable any VPN or proxy temporarily
  • Check for ISP-level port blocking. If the website loads but FTP (21) and SSH (22) time out from every device on your network, your ISP is likely filtering those ports
  • Run a traceroute (tracert example.com on Windows, traceroute example.com on Mac or Linux) and send us the output. Timeouts at intermediate hops point to a routing problem between your ISP and us, not to your hosting
  • Check your resource usage. If the account has exceeded its CPU, memory or process limits, the web server can stop serving. See Identifying and reducing high disk usage
  • Check for billing suspension. An overdue invoice suspends services and makes every site on the account unreachable