I'm blocked, or my site is slow

Two situations land people on this page, and both are usually less alarming than they look:

You suddenly can't reach your site or the control panel — pages time out, or you get a "connection refused", from a network that worked fine a minute ago. BOA may have temporarily blocked your address.
Your site is slow, or flashes a 502 for a moment and then comes back. BOA eases off under heavy load and then picks back up on its own.

The reassuring part: BOA is built to heal itself in both cases. A block is time-limited and usually lifts on its own; a slowdown under load resolves the moment the load drops. Most of the time the right move is to give it a few minutes and try again. Below is how to tell what's happening, the quick checks you can do from your account, and the small number of cases where the answer is a short support request to your host.

"I can't reach my site — I think I got blocked"

BOA runs an automatic abuse-protection layer that watches for the patterns attackers use — repeated failed logins, port scanning, a flood of odd requests. When it sees one of those from an address, it blocks that address for a while. It's the same shield that keeps everyone's sites safe, and now and then it catches a real person by accident.

First: is it actually a block, or is the site down for everyone?

These look similar but need completely different responses, so check this first.

Ask someone else to load your site — a friend, or just your own phone with Wi-Fi turned off (so it's on the mobile network, a different address). Or try a site like isitdownrightnow / downforeveryoneorjustme.
If they can reach it and you can't, it's almost certainly your address that's blocked — the site itself is fine. Read on.
If nobody can reach it, it's not a block on you — the site or the server is having a problem. That's the slow / 502 situation further down this page, or a broken site — see My site is broken.

A block usually hits everything from your address at once — your sites, the Aegir control panel, even your oN.ftp shell may stop responding. That "all of it went quiet together, from this one network" pattern is the tell-tale sign of a firewall block rather than a broken site.

It usually clears itself — wait it out first

Here's the good news, and the first thing to try: these blocks are short and they expire on their own. A typical web-abuse block lasts about 15 minutes, then lifts automatically — you don't have to do anything. A block only becomes long-lived if the same address keeps tripping the protection over and over.

So the simplest fix is almost always the best one:

Stop retrying. Hammering the login page or refreshing over and over can look like more abuse and restart the clock. Step away from it.
Wait about 15 minutes.
Try again from the same network. If you're back in, you're done.

While you wait, it's worth figuring out what set it off, so it doesn't happen again. The usual culprits are the everyday things that look like an attack:

Typing a password wrong several times on your site's login, the control panel, or SSH/SFTP.
An automated tool firing fast from your address — a deploy script, an uptime monitor, a link checker, an aggressive browser extension.
Being on shared or public Wi-Fi where someone else on that network triggered the protection, and you share the same public address.

Slow down the thing that tripped it, and the block won't come back.

If it hasn't cleared, or you're fully locked out

If you've waited well past 15 minutes and still can't get in from that network, or you've retried so many times the block has escalated to a longer one, this is the point to ask for help. Lifting a firewall block is done on the server, and that's not something you can do from your account — there's no command in your shell and no button in the control panel for it, by design. Trying to work around it will only keep the clock running.

Two things get you sorted quickly:

Try a different network in the meantime. Your phone on mobile data, or a different Wi-Fi, is a completely different address and almost always sails right in. That gets you back to work while the block on your original address expires.
Open a support request with your host if you need the block on your main address lifted now. Tell them the address you're coming from (search the web for "what is my IP" from the blocked network, if you can reach it), roughly when it started, and what you were doing when it happened (logging in, deploying, running a tool). With that, lifting the block and, if it makes sense, adding your address to the allow-list is a one-minute job for them.

One handy habit: if you're about to do something that fires a lot of requests — a big deploy, a batch of tasks — keep one working session open in another window first. An address that's already actively and legitimately connected is treated as trusted, so you're much less likely to get shut out mid-job.

"My site is slow, or it flashed a 502 and came back"

BOA actively protects every server from being overwhelmed. When a machine gets very busy — a traffic spike, a heavy crawler, a runaway job somewhere on the box — BOA steps in automatically to keep it from falling over, and then backs off again on its own once things calm down. So a brief slowdown or a 502 that clears by itself isn't a fault you need to chase; it's the safety net doing its job.

What BOA does under load (and why it's temporary)

There are a few levels, and BOA moves up and back down them automatically as load rises and falls:

Busy — BOA tightens up on aggressive web crawlers and bots so real visitors keep getting served. You might notice the site feels a touch slower for a few minutes. Your visitors are fine.
Very busy — BOA briefly pauses the web server to let the machine recover. During those moments a page can return a 502 or simply not load. This is short, and the web server is brought back automatically the moment the load drops back to normal — you don't have to do anything, and nobody has to restart anything.
Extremely busy — on top of pausing, BOA also stops long-running background jobs that are eating the machine, again to protect everyone, and again it recovers on its own.

The thread through all of it: it self-heals. If your site was briefly slow or threw a 502 and is fine again now, that's the system working exactly as intended. There's nothing for you to fix and nothing to report.

The checks you can do

If the slowness sticks around rather than clearing in a few minutes, here are the things you can look at from your own account — no server access needed.

Reload, and give it a minute. BOA caches pages for speed, so one slow load doesn't mean the site is slow. A hard refresh often serves it instantly from cache.
Look at the site's own error log (the watchdog). A site that's genuinely slow or erroring will usually say why in its Drupal log. From your oN.ftp shell:
```
drush @your-site.example.com watchdog-show --count=20
```
Use your site's own alias in place of @your-site.example.com. Recent errors here — a slow database query, a misbehaving module, a flood of a particular request — point you straight at the cause. See Running Drush if you're not sure how to connect or which alias to use.
Check the site through its .dev. URL. Every site can be opened through a special development alias with .dev. in the name (for example www.dev.example.com). Opening the site that way skips the caching and shows PHP errors right on the page, so if the slowdown is really an error hiding behind a cached page, the .dev. view often surfaces it. Open it over http://, not https. The full walkthrough — including how to add a .dev. alias if you don't have one yet, and how it puts errors back on screen — is on My site is broken, which is the right page to work through if the site is actually erroring rather than just busy.
Was it just your site, or all of them? If every site on your account slows or 502s together, that points at the whole machine being busy (the load protection above) rather than any one of your sites. If it's only one site, its watchdog log or its .dev. view is where the answer usually is.

When to open a support request

Reach for your host when the picture is clearly server-side and it isn't clearing on its own:

Every site 502s or is slow for a long stretch and doesn't recover the way a brief load spike would — that suggests the machine is under sustained pressure, which is your host's to look at.
The Aegir control panel itself won't load, not just your sites.
Your site's watchdog log points at something on the server — a service it can't reach — rather than at your own code or content.

When you do, hand your host a short, specific note: which site (or that it's all of them), the exact error (for example 502 Bad Gateway), roughly when it started, and what you already tried (reloaded, checked the watchdog, tried the .dev. URL). That's everything they need to jump straight on it. You don't have to diagnose the server yourself — describing what you saw clearly is the whole job on your side.

My site is broken — the full playbook when a site returns a blank page or an error rather than just being slow, including the .dev. development URL in detail.
When something's wrong — the calm first-stop guide to reading tasks, clearing caches, and telling "yours to fix" from "your host's to fix".
Access control for your sites — the access limits that are yours to set (password-protecting a site, restricting who can reach it), and where the line falls to your host.
Running Drush — connecting as oN.ftp and running the watchdog-show check used above.
Reference — task names, control-file names, and command verbs collected in one place.