AI support for blocked IPs and firewalls
How Panelbot diagnoses "it works on my phone but not here" by checking whether the customer's connection is blocked or the account suspended.
Updated
Blocked access and firewall issues
“It works on my phone but not on my laptop” is one of the most confusing tickets a customer can send, because from their side nothing has changed. The same site, the same login, the same password, and yet one device gets in and another does not. The usual cause is that the customer’s own connection has been shut out by a protective rule, often after a run of failed logins from a stale saved password. Panelbot works out whether that is what happened, and either clears the block or tells your team exactly what it found.
What your customers report
Access complaints tend to arrive in forms like these:
- “Your website works on my phone but not on my home internet.”
- “I suddenly cannot reach my site or my webmail, and it was fine this morning.”
- “The page just times out, but my friend can open it.”
- “I keep getting connection refused from my office.”
- “I think I have been locked out of the server.”
The customer almost never realises that the problem is specific to their connection rather than the site being down for everyone. Panelbot starts from that possibility instead of taking “the site is down” at face value.
How Panelbot looks into it
Panelbot runs read-only checks that describe the situation without changing anything. In plain terms, it is confirming:
- Whether the customer’s own connection has been blocked. Repeated failed logins, often from an old password saved on one device, can cause the server’s protective measures to shut that connection out automatically. To the customer this feels exactly like the site or mailbox breaking, when in fact everyone else can reach it fine.
- Whether the account itself is suspended. An account can be held for billing or policy reasons, which looks like an outage to the customer but is a very different situation with a very different fix.
- Whether a protective rule is involved. Some blocks come from the security measures that guard the server against abuse. Panelbot identifies when one of those is the reason a legitimate customer has been caught, so the response addresses the real cause rather than guessing.
These checks give Panelbot the evidence to name what is actually happening, which is frequently a legitimate customer swept up by a protective rule rather than anything wrong with the site.
What it can fix, and what needs your approval
When the cause is a legitimate customer connection that got blocked by too many failed logins, and you have enabled action-taking for your account, Panelbot can offer to:
- Identify what triggered the block, so the fix addresses the actual source.
- Clear the block so the customer can connect again.
Panelbot pairs the unblock with guidance to correct whatever caused it, such as a stale saved password on a phone or a second device, because an unblock that skips the underlying trigger treats the symptom and not the cause, so the same protective rule fires again before long. Any such step is presented for you or the customer to confirm, never taken silently, and it is scoped to the specific connection involved. If action-taking is turned off, Panelbot still identifies exactly what happened and how to resolve it, and leaves the actual unblock for your team to carry out.
What each unblock needs on your server
Firewalls guard the whole server, so what Panelbot can check and clear depends on how the server is connected:
- CSF and Imunify360 IP unblocks need the agent. Unblocking a customer’s IP in CSF or Imunify360 without the agent is not available today; IP unblocks run through the optional agent, on cPanel and DirectAdmin, whether the server is connected with a reseller credential or a root WHM token. Your server’s capability list may show the two IP-unblock rows as available when the upstream host has granted the CSF or Imunify360 reseller plugin; Panelbot does not unblock through that grant today, so treat those two rows as agent-only until this page says otherwise. See Reseller, VPS, and dedicated support.
- A root WHM token or the agent (cPanel) covers clearing cPHulk brute-force blocks and listing everything the firewall is blocking.
- The agent is also needed to read the LFD block log.
Without the right access on a server, Panelbot still works out whether a block is the cause where it can, then hands the unblock to your team. With and without the agent has the full list.
When a human takes over
Some blocks are not safe to clear automatically, and Panelbot is deliberately conservative here. It brings in your team when the evidence points to situations like these:
- The account is suspended for billing or policy reasons, which is a decision for your team, not something an assistant should reverse.
- The block looks like it is protecting the server from genuine abuse rather than catching a legitimate customer by mistake.
- The pattern does not match a known, safe-to-clear cause, so reopening access could do more harm than good.
Whenever it escalates, the customer is told plainly that a real person on your team has been alerted, and your staff inherit the context Panelbot has already collected. It clears the everyday lockouts that are genuinely safe to clear, and it treats anything that could be a real security concern as a human’s call. That boundary is intentional, because reopening the wrong door is worse than a short wait.
See it in action
Real conversation flows through the widget, on a sample account under the fictional Vornalis Hosting brand. Nothing loads until you press play.
All 28 scenarios are in the video demo library.
Related guides
- Email account and login issues for lockouts that show up specifically in a mail app.
- Websites down or showing errors when the site really is down for everyone rather than blocked for one person.
- When a human takes over for how escalation reaches your team.
- Safety and permissions for how ownership and approvals gate every action.