Quick context if you haven't seen this yet: on July 2, 2026, the FBI and IRS Criminal Investigation division seized domains tied to NetNut, a major residential proxy provider. If any part of your scraping/automation stack points at NetNut endpoints, this is a "fix it this week" problem, not a "read about it later" one.
What actually happened (worth knowing before you migrate)
This wasn't a routine outage. Per reporting from Krebs on Security, Google's Threat Intelligence Group (GTIG), and independent researchers (Synthient, Qurium), NetNut's residential proxy network has been linked to a botnet tracked as "Popa" — roughly two million consumer devices (mostly smart TVs and streaming boxes) that were enrolled as proxy exit nodes without meaningful user consent, via SDKs bundled into apps.
GTIG reported observing 316 distinct threat clusters using suspected NetNut exit nodes in a single week in June 2026, including both cybercriminal and espionage activity — things like password spraying and disguising unauthorized access. Alarum Technologies (Nasdaq: ALAR), NetNut's parent, confirmed awareness of the seizure and said it would cooperate with investigators.
One detail worth flagging for anyone doing infra planning: the seizure initially hit netnut.com and a few related domains (proxyjet.io, divinetworks.com), while netnut.io reportedly stayed live for a period afterward — a reminder that "the provider got seized" doesn't always mean "100% of their infrastructure is down," which complicates any assumption you might make about failover behavior.
This also isn't an isolated incident — Google's takedown explicitly follows their January 2026 disruption of IPIDEA, NetNut's largest competitor, and GTIG has said they expect displaced demand to shift toward other providers in the ecosystem rather than the market shrinking outright.
Practical takeaway: when evaluating your next residential proxy provider, "how do you source your IP pool, and do end users consent to being a node" is now a reasonable technical due-diligence question, not just a compliance nicety.
Migration checklist
Before picking a replacement, inventory what you were actually doing with NetNut:
[ ] Rotating residential proxies for scraping
[ ] Sticky/static sessions for logged-in workflows
[ ] Mobile-targeted proxies
[ ] Datacenter/IPv6 for high-volume, low-risk jobs
[ ] Specific city/region geo-targeting requirements
[ ] SOCKS5 vs HTTP/HTTPS requirements in your current tooling
Match each item to a provider capability — don't force everything through one proxy type just because that's how your old setup was wired.
Provider options and what they're actually good for
| Provider | Type | Best for | Notes |
|---|---|---|---|
| Nstproxy | Residential (Lite/Prime), Static ISP, Mobile, Datacenter, IPv6 | Mixed workloads needing more than one proxy type | Single dashboard/API across proxy types, useful for staged migration |
| Oxylabs | Residential + scraping tools | Enterprise-scale scraping | Large pool, higher cost, enterprise contracts |
| Bright Data | Residential, ISP, Mobile, Datacenter | Advanced/enterprise data ops | Broad product surface, steeper setup |
| ScrapingBee | Scraping API | "Just get me the rendered HTML" workflows | Handles rotation/rendering for you; not raw proxy access |
| Zenscrape | Scraping API | Similar to ScrapingBee | Good if you don't need proxy credentials directly |
| SOAX | Residential + Mobile | Precise geo-targeting | Strong filtering, costs scale with usage |
| IPRoyal | Residential | Budget/small teams | Cheaper entry point, test before scaling |
| NodeMaven | Residential | NetNut migrators specifically | Newer brand — apply the same vetting as anything else |
Swapping proxy config: minimal example
Most providers use a similar host:port + user:pass pattern, so migration at the code level is usually a config change, not a rewrite — assuming you abstracted your proxy config in the first place. If you didn't, now's a good time to.
# proxy_config.py — centralize this so provider swaps are a one-line change
import os
PROXY_HOST = os.environ["PROXY_HOST"] # e.g. gate.provider.com
PROXY_PORT = os.environ["PROXY_PORT"] # e.g. 7000
PROXY_USER = os.environ["PROXY_USER"] # encodes session id / geo target
PROXY_PASS = os.environ["PROXY_PASS"]
def proxy_url():
return f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
def get_proxies():
return {"http": proxy_url(), "https": proxy_url()}
# usage — provider-agnostic as long as env vars are updated
import requests
from proxy_config import get_proxies
resp = requests.get("https://example.com", proxies=get_proxies(), timeout=15)
To migrate, you change four environment variables and re-run your test suite against a small batch before touching production volume:
export PROXY_HOST="gate.newprovider.com"
export PROXY_PORT="7000"
export PROXY_USER="user-session-abc123-country-DE"
export PROXY_PASS="your_password"
python3 -c "
import requests
from proxy_config import get_proxies
r = requests.get('https://ipinfo.io/json', proxies=get_proxies(), timeout=10)
print(r.json())
"
Confirm the returned country/org fields match expectations before scaling.
Session strategy by workflow
Scraping / data collection: rotating residential proxies, retry + backoff logic, rotate user-agents alongside IPs. This part of your setup should port over to almost any provider with minimal change.
Account-based workflows: sticky residential or static ISP proxies. If you were relying on NetNut's static IP offerings for long-lived sessions, prioritize a provider with an explicit static ISP product (Nstproxy and Bright Data both have one) over one that only offers rotating residential.
SEO/SERP monitoring and ad verification: verify city/region targeting claims against real requests — don't trust the country dropdown in the dashboard. Run the ipinfo.io check above for every new region you add.
Mobile-first targets: if mobile trust signals mattered in your old setup, check whether the replacement offers actual carrier-assigned mobile IPs, not just "mobile user-agent" residential IPs — these are not the same thing and behave very differently against strict targets.
A note on due diligence going forward
Given what triggered this migration, it's worth asking any new provider a few direct questions before committing volume:
- How is your residential IP pool sourced — direct ISP partnerships, opt-in bandwidth-sharing apps, or something else?
- Is there a public consent mechanism for devices/users contributing IPs?
- Have you been named in any security research (Krebs, GTIG, Spur, Synthient, etc.) connecting your network to botnet activity?
None of this is meant to imply every residential proxy company has the same problem NetNut did — plenty operate through legitimate opt-in panels and ISP partnerships. But "ask where the IPs come from" is now a reasonable line item in your vendor evaluation, not paranoia.
Wrap-up
If you're migrating off NetNut, treat it as an opportunity to decouple your workflows from a single proxy type rather than just swapping one vendor for a like-for-like replacement. Centralize your proxy config if you haven't, test small before scaling, and add "how do you source your IPs" to your vendor questionnaire — this month made it relevant for the whole industry, not just NetNut.
Top comments (0)