NetNut Alternatives: Where to Move Your Traffic Now

Do not take a vendor comparison's word for whether a provider is up, including this one. Comparison pages go stale in days, and this situation has already moved once. Two commands settle it in about ten seconds.

The first asks what the site returns right now:

curl -sI https://netnut.io/ | head -1
curl -s https://netnut.io/ | grep -o '<title>[^<]*</title>'

The second is the one people skip, and it is the more reliable signal. A web page can be changed by anyone who controls the server. Nameservers are recorded at the domain registry, so they tell you who controls the domain itself:

dig +short NS netnut.io

For the full registry record, including when it last changed, query RDAP directly:

curl -s https://rdap.identitydigital.services/rdap/domain/netnut.io \
  | python3 -c "import sys,json; d=json.load(sys.stdin); \
print('ns:', [n['ldhName'] for n in d.get('nameservers', [])]); \
print([(e['eventAction'], e['eventDate']) for e in d.get('events', [])])"

Here is what those queries returned for us on 1 September 2026. Every row is an observation from that morning, not a claim about what will be true when you read this. Run the commands above and trust your own output over this table.

One row on that list matters more than the rest for anyone with a running scraper. ntnt.io is the domain that carried NetNut gateway hostnames, including gw.ntnt.io. If your proxy configuration points at a gw.ntnt.io address rather than at anything with "netnut" in it, that is the hostname your code is failing to reach, and it is why some teams spent a day debugging their own networking before they checked the vendor.

Worth knowing for next time: this is a general technique, not a NetNut one. dig +short NS against any supplier you depend on is a five second health check that catches a class of failure your uptime monitoring will report only as timeouts.

Being precise here protects you as much as it protects anyone else, because migration decisions made on rumour tend to be expensive.

What we observed directly: the HTTP responses and registry records in the table above, on 1 September 2026, from our own network. That is the whole of our first-hand knowledge.

What other organisations have published, attributed to them: Alarum Technologies, NetNut's parent company, said in a press release dated 3 July 2026 that on 2 July 2026 it and its subsidiary "became aware that certain domains associated with NetNut had been seized", that it was "currently experiencing disruptions to a portion of its services", that continued disruption would be "likely to have a material adverse effect on the Company's operations", and that as of that date neither it nor NetNut "has been formally contacted by the FBI or any other governmental or regulatory authority". Google's Threat Intelligence Group published its own assessment on 3 July 2026 in a post on Google's threat intelligence blog. Independent reporting appeared at Krebs on Security and Infosecurity Magazine.

What we are not doing: we are not summarising any charging document, describing any court finding, naming any individual, or taking a position on anyone's conduct. Statements by Google and by Alarum are those organisations' statements, and Alarum's release describes an investigation it was itself conducting. Nothing here should be read as a finding of wrongdoing by anybody.

What we are also not doing: using any of this as a sales argument. A supplier going dark is a bad week for the engineers who depended on it, and several of the alternatives named below compete directly with us. The useful thing we can offer is an accurate map, so that is what the rest of this page is.

This is the question that decides everything else, and a surprising number of teams have to go and look at an invoice to answer it.

An archived snapshot of the NetNut site dated 22 June 2026 lists six lines: Rotating Residential Proxies, Static Residential (ISP) Proxies, Mobile Proxies, Datacenter Proxies, a Website Unblocker, and Scraper APIs including a SERP API. The same snapshot published network figures of 85M+ residential IPs across 195+ countries. Those were the vendor's own marketing claims as archived on that date. They are not current facts and we did not measure them.

Read that table honestly and most NetNut invoices turn out to be dominated by the top three rows, which is the part of the market SparkProxy is not in. The static residential line in particular was the product NetNut was best known for, and swapping it for datacenter proxies is not a like-for-like move. It is a different network type with a different detection profile, and pretending otherwise would just waste your sprint. If the distinction is fuzzy, our comparison of residential, datacenter and mobile proxy types lays out what each one is actually made of.

Here is the part that catches people, and it is the reason this page exists in the shape it does rather than as a feature grid.

In its 3 July 2026 post, Google's Threat Intelligence Group wrote that "NetNut has a robust reseller program that allows whitelabeling of its network" and that "Google has high confidence that many popular residential proxy brands are in fact whitelabeling the NetNut botnet." That is Google's assessment, published in Google's own words, and we are quoting rather than endorsing it.

The operational consequence stands regardless of how you weigh the assessment: a residential proxy pool you buy under one brand may not be that brand's own network. Proxy supply chains have upstreams, and buyers almost never ask about them. So if your residential proxies degraded in July or August and your vendor is not NetNut, the vendor relationship you have may not be the infrastructure relationship you have.

