Proxy Concepts

Subnet Bans: What They Are and How to Diagnose Them

A subnet ban filters a CIDR range, not just one address. Changing IPs inside the same /24 changes nothing.

Field notes Range diagnostics Updated 2026-06-12

Subnet ban is not the first diagnosis

A scrape fails, someone says the range is burned, and later the real cause turns out to be a retry loop, stale login state, a browser profile that changed shape, or a target template update that made the parser save nothing. Check the boring causes first. Subnet is worth investigating only after those are ruled out.

A subnet ban means the target is filtering an IP range rather than a single address. In IPv4 (RFC 791), a /24 covers 256 addresses; a /23 covers 512. If the blocked range is 203.0.113.0/24, then 203.0.113.17 and 203.0.113.91 are two different exit IPs inside the same CIDR block. Rotating between them changes nothing. That distinction sounds fussy until the dashboard shows you swapped IPs and the target responded identically.

Test one route before scaling. If the result is bad at low volume, scaling only hides which part failed and makes the provider meter harder to read.

Log columns that expose a range problem

The columns worth keeping: exit IP, subnet, ASN, owner, target, HTTP status, body size, saved rows, latency, retries, and provider-metered bytes. That is more columns than feels comfortable. Keep them anyway, because a status-only view hides too much.

A 200 with a 2 KB body on a page that normally returns 80 KB is a block page, not a success. An app-level dashboard that counts saved rows can look quiet while the provider meters redirects, retries, challenge pages, and dead attempts. During a subnet problem, saved rows fall while billed traffic climbs. If the report does not include provider-metered bytes, the first honest number is the invoice.

Keep subnet and ASN in separate columns. Subnet is the range. ASN is the routing owner — each ASN is a unique number assigned by IANA and listed in the IANA AS Number Registry. One bad /24 under a specific owner does not make every route under that owner bad. One noisy residential sample does not indict every residential exit. A provider refusing a category is provider policy, not a subnet ban — it belongs in a different column. Mixing those buckets causes people to change the wrong thing.

Pool size does not equal range diversity

More IPs can still mean poor subnet spread on one target. Datacenter pools show it quickly because allocations are often contiguous blocks. Residential traffic can bunch too. Volume Residential at $0.89/GB gives cheaper coverage with more address noise. Premium Residential at $5.00/GB tends toward cleaner selection but does not cancel target-side scoring. Static ISP is useful when a workflow needs a stable identity, and that same stability concentrates exposure to one range over time.

The right question is not whether the provider has a large pool in the abstract. The right question is which ranges touched this specific target. If the good rows and bad rows are spread across unrelated CIDRs, subnet is probably not the main story. If bad rows keep landing in the same /24 after every rotation, stop treating the pool count as meaningful for that job.

The Proxynade dashboard network logs show host, outcome, latency, and byte totals per request. Export the usage log as CSV and group by the first three octets of the exit IP. If failures cluster in one group and successes are elsewhere, the pattern is visible without guessing.

Fix one variable at a time

When the pattern shows up, do not fix three things at once. Pull the failing /24 from the sample and compare a different range against the same target with the same client. If Volume Residential burns bandwidth on small bodies and retries, compare Premium Residential before touching parser code. If a Static ISP range starts failing, move that workflow to a different range or let the original range cool rather than pushing harder into it. With datacenter, keep batches small — clustered failures usually surface faster at lower volume.

Some subnet bans fade within hours. Some persist long enough that the practical answer is to keep that range cold for that target. There is no need to model why the target made its decision. The goal is a run that returns one clear signal, and one bad range that stops dragging metered bytes into waste.