Field note: clearing more than 60,000 blocked IPs across 13 phone systems

Over a few weeks, I worked through the Blocked IPs lists on 13 on-prem Switchvox phone systems. Between them, they’d built up more than 60,000 entries, from under a thousand on one box to over 15,000 on another. Here’s what that job taught me.

If you want the actual method, it’s written up step by step in Clearing a Switchvox blocked IP list from Chrome’s console. This is the story behind it.

Clicking through the web interface crashed a box

The obvious approach was to remove entries through the admin web page. On a list of a few thousand entries, that meant thousands of clicks, and on one system, the sustained load actually took the web service down, more than once.

The fix was to use the phone system’s own API instead: ask it for the list of blocked entries, then remove them one at a time, with a short pause between each. Slow and steady finished the job. Faster, parallel removals were what had overloaded the box in the first place.

First, check whether the list is still growing

Before clearing anything, I looked at two things on each system:

• Was anything open to the whole internet? A long block list usually means something like SIP or the admin login is reachable by anyone. On a couple of systems it was, and I closed that first. Otherwise the list just refills.
• When was the newest entry added? On most of the systems, nothing had been added in months, because access had already been locked down long ago. Those entries were inert history: clearing them was housekeeping, not an emergency.

I also saved a copy of every list before clearing it, so there was a record of what had been blocked and when.

Some boxes were struggling for other reasons

The slow systems taught me the most:

• On most systems, each removal took about a second. On one, each took 6 to 8 seconds, with multi-minute stalls where the whole web interface stopped responding.
• On that same box, the removal rate started around 14 per minute and climbed to nearly 60 per minute partway through, as the system seemed to free up.
• Another system had a heavy load before we started, with pages taking 10 to 20 seconds to load.

After clearing, several systems did seem to run better. But I couldn’t prove the list was the cause. Trunk latency improved on some boxes and not others, and one struggling box had a smaller list than a healthy sibling. So I’d call it “worth doing,” not “a guaranteed fix.”

Scanning continues even with SIP closed

On one system, the list was still growing during the cleanup, even though SIP was already closed to the internet on the phone system itself. More than 700 new entries had arrived over the previous four months, mostly from hosting and VPS networks, and the rate was accelerating.

The takeaway: when you can’t filter traffic on the phone system itself, the fix belongs at the edge, meaning the router or firewall in front of it. That’s where geolocation blocking or tighter rules can stop the scanning before it ever reaches the box.

A browser quirk slowed everything down

This one surprised me. The clearing script ran in Chrome, and whenever its tab was hidden behind other windows, Chrome quietly throttled it and the job crawled. Leaving the developer tools open didn’t reliably help. What worked was keeping that tab visible in front. (Chrome’s flags for native window occlusion and intensive background throttling, and turning off Memory Saver, can also help on Windows.)

What I took away from it

• Fix exposure first. A block list is a symptom.
• Use the API, pace it, and never run it in parallel.
• Save a copy before you clear anything.
• Check the newest entry date to tell active attacks from old history.
• When the device can’t filter, filter at the edge.
• Keep the tab in front when a long-running browser script matters.