DEV Community: Proxy Universe

How to Verify Proxy Quality Before You Buy: Latency, Anonymity & Geo Accuracy

Proxy Universe — Tue, 04 Aug 2026 08:51:40 +0000

Most proxy providers publish numbers you cannot verify. This is a practical walkthrough for checking latency, anonymity level, geo accuracy and pool depth yourself — using public endpoints and a small Python script — so you evaluate a pool on evidence instead of a pricing page.

How to Verify Proxy Quality Before You Buy: Latency, Anonymity & Geo Accuracy

Every proxy provider publishes the same three claims: huge pool, high success rate, global coverage. None of them are verifiable from the outside, and all of them are true in the sense that a used car "runs."

The good news is that the things that actually matter are measurable in about fifteen minutes with a small script and a minimum top-up. This post walks through what to measure, why each metric matters, and how to read the output.

What actually matters

Four measurable properties tell you almost everything about a pool's usefulness:

![Four measurable proxy metrics: latency, anonymity level, geo accuracy, pool depth — and what each one tells you
Four metrics, four different failure modes. Measure all four — any one of them alone is misleading.

Latency — round-trip time through the proxy. Residential routing adds real overhead; anything under 1s to a nearby endpoint is healthy, 1–3s is workable for batch jobs, consistently above 3s will wreck any interactive workflow.

Anonymity level — whether the proxy forwards headers that reveal it's a proxy at all. X-Forwarded-For, Via, and friends. A proxy that announces itself defeats the purpose.

Geo accuracy — whether the IP is actually where the dashboard says it is. Registry data and physical routing disagree more often than you'd expect, and CDN-served content is regional, so a mismatch silently corrupts collected data.

Pool depth — how many distinct IPs you actually get for a given location. A provider can support a country with forty usable addresses in it. That's technically true and operationally useless.

The script

Nothing exotic — requests and the standard library. It pulls each proxy from a list, measures round-trip time, checks which headers arrive at the other end, and resolves geo from a public IP-intelligence endpoint.

import time
import requests
from collections import Counter

# Public endpoints that echo what the other side sees.
ECHO = "https://httpbin.org/get"
GEO = "https://ipinfo.io/json"

# Headers that reveal a proxy is in the path.
LEAK_HEADERS = {"X-Forwarded-For", "Via", "X-Real-Ip", "Forwarded", "X-Proxy-Id"}


def check(proxy_url, timeout=10):
    """Measure one proxy: latency, header leaks, exit IP and geo."""
    proxies = {"http": proxy_url, "https": proxy_url}
    result = {"proxy": proxy_url, "ok": False}

    try:
        start = time.perf_counter()
        r = requests.get(ECHO, proxies=proxies, timeout=timeout)
        result["latency_ms"] = round((time.perf_counter() - start) * 1000)
        r.raise_for_status()

        seen = set(r.json().get("headers", {}))
        result["leaks"] = sorted(LEAK_HEADERS & seen)

        g = requests.get(GEO, proxies=proxies, timeout=timeout).json()
        result["ip"] = g.get("ip")
        result["city"] = g.get("city")
        result["country"] = g.get("country")
        result["org"] = g.get("org", "")
        result["ok"] = True
    except Exception as exc:
        result["error"] = f"{type(exc).__name__}: {exc}"

    return result

![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/4m0npqy6rfl80uc8akfi.png)

def report(proxy_list, expect_country=None):
    rows = [check(p) for p in proxy_list]
    alive = [r for r in rows if r["ok"]]

    print(f"alive: {len(alive)}/{len(rows)}")
    if not alive:
        return rows

    lat = sorted(r["latency_ms"] for r in alive)
    print(f"latency ms  min={lat[0]}  median={lat[len(lat)//2]}  max={lat[-1]}")

    unique_ips = len({r["ip"] for r in alive})
    print(f"unique exit IPs: {unique_ips} (from {len(alive)} working proxies)")

    leaking = [r for r in alive if r["leaks"]]
    print(f"header leaks: {len(leaking)}")
    for r in leaking:
        print(f"   {r['ip']} leaks {r['leaks']}")

    if expect_country:
        wrong = [r for r in alive if r["country"] != expect_country]
        print(f"geo mismatch: {len(wrong)} expected {expect_country}")
        for r in wrong:
            print(f"   {r['ip']} -> {r['country']} / {r['city']}")

    print("top networks:", Counter(r["org"] for r in alive).most_common(3))
    return rows


if __name__ == "__main__":
    # user:pass@host:port — one entry per proxy you want to evaluate
    pool = [
        "http://user:pass@proxy.example.net:8000",
        "http://user:pass@proxy.example.net:8001",
    ]
    report(pool, expect_country="US")

Two notes on running it:

Test sequentially first, not concurrently. Concurrency hides per-proxy latency in queue time and you'll misread the numbers.
Run it twice, an hour apart. A pool that looks great once and degrades on the second pass is telling you something important about peer churn.

Reading the results

The raw numbers are less interesting than the patterns they form.

![How to interpret proxy test results: healthy pool versus warning signs across latency, unique IPs, leaks and network diversity
The same four metrics, read as signals. Patterns matter more than individual values.

Unique exit IPs well below the number of proxies tested. You're being served a thin slice of the pool. Ten proxies returning three distinct IPs means you're effectively buying three IPs.

Any header leak at all. Non-negotiable. This is a configuration property of the provider's edge, not something you can patch client-side.

org field showing hosting providers. If the organisation behind your "residential" IPs is a cloud host or a datacenter ASN, the label is wrong. Real residential IPs resolve to consumer ISPs — the kind of names that show up on home broadband bills.

Wide latency spread with a low median. A median of 400ms with a max of 9s means a minority of peers are effectively dead. That tail is what causes mysterious timeouts in production, and it never appears in a provider's advertised average.

Country correct, city consistently wrong. Registry drift. Fine if you only need country-level targeting; disqualifying if your task is city-specific.

What to do with a bad result

Don't tune around it. If a pool leaks headers, serves datacenter ASNs under a residential label, or gives you six unique IPs out of twenty, that's structural — a bigger plan buys more of the same thing.

The practical strategy is to make switching cheap:

Test on the smallest purchase possible — providers that force large upfront commitments make you rationalise their flaws.
Prefer traffic that doesn't expire, so an unused balance from a failed test isn't a sunk cost pushing you to keep using a bad pool.
Keep two pools available behind one config abstraction. 2026 killed several well-known proxy services with prepaid balances still on them — single-supplier setups went down with them.

Try it yourself

Run the script against whatever you're using now. Then run it against something else and compare — the numbers will make the decision for you, which is a much better position than choosing between two marketing pages.

If you want a pool to test it against without a monthly commitment, that's what we built ProxyUniverse for: residential, mobile, static ISP and dedicated IPv4 across 10+ networks on a single balance, pay-as-you-go, traffic that never expires. Buy the minimum, run the checks, decide with data.

If you extend the script — concurrency handling, TLS timing, retry curves — drop it in the comments. I'd like to turn this into a proper little tool.

The 2026 Proxy Purge: What Really Happened to 922, PIA S5 and LunaProxy

Proxy Universe — Sat, 01 Aug 2026 10:04:39 +0000

The 2026 Proxy Purge: What Really Happened to 922, PIA S5 and LunaProxy

If you run scraping pipelines or multi-account infrastructure, your Twitter feed in 2026 has looked like an obituary column: 922Proxy — dead. PIA S5 — client shut down. LunaProxy, PyProxy, IP2World, 360Proxy — domains not even resolving.

This wasn't a coincidence, and it wasn't a market downturn. Here's what actually happened, verified from registry data and public threat-intelligence reports — and what it means for anyone whose infrastructure depends on residential proxies.

One takedown, many brands

In January 2026, Google's Threat Intelligence Group disrupted the network behind IPIDEA. What most users never knew: IPIDEA wasn't one provider. Analysts published a list of affiliated brands, and it reads like the entire budget-S5 aisle: 922Proxy, 360Proxy, LunaProxy, PIA S5, ABCProxy, IP2World and more.

These "different providers" with different logos, different dashboards and different Telegram support channels were, at the infrastructure level, largely one pool. When the core got disrupted, the storefronts died together. We ran DNS checks across the brand list in July 2026: 922proxy.com, 922s5.com, lunaproxy.com, pyproxy.com, abcproxy.com — NXDOMAIN, all of them.

The zombie-brand problem

Here's where it gets dangerous. The demand didn't die with the brands — Google autocomplete still suggests "s5 proxy 922" as the top completion for "s5 proxy". That orphaned demand attracts predators:

Clone sites registering hyphenated or swapped-TLD variants of dead brands, selling "the same service" through a lookalike dashboard. We found several already ranking. Before you trust a "revived" brand, check the domain's registration date via RDAP — a "10-year-old provider" on a domain registered in March 2026 is not the provider you knew.
Balance-recovery scams targeting users whose prepaid IPs got locked inside dead clients.

The 9Proxy scare — a different story

9Proxy went dark on June 28, 2026 and the community immediately filed it under "seized like the rest". The registry data never supported that: routine registrar lock, nameservers untouched, domain paid through 2027. It came back in mid-July — an unexplained outage, not a takedown. Different failure mode, same lesson: you can't tell an outage from a seizure from the inside, and your balance is hostage either way.

Engineering takeaways

Treat proxy providers like any other third-party dependency. Two suppliers minimum, health-checked, with traffic you can shift in minutes. If your scraper has retry logic but your proxy layer has a single vendor, you've just moved the SPOF.
Prefer non-expiring, pay-as-you-go balances. Subscriptions and time-boxed GB packs maximize your loss in a shutdown. Non-expiring GB means your exposure is only what you haven't burned yet.
Buy through channels with conversion paths. PIA S5's desktop client died, but the network's GB API kept working — users who bought per-IP through the client got stuck; users on the API just kept going. When we route customers at ProxyUniverse, we now explicitly prefer API-deliverable products for exactly this reason.
Vet suppliers with registry data, not marketing. RDAP is free. Domain age, registrar history, nameserver stability — five minutes of checking beats a locked balance.

The uncomfortable conclusion

The budget residential proxy market runs on infrastructure whose ownership you can't audit, sold through brands that are sometimes just skins. That's not a reason to avoid it — the economics are unbeatable for a lot of legitimate work — but it is a reason to architect for provider death as a routine event, not an exception.

The next purge will come. The only question is whether your pipeline notices.

I aggregate and monitor a dozen residential networks at ProxyUniverse — one panel, per-GB pricing, no subscriptions. If your provider died this year, the catalog is a decent place to rebuild from.

80 Lines of Python That Keep My Scrapers Alive: Proxy Rotation with Retries, Health Checks & Failover" published: false

Proxy Universe — Sat, 25 Jul 2026 11:07:27 +0000

Rotating proxies is easy. Surviving bans, timeouts and dead proxies is not. An 80-line Python rotator with health tracking and failover — copy-paste ready

TL;DR: Rotating a list of proxies is easy. Rotating them without your scraper dying when proxies get banned, time out, or return garbage is the part people get wrong. Below is a small, dependency-light proxy rotator that does retries, health tracking, and failover — copy-paste ready.

If you scrape anything at scale, you already know the pain: you paste a list of proxies into a loop, it works for ten minutes, then half of them get rate-limited, three are dead, one returns a captcha page with HTTP 200, and your job silently produces junk. A naive random.choice(proxies) doesn't cut it.

This post builds a rotator that treats proxies like what they are — an unreliable resource pool — and keeps your scraper running anyway.

What a real rotator needs

Before code, the requirements that separate a toy from something you'd run in production:

Rotation — spread requests across the pool so no single IP gets hammered.
Retries — a failed request should retry on a different proxy, not the same dead one.
Health tracking — proxies that fail repeatedly get benched; proxies that recover come back.
Failure classification — a timeout, a 407, a 429, and a captcha page are different problems and shouldn't be treated the same.
No heavy dependencies — just requests. (An async version at the end.)

Step 1: model a proxy with health

Each proxy is more than a string — it carries a score we adjust as it succeeds or fails.

import time
from dataclasses import dataclass, field


@dataclass
class Proxy:
    url: str                      # "http://user:pass@host:port"
    fails: int = 0                # consecutive failures
    disabled_until: float = 0.0   # unix time; 0 means active

    def is_available(self) -> bool:
        return time.time() >= self.disabled_until

    def penalize(self, cooldown: float = 60.0):
        self.fails += 1
        # exponential backoff: 60s, 120s, 240s...
        self.disabled_until = time.time() + cooldown * (2 ** (self.fails - 1))

    def reward(self):
        self.fails = 0
        self.disabled_until = 0.0

Note the exponential backoff: a proxy that keeps failing gets benched for longer each time, instead of being retried into the ground.

Step 2: the rotator

import itertools
import threading


class ProxyRotator:
    def __init__(self, proxy_urls):
        self._proxies = [Proxy(u) for u in proxy_urls]
        self._cycle = itertools.cycle(self._proxies)
        self._lock = threading.Lock()

    def get(self) -> Proxy:
        """Return the next available proxy, or wait for the soonest one."""
        with self._lock:
            for _ in range(len(self._proxies)):
                p = next(self._cycle)
                if p.is_available():
                    return p
            # all benched — return the one that frees up soonest
            return min(self._proxies, key=lambda p: p.disabled_until)

    def alive_count(self) -> int:
        return sum(p.is_available() for p in self._proxies)

The itertools.cycle gives round-robin rotation; the lock makes it thread-safe so you can use it from a thread pool.

Step 3: the request wrapper with retries and classification

This is the part that actually saves your job. We classify what went wrong and react accordingly.

import requests

# treat these as "the proxy or target is refusing us"
BAD_STATUS = {403, 407, 429, 502, 503}


def fetch(rotator: ProxyRotator, url: str, max_retries: int = 4, timeout: int = 20):
    last_err = None
    for attempt in range(max_retries):
        proxy = rotator.get()
        try:
            r = requests.get(
                url,
                proxies={"http": proxy.url, "https": proxy.url},
                timeout=timeout,
            )
            if r.status_code in BAD_STATUS:
                proxy.penalize()
                last_err = f"HTTP {r.status_code}"
                continue
            # crude captcha / block-page check on a 200
            if "captcha" in r.text[:2000].lower():
                proxy.penalize(cooldown=120)
                last_err = "captcha page"
                continue
            proxy.reward()
            return r
        except (requests.Timeout, requests.ConnectionError) as e:
            proxy.penalize()
            last_err = type(e).__name__
            continue
    raise RuntimeError(f"all {max_retries} attempts failed, last: {last_err}")

Key details most tutorials miss:

A 200 with a captcha is a failure. Checking status code alone is not enough — sites return 200 on block pages constantly.
A 407 means proxy auth failed — penalize the proxy, don't blame the target.
We retry on a fresh proxy each attempt, because retrying the same dead one is pointless.

Step 4: use it

PROXIES = [
    "http://user:pass@p1.provider.com:8000",
    "http://user:pass@p2.provider.com:8000",
    "http://user:pass@p3.provider.com:8000",
]

rotator = ProxyRotator(PROXIES)

for target in ["https://httpbin.org/ip"] * 20:
    try:
        resp = fetch(rotator, target)
        print(resp.json(), f"| alive: {rotator.alive_count()}")
    except RuntimeError as e:
        print("giving up on this URL:", e)

Run it and watch alive shrink and recover as proxies get benched and come back. That visibility alone will teach you more about your proxy pool's real quality than any provider's marketing page.

Async version (for real throughput)

requests is synchronous. For thousands of URLs, here's the aiohttp core — same rotator, async fetch:

import aiohttp
import asyncio


async def fetch_async(rotator, session, url, max_retries=4):
    for _ in range(max_retries):
        proxy = rotator.get()
        try:
            async with session.get(url, proxy=proxy.url, timeout=20) as r:
                if r.status in BAD_STATUS:
                    proxy.penalize()
                    continue
                proxy.reward()
                return await r.text()
        except (aiohttp.ClientError, asyncio.TimeoutError):
            proxy.penalize()
    return None


async def main(urls):
    rotator = ProxyRotator(PROXIES)
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_async(rotator, session, u) for u in urls]
        return await asyncio.gather(*tasks)

(Note: aiohttp proxy auth needs the credentials in the proxy URL, which our format already has.)

What this won't fix

Honest limits, because your rotator is only as good as the proxies feeding it:

A rotator can't fix a bad pool. If your provider hands you already-flagged datacenter IPs, no amount of retry logic saves you. Rotating dead weight is still dead weight.
Rotating too aggressively can cause bans for stateful tasks (logins, carts). For account work you want sticky sessions, not rotation. Rotation is for stateless scraping.
Free proxy lists will make this code look broken because 90% of the pool is dead. The logic is fine; the input is garbage.

For the pool itself, you want residential or mobile IPs with real session control. I run mine through ProxyUniverse — residential, mobile and ISP proxies that come as standard host:port:user:pass, so they drop straight into the PROXIES list above with no changes. After the 2026 provider shutdowns, I keep the pool spread across networks so one dying provider doesn't empty my rotator.

Wrap-up

The difference between a scraper that runs for ten minutes and one that runs for ten days is almost never the parsing code — it's how you handle the proxy layer failing. Health tracking + classified retries + failover is maybe 60 lines, and it's the 60 lines that matter.

Grab the code, drop in your own proxies, and watch the alive counter. If you build something on top of this (proxy scoring, per-domain pools, Prometheus metrics), I'd genuinely like to see it.

Question for the comments: how do you detect soft blocks — captcha pages and junk HTML that come back with a clean HTTP 200? That's the failure class this rotator handles worst, and I'm curious what checks people run in production. 👇

Best Proxies for Dating Sites like Match in 2026: Access, Privacy, and Avoiding Wrongful IP Bans

Proxy Universe — Wed, 22 Jul 2026 18:39:08 +0000

Dating platforms — Match, Tinder, Bumble, Hinge, OkCupid and the rest — are some of the most aggressively IP-policed sites on the internet. If you've ever been shadow-limited, geo-locked while traveling, or wrongly flagged after a single login from a new network, you've run into it. This guide explains how dating sites read your IP, and how to keep a clean, stable connection.

I've supplied proxies to people working with dating platforms since 2023, and the recurring questions are always the same: which proxy type, which location, sticky or rotating. Here's the straight answer — plus a clear note on staying on the right side of the rules.

Legitimate reasons people use proxies with dating sites
Access while traveling or living abroad, where a platform limits or changes behavior by region.
Privacy — not exposing your home IP and approximate location to a data-hungry platform.
Stable location — keeping a consistent city/region so your matches and visibility don't scramble every time your ISP rotates your IP.
Agencies and social-media managers legitimately operating a client's own profile from a fixed location.
QA, testing and market research on how a platform behaves across regions.
This article covers the networking layer for those cases. It is not a guide to deceiving people, and using proxies to run fake or fraudulent profiles violates every dating platform's terms and, in many places, the law. Don't. More on that at the end.

Why dating sites are so sensitive to your IP
Dating platforms fight fraud and spam constantly, so they lean hard on IP signals:

IP reputation — datacenter and known-VPN ranges are heavily penalized or blocked. Dating apps block these faster than almost any other category of site.
Geo consistency — your stated location, phone region, GPS and IP should agree. A profile set to Los Angeles logging in from a German datacenter is an instant red flag.
IP churn — logging into one account from many different IPs in a short window looks like an account takeover and triggers verification or a lock.
Shared-IP crowding — many accounts behind one IP is the classic spam signature.
Datacenter proxies and public VPNs fail nearly all of these, which is exactly why people move to residential and mobile.

Residential vs mobile vs datacenter for dating platforms
Datacenter: fast and cheap, but the ranges are known and blacklisted. Dating apps detect these almost instantly. Not usable.

Residential: real ISP IPs from homes. High trust, real geo, and you can lock to a specific city. This is the sensible default for a stable, natural-looking connection.

Mobile (4G/5G): carrier IPs shared by huge numbers of real users, so they carry the highest trust — and mobile-first dating apps expect a mobile IP. This is often the strongest option for app-based platforms, at a higher cost per GB.

Location and stability matter more than raw speed
For dating platforms, a stable location beats everything. Pick the city you want to appear in, get a residential or mobile IP there, and match your device locale, timezone and (for apps) GPS region to it. Consistency is what reads as a normal user.

Just as important: use a sticky (session) IP that stays the same across logins. Dating sites treat an account that hops IPs as suspicious. One account, one stable IP, held over time — that's the pattern that avoids verification loops and wrongful locks.

A clean setup
Residential or mobile IP in your target city, matched to device locale, timezone and region.
A sticky session so the IP stays stable across sessions, not a rotating one.
If a browser is involved, one clean browser profile tied to that one IP — don't mix.
Standard host:port:user:pass (HTTP or SOCKS5), which drops into any browser, antidetect profile or mobile proxy tool.
Warm up gradually; sudden bursts of activity from a fresh session look automated.
Common mistakes
Using datacenter proxies or free VPNs (blocked fastest of all).
Letting the IP rotate between logins (looks like account takeover).
Location on the profile not matching the IP or phone region.
Sharing one IP across multiple accounts or people.
A note on staying legitimate
Proxies solve real access, privacy and stability problems. They do not make it acceptable to impersonate people, create fake or bulk profiles, or run romance scams — those harm real users, break platform rules everywhere, and are illegal in many jurisdictions. Payment processors, platforms and search engines all police this hard. Use proxies for legitimate access and privacy, not deception.

What to use
For dating platforms you want sticky residential or mobile IPs with precise city targeting, held stable over time. I run ProxyUniverse for this — residential, mobile and IPv4 across 10+ networks in one panel, with sticky sessions and city-level targeting, so you can keep one clean, stable IP per account.

Whatever provider you choose, stability and a clean, well-located IP are what keep a dating connection trouble-free.

TL;DR
Dating sites ban on IP first and block datacenter ranges fastest. Use a sticky residential or mobile IP in your target city, match your locale, timezone and region to it, keep one stable IP per account, and never let it rotate between logins. And keep it legitimate — proxies are for access and privacy, not for fake profiles.

What platform are you connecting to, and what's your setup? Happy to compare notes in the comments.

Don't Trust the Marketing Page: Score Your Proxy Provider's IP Quality in ~60 Lines of Python

Proxy Universe — Tue, 21 Jul 2026 16:20:40 +0000

Subtitle: Every provider claims "clean residential IPs". After the 2026 outage wave I trust none of them — I test. Here's the scorer I run before putting money on any network: latency, fraud score, and ban-rate against real targets.

In my previous posts I covered building a failover layer and monitoring provider uptime. This closes the trilogy: how do you know a provider's IPs are actually good before you commit a deposit?

"Good" is measurable. For any proxy, three numbers tell you most of what matters:

Latency — time to first byte through the proxy
Fraud/abuse score — is the IP already burned in reputation databases
Target survival — does the IP get challenged by the sites you actually care about

The scorer

import concurrent.futures as cf
import time
import requests

# proxies to test: grab 20-50 fresh IPs from the provider's gateway
PROXIES = [
    "http://user:pass@gate.provider.com:7777",
    # ... more sessions/IPs
]

# swap for your real targets
TARGETS = [
    "https://www.amazon.com/",
    "https://www.google.com/search?q=test",
]

IPINFO = "https://ipinfo.io/json"
SCAMALYTICS = "https://scamalytics.com/ip/{ip}"  # manual check; API is paid

def test_proxy(proxy_url: str) -> dict:
    p = {"http": proxy_url, "https": proxy_url}
    result = {"proxy": proxy_url[:40], "ok": False}

    # 1. latency + exit IP
    t0 = time.time()
    try:
        r = requests.get(IPINFO, proxies=p, timeout=12)
        result["latency_ms"] = round((time.time() - t0) * 1000)
        info = r.json()
        result["exit_ip"] = info.get("ip")
        result["geo"] = f'{info.get("country")}/{info.get("city")}'
        result["org"] = info.get("org", "")[:40]
    except Exception as e:
        result["error"] = f"connect: {type(e).__name__}"
        return result

    # 2. datacenter smell test: residential orgs are ISPs, not clouds
    dc_words = ("amazon", "google", "digitalocean", "ovh", "hetzner", "m247")
    result["looks_dc"] = any(w in result["org"].lower() for w in dc_words)

    # 3. target survival: 200 = pass, 403/429/503 or captcha markers = burned
    burned = 0
    for url in TARGETS:
        try:
            tr = requests.get(url, proxies=p, timeout=15,
                              headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"})
            text_sample = tr.text[:4000].lower()
            if tr.status_code != 200 or "captcha" in text_sample:
                burned += 1
        except Exception:
            burned += 1
    result["burned_targets"] = f"{burned}/{len(TARGETS)}"
    result["ok"] = True
    return result

with cf.ThreadPoolExecutor(max_workers=10) as ex:
    rows = list(ex.map(test_proxy, PROXIES))

rows.sort(key=lambda r: r.get("latency_ms", 99999))
for r in rows:
    print(r)

good = [r for r in rows if r["ok"] and not r["looks_dc"] and r["burned_targets"].startswith("0")]
print(f"\nPASS: {len(good)}/{len(rows)} "
      f"(median latency {sorted(r['latency_ms'] for r in rows if r['ok'])[len(rows)//2]}ms)")

How to read the results

Latency. Residential proxies add 300–900ms TTFB normally. Median above ~1.5s means an overloaded gateway — it won't get better under your production load.

The looks_dc flag. If a "residential" provider's exit IPs resolve to Amazon or M247 orgs, you're paying residential prices for datacenter IPs. Walk away. (This exact test has saved me from two providers this year.)

Burned targets. This is the one that matters most and the one no review can tell you, because it depends on your targets. A pool that's clean for Amazon may be torched for sneaker sites. Test with 30+ IPs to get a real rate: anything above ~15% burned on first contact means the pool is oversold in your niche.

The workflow that actually protects you

Deposit the minimum ($5–10) at any new provider.
Pull 30–50 IPs, run the scorer against your real targets.
Score again a week later — pool quality drifts as providers resell capacity.
Keep results per provider; when quality drops two checks in a row, shift volume to your backup before it becomes an emergency.

Step 4 is why I do all of this on an aggregator (one balance across 10+ networks) — moving volume between networks is a dropdown, not a new vendor onboarding. After watching PIA S5, IP2World, 922 S5 and 9Proxy users scramble this year, "migration is one click" stopped being a convenience and became the whole point.

Next post: putting the three scripts together into a self-healing proxy layer with automatic weight shifting. If you want it sooner, say so in the comments.

Best Proxies for Online Surveys in 2026: Residential vs Mobile, Geo-Targeting, and a No-Ban Setup

Proxy Universe — Fri, 17 Jul 2026 15:26:45 +0000

If you take paid surveys or run survey accounts at any kind of scale, you already know the real bottleneck isn't finding surveys — it's not getting flagged, screened out, or banned. And nine times out of ten, the thing that gets you flagged is your IP.

I've been supplying proxies to survey operators since 2023, and the same questions come up every week: which proxy type, which country, sticky or rotating, how many accounts per IP. This guide is the distilled answer.

Why survey sites care so much about your IP

Survey and market-research platforms make money by selling clean, unique respondents to their clients. So they invest heavily in filtering out anything that looks like duplicate or low-quality traffic. Your IP is the first signal they check:

IP reputation — datacenter and known-VPN ranges get scored down or blocked outright.
Geo consistency — if your profile says you're in Chicago but your IP resolves to a server farm in Frankfurt, you're screened out before question one.
Uniqueness — multiple respondents from the same IP or subnet look like one person farming accounts.
Timezone, language and IP alignment — mismatches between browser locale and IP geo are a classic flag.

Datacenter proxies fail almost all of these. That's why survey work is one of the clearest use cases for residential
and mobile proxies.

Residential vs mobile vs datacenter for surveys

Datacenter: cheap and fast, but the IP ranges are known and widely blacklisted by survey panels. Fine for scraping public pages, wrong tool for surveys. Skip.

Residential: real ISP-assigned IPs from actual homes. This is the default choice for surveys — high trust score, real geo, and you can target specific countries and cities. The vast majority of survey operators I supply run residential.

Mobile (4G/5G): carrier IPs shared by thousands of real users, so they carry very high trust and are the hardest to ban. Best when a survey platform is mobile-first, or when you need the absolute highest trust for high-value panels. More expensive per GB, so people usually reserve mobile for their most valuable accounts.

Geo-targeting: pick the country before the proxy

Survey payouts are not equal across countries. Tier-1 English-speaking geos — United States, United Kingdom, Canada, Australia — consistently pay the most per completed survey, because that's where the buying-power demographics are. Many high-value surveys are only offered to respondents in those countries.

So the rule is simple: the account's declared country, the browser locale and timezone, and the proxy IP geo must all match. A US account needs a US residential IP, US timezone, en-US locale. Consistency is what keeps you in the high-paying survey queues instead of the "no surveys available" wall.

Sticky sessions are non-negotiable

This is the mistake that burns most beginners. Surveys are long — screeners, the main questionnaire, sometimes 10 to 30 minutes. If your IP rotates mid-survey, the platform sees the session jump IPs and voids the response, or bans the account.

You want sticky (session) residential IPs: one stable IP held for the entire survey, ideally for the whole life of that account. Rotating proxies are for scraping, not for surveys. Configure a sticky session per account and leave it.

A clean per-account setup that survives

The setup that has worked for operators running anywhere from a handful to hundreds of accounts:

One antidetect browser profile per survey account (AdsPower, Dolphin, GoLogin, Multilogin, and so on). Separate cookies, canvas, fonts and WebGL fingerprint per profile.
One sticky residential IP per profile, in the account's country. Never share an IP across two accounts.
Match locale, timezone and language to the IP geo.
Keep the mapping stable: profile A always uses IP A. Don't shuffle IPs between profiles.
Warm accounts up — don't blast 20 surveys in the first hour on a brand-new profile.

Proxy string format is the standard host:port:user:pass (HTTP or SOCKS5), which drops straight into any antidetect browser's proxy field.

Common mistakes that get you banned

Using datacenter proxies (instant low trust).
Rotating IPs mid-survey (voided responses).
Piling multiple accounts on the same IP or subnet.
IP in one country, browser locale and timezone in another.
Reusing a residential IP that's already burned on the same panel.

A note on scale and rules

Running many accounts is against most survey platforms' terms of service, so understand the risk before you scale. This guide is about the networking layer — how IPs are detected and how to keep sessions clean — not legal advice. Operate within the rules that apply to you.

What to use

For survey work you want sticky residential IPs with real country and city targeting, and mobile as a premium option for the highest-trust accounts. I run ProxyUniverse for this — residential, mobile and IPv4 across 10+ networks in one panel, with sticky sessions and country/city targeting, so you can keep one clean IP per account and switch networks if one degrades. Link:

Whatever provider you pick, the checklist above is what actually keeps survey accounts alive.

TL;DR

Surveys get you banned on IP first. Use sticky residential IPs (mobile for premium accounts), match the country to high-payout geos like the US, UK, Canada and Australia, keep one IP per antidetect profile, and never rotate mid-survey. Get those five things right and your completion rate — and your earnings — stop bleeding out to screen-outs.

What's your survey stack — which antidetect browser and proxy setup are you running? Curious how others structure it.

Is 9Proxy Down in 2026? Verified Status, Timeline & Best Alternatives

Proxy Universe — Thu, 16 Jul 2026 17:25:25 +0000

Last updated: July 16, 2026
Quick answer: 9Proxy is not fully back. The public website loads again after going dark on June 28, 2026, but new purchases are still paused, the company has published no root cause, and full proxy stability is unconfirmed. If your workflow depends on it, keep a funded alternative running. Below is the verified timeline, what actually happened, whether it was "seized," and the alternatives that work right now.

Is 9Proxy down right now?
As of July 16, 2026:
Website (9proxy.com): up. Homepage, login and docs respond.
New purchases: still officially paused ("temporarily paused to support current customers first").
Proxy service: partially restored, stability uneven across plans/regions per user reports.
Root cause: never explained.
So the honest description is "recovering, not recovered." A homepage that returns HTTP 200 is not proof your proxies authenticate, rotate and hold sessions — those are different systems.

What happened
Reports clustered on June 28, 2026: the website wouldn't load, the desktop app timed out, active sessions dropped, and prepaid IP/GB balances became unusable. Support went quiet. This wasn't a marketing-site blip — login, dashboard, session generation and already-purchased capacity were all affected.
On June 29, 9Proxy posted an identical notice to its Facebook page and its BlackHatWorld seller account: "We're currently experiencing a service disruption… our team has identified an unexpected issue… we're focused on a stable and secure recovery rather than a rushed fix… we don't have an exact restoration time yet." No cause, no ETA.

Verified timeline
Jun 28 — Website + app down, sessions drop, balances locked.
Jun 29 — Official "service disruption" notice (Facebook + BlackHatWorld), no cause/ETA.
Jul 1 — Login + app still unavailable; homepage sometimes returns HTTP 200.
~Jul 6 — First "it's working again" user comments (not an official all-clear).

Why "HTTP 200" is not a proxy test
An uptime checker only confirms a web server answered. It does not verify a paying customer can:
authenticate and see the correct balance,
generate a residential endpoint,
open an authenticated HTTP/SOCKS5 session,
keep a sticky session alive,
rotate to a fresh IP,
get the requested country/city,
actually reach the target site.
That's why a status page can read "up" while users still report failures. Test authenticated sessions against your real targets before trusting production traffic.

Was 9Proxy seized or shut down?
No credible evidence supports a seizure. The domain shows an ordinary registrar lock, unchanged Cloudflare nameservers, and registration paid through 2027 — no government banner, no agency, no court filing. The "seized" story traces back to a single competitor blog.
For context, 2026 has been brutal for the proxy industry — the January IPIDEA-linked disruption (PIA S5, 922 S5, ABCProxy, Cherry Proxy) and the July NetNut/FBI action are real, better-attributed events. But sharing a calendar year with those isn't evidence. On verifiable facts, 9Proxy is a recovering service with paused sales, not a taken-down network.

9Proxy not working? Fast troubleshooting
Confirm it's them, not you — check a status monitor first.
Re-authenticate — sign in fresh, verify balance, regenerate credentials.
Update the desktop app — IP-based plans route through the client; timeouts often clear on the latest build.
Test HTTP and SOCKS5 separately, and try a second location.
Switch networks — rule out local firewall/DNS/ISP issues.
Check the purchase pause — if you were topping up, that's expected right now.
If sessions still fail, treat 9Proxy as unreliable for now and keep a funded fallback.

Best 9Proxy alternatives in 2026
With sales paused and stability unproven, the smart move is to keep a working provider ready — even if you plan to return. These are residential-first, credible swaps:
711Proxy — broad geo coverage for scraping and multi-accounting. Closest like-for-like swap. → https://go.proxyuniverse.org/711proxy
NovProxy — clean residential pool, straightforward pricing. → https://go.proxyuniverse.org/novproxy
Swiftproxy — value residential with sticky sessions. → https://go.proxyuniverse.org/swiftproxy
IPRocket / LokiProxy — solid residential options worth benchmarking. → https://go.proxyuniverse.org/residential
PIA Proxy GB — pay-per-GB, maps cleanly onto 9Proxy's GB budgeting. → https://go.proxyuniverse.org/pia-gb
Mobile proxies — if you need true mobile IPs, not residential. → https://go.proxyuniverse.org/mobile
Migrate in stages: move 20–30% of traffic first, measure connection + target success rates, then scale.

Buy the alternatives cheaper — from one panel
Here's the real lesson of this outage: a single provider is a single point of failure. When 9Proxy went dark, customers couldn't even reach money they'd already paid for.
ProxyUniverse is a multi-provider panel — 711Proxy, NovProxy, Swiftproxy, IPRocket, PIA GB and mobile in one dashboard. Because it aggregates several networks, per-unit prices are often lower than buying direct, and you can switch networks the moment one starts failing — exactly the resilience an outage like this rewards. Diversify across providers and no single blackout ever locks you out again. → https://go.proxyuniverse.org/catalog

9Proxy refund & prepaid balance
9Proxy's terms: GB traffic stays valid 180 days; unused IP balances don't expire — a paused store doesn't erase what you already bought.
There are no monetary refunds (only automatic replacement of a dead IP within 60 seconds of allocation).
If you can't reach a paid balance: open a support ticket, keep records (dates, screenshots, error codes), and if you paid by card with no resolution, a chargeback is the standard fallback.
Because purchases are still paused, don't commit new spend to 9Proxy right now — keep a funded alternative running instead.

FAQ
Is 9Proxy down right now? Not completely — the site is back, but new purchases are paused and full stability is unconfirmed (as of July 16, 2026).
Did 9Proxy get shut down / seized? No evidence of a seizure. It's an unconfirmed outage; the domain and registry look normal.
When did the outage start? June 28, 2026.
Can I get my money / balance back? GB stays valid 180 days and IP balances don't expire; no cash refunds. Keep records; chargeback as last resort.
What are the best alternatives? 711Proxy, NovProxy, Swiftproxy, PIA GB — all available in one panel via ProxyUniverse.

~Jul 8 — New "server down / all proxies failing" reports resurface.
Jul 15 — Site stable (~99.86% uptime on monitors); new purchases still paused.
There is no confirmed full-restoration date.