You can test the shape of your own supply chain without any vendor cooperation. Sample your exits and look at who owns them:

import json
import os
import requests

# Point this at whichever provider you are auditing.
PROXY = os.environ["PROXY_URL"]

seen = {}
for _ in range(200):
    ip = requests.get(
        "https://ipinfo.io/json",
        proxies={"http": PROXY, "https": PROXY},
        timeout=30,
    ).json()
    org = ip.get("org", "unknown")
    seen[org] = seen.get(org, 0) + 1

for org, count in sorted(seen.items(), key=lambda kv: -kv[1])[:15]:
    print(f"{count:4d}  {org}")

What you are looking for is concentration. A pool advertised as tens of millions of consumer IPs that returns a handful of the same organisations across 200 samples is telling you something about its real breadth. A pool that returns hosting and cloud ASNs when you paid for residential is telling you something louder. Our explainer on what a datacenter ASN is covers how to read those org strings and why the ASN, not the marketing label, is what a target site actually scores.

Then ask the vendor directly, in writing. The questions are in the due diligence section below. A vendor that will not name its upstreams in writing has answered you.

Plainly, so nobody wastes an afternoon on a trial that was never going to work.

SparkProxy sells rotating datacenter proxies and a Scraping API. We do not sell residential, ISP, or mobile proxies, and we do not sell static addresses you keep. If NetNut's static residential product is what your workflow depends on, we cannot replace it, and the alternatives table names vendors who can. That is not modesty, it is the actual product boundary, and a datacenter IP will not pass a check designed to spot one no matter whose logo is on the invoice.

Where we do fit: the datacenter line, and a fair amount of work that was running on residential purely because that is what the team happened to buy first. The pool is published at 1M+ IPs across 80+ countries, sold by concurrent thread rather than by gigabyte, with unlimited bandwidth and no overage. Country-level geo targeting, not city or ASN level. There is a 24-hour trial that does not ask for a card, which is enough to run your real target list rather than a demo URL, and given the week you are having, running your own targets is the only test worth anything.

One hostname, three ports:

# Rotating pool, a fresh exit IP per request
curl -x http://USER:PASS@gateway.sparkproxy.io:11000 https://ipinfo.io/ip

# Sticky exit, the same IP held for the session window
curl -x http://USER:PASS@gateway.sparkproxy.io:11002 https://ipinfo.io/ip

# SOCKS5 for tools that prefer it (TCP only, no UDP relay)
curl -x socks5h://USER:PASS@gateway.sparkproxy.io:13000 https://ipinfo.io/ip

If the line you are replacing is the Website Unblocker rather than raw proxies, the closer equivalent is the managed SparkProxy Scraping API, which handles rotation, rendering and stealth behind one call. It returns pages, not parsed fields, so it is not a drop-in for a SERP API that gave you structured results.

Two things we deliberately do not offer, because you will hit them in week one otherwise: a fixed address you can allowlist on your own systems (covered in shared vs dedicated datacenter proxies), and geo targeting below country level.

This is the section that saves the most time, because "can this run on datacenter?" has a real answer per workload rather than a general one. The deciding factor is almost always whether the target scores the network type of the connecting IP, and how harshly.

The pattern worth internalising: datacenter tends to work where the target cares about volume, and fails where the target cares about who you look like. Roughly the top half of that table is where a large minority of teams discover they were paying residential prices for work that never needed it. The bottom half is where migrating to datacenter produces a week of confusing 403s and a rollback.

So split your target list before you buy anything. Run the easy half through a datacenter trial, keep the hard half on a residential vendor from the next section, and accept that you may end up with two suppliers rather than one.

Vendors are grouped by what they actually sell, since that is the axis that matters here. This is a shortlist to start from, not a ranking, and we have not measured any of these networks.

On pricing, deliberately. There are no prices in this article. Every vendor here reprices, runs promotions and moves tier boundaries, and a figure copied into a blog post in August misleads somebody in October. Price your own workload on each vendor's current page on the day you buy. If the underlying billing models are unfamiliar, we wrote them up in understanding datacenter proxy pricing models.

On urgency and contracts. You are negotiating from a weak position this month, and vendors know a wave of migration is happening. That is an argument for a short commitment now and a considered one in November, not for signing an annual deal in the first 48 hours because a salesperson was responsive.

Standard migration advice says to overlap contracts for a billing cycle and A/B the two vendors. That advice assumes the old vendor still answers. When it does not, the playbook changes.

1. Fail fast instead of retrying. Retry and backoff logic built for transient errors will happily burn hours against a gateway that is not coming back, and on some plans it will burn quota too. Add a circuit breaker that trips the whole proxy layer after N consecutive connection failures rather than retrying per request.
2. Reconstruct your baseline from logs, not from a live run. You cannot A/B against a vendor that is down. Pull success rate, median latency and bytes per record from the last known good week in your own logs. Without that number you will not be able to tell whether the replacement is worse or your targets simply changed.
3. Split the target list by defence level first. Send the easy half to a datacenter trial and the hard half to a residential vendor. Migrating everything to one replacement because one replacement is simpler is the most common mistake in an unplanned move.
4. Change one variable. Do not ship a parser rewrite or a concurrency change in the same deploy as the vendor swap. In a rushed migration this discipline is more important, not less, because you have less time to debug a confound.
5. Re-register IP allowlists early. Allowlist changes are not always instant at a new vendor, and this is the step that most often adds a day. If your scraper runs anywhere with a changing egress address, switch to user and password auth for the migration.
6. Re-verify geo and session syntax explicitly. Country targeting and session identifiers are expressed differently by nearly every vendor. A silently ignored country flag returns data that looks perfectly fine and is wrong, which is worse than an error.
7. Preserve your records before you close the account. Invoices, contract terms, and your own usage logs. Whatever happens with billing, prepaid balances or accounting for the disruption, you will want the evidence, and it gets harder to retrieve later.

The code change itself is usually small, provided the proxy string lives in one place:

import itertools
import os
import requests

USER = os.environ["PROXY_USER"]
PASSWORD = os.environ["PROXY_PASS"]

# The one line that changes when you switch vendors.
PROXY = f"http://{USER}:{PASSWORD}@gateway.sparkproxy.io:11000"

session = requests.Session()
session.proxies = {"http": PROXY, "https": PROXY}

failures = itertools.count()
for url in targets:
    try:
        resp = session.get(url, timeout=30)
        failures = itertools.count()          # reset the breaker on success
    except requests.exceptions.ProxyError:
        if next(failures) > 20:               # gateway is down, not the target
            raise SystemExit("proxy layer unreachable, stopping")
        continue

If that string appears in more than one place in your codebase, fix that first. It is the cheapest work in the whole migration, and this month has been a decent argument for why it matters.

Send these in writing, to whoever you are about to buy from, including us. A vendor's willingness to answer in writing is itself most of the signal.

1. Where does your exit pool come from? Name the mechanism, not the adjective. "Ethically sourced" is not an answer; "leased ranges from named hosting providers" or "an opt-in SDK in consumer apps" are answers.
2. Do you resell or white-label any upstream network? If yes, which ones, and what happens to my service if an upstream is disrupted?
3. If any part of the pool comes from consumer devices, what does the consent flow look like? Ask to see the actual disclosure a device owner sees, not a policy page describing it.
4. What is your process when a customer is found abusing the network? A vendor with no answer has no process.
5. What data do you retain about my requests, for how long, and what would you produce under legal process?
6. What is the notice period and refund position if service becomes unavailable? Ask before you need it, because that is the only time you will get a straight answer.

There is a structural point here that we would rather state plainly than imply. Question three does not apply to datacenter proxies at all, because the addresses are leased from hosting providers and announced by identifiable ASNs rather than sourced from anybody's home devices. That is not a claim that datacenter is better. It is worse than residential at looking like a real user, which is the entire reason residential exists and a large part of why people bought NetNut. It is simply a different supply chain with a different set of questions attached, and knowing which set applies to you is the point.

• Today: dig +short NS your vendor's domain, and trip a circuit breaker so your scrapers stop hammering a dead gateway.
• Day one: reconstruct the baseline from logs. Split the target list into "cares about volume" and "cares about who you look like".
• Day two: start a datacenter trial for the first half and a residential trial for the second, on your real targets.
• Day three: measure success rate, median latency and bytes per record, per target, per vendor. Keep the numbers.
• Day four: migrate the easy half. Leave the hard half until the measurements say something.
• This month: short commitments only, and send the due diligence questions to everyone on the shortlist.
• Next quarter: decide whether one vendor or two is the right shape, with data rather than under pressure.

The habit worth keeping after the dust settles is the boring one from step one. A dependency you cannot survive losing deserves a health check that runs without you thinking about it, and an answer to "what do we do if this vendor disappears on a Tuesday" that predates the Tuesday.