DEV Community: 全网低价IP

Debugging SOCKS5 at the Wire Level: An RFC 1928 Walkthrough

全网低价IP — Thu, 08 Oct 2026 02:02:23 +0000

"It works in the browser but hangs in my script." If you have run a proxy pool you have seen this line, and the usual answer is a shrug. The browser does the handshake for you and hides every step; your script inherits the failure but not the diagnosis. Reading it at the byte level collapses that ambiguity — a generic timeout becomes one specific phase.

Four phases, strictly ordered

SOCKS5 is small. RFC 1928 defines exactly four exchanges, and each one depends on the previous reply. A stall is almost always "the client is waiting for a reply the server will never send, because the previous message was malformed or unacceptable."

Greeting (client → proxy): VER, NMETHODS, then that many METHOD bytes. This is the client listing the auth methods it supports.
Method selection (proxy → client): VER, METHOD. The proxy picks one, or 0xFF for "none acceptable."
Request (client → proxy): VER, CMD, RSV, ATYP, DST.ADDR, DST.PORT. This is the actual ask — usually CONNECT.
Reply (proxy → client): VER, REP, RSV, ATYP, BND.ADDR, BND.PORT. REP = 0x00 means success; anything else is a structured error, not a crash.

The version byte is 0x05 in all four. If you ever see 0x04 in a reply, you are talking SOCKS4 to a SOCKS5 endpoint, or vice versa.

The byte layout, phase by phase

Phase	Direction	Fields (in order)	Sizes
Greeting	client → proxy	VER, NMETHODS, METHODS[]	1, 1, NMETHODS
Method selection	proxy → client	VER, METHOD	1, 1
Request	client → proxy	VER, CMD, RSV, ATYP, DST.ADDR, DST.PORT	1, 1, 1, 1, var, 2
Reply	proxy → client	VER, REP, RSV, ATYP, BND.ADDR, BND.PORT	1, 1, 1, 1, var, 2

ATYP decides how long ADDR is: 0x01 = 4-byte IPv4, 0x04 = 16-byte IPv6, 0x03 = one length byte followed by a domain name. Ports are big-endian. Getting the address type wrong is the single most common reason a hand-rolled client desynchronises: the proxy reads your domain name as raw address bytes and the stream never lines up again.

CMD is usually 0x01 (CONNECT). 0x02 (BIND) and 0x03 (UDP ASSOCIATE) exist, but most proxy services only implement CONNECT — a 0x03 request against such a proxy returns REP = 0x07 (command not supported), which is a configuration fact, not a bug in your code.

Auth is what silently kills a connection

Two methods carry most of the traffic: 0x00 (no auth) and 0x02 (username/password, defined in RFC 1929). If your client offers only 0x02 and the proxy is white-listed by source IP instead, it replies METHOD = 0xFF and drops the connection — to your socket an empty read, not an error. That is why "authenticated" proxies work from one machine and not another: the source IP is the real credential.

The practical fix is to offer both methods in the greeting and branch on the reply. Never assume the method you want.

import socket, struct

def socks5_connect(proxy_host, proxy_port, dst, timeout=10):
    s = socket.create_connection((proxy_host, proxy_port), timeout)
    # 1. Greeting: offer no-auth AND user/pass
    s.sendall(b"\x05\x02\x00\x02")
    ver, method = s.recv(2)
    if method == 0xFF:
        raise OSError("proxy rejected all offered auth methods")
    # 2. (If method == 0x02, do the RFC 1929 sub-negotiation here.)
    # 3. CONNECT with a domain name target
    host = dst[0].encode()
    req = b"\x05\x01\x00\x03" + bytes([len(host)]) + host + struct.pack("!H", dst[1])
    s.sendall(req)
    head = s.recv(4)                      # VER REP RSV ATYP
    rep = head[1]
    if rep != 0x00:
        raise OSError(f"CONNECT failed, REP=0x{rep:02x}")
    # 4. Consume BND.ADDR + BND.PORT so the socket is positioned at payload
    ln = {0x01: 4, 0x04: 16}.get(head[3]) or s.recv(1)[0]
    s.recv(ln + 2)
    return s   # s is now a plain tunnel; write HTTP or TLS over it

Once REP = 0x00 and the bound address is drained, the socket behaves like a direct connection. There is no further framing — that is the whole point of SOCKS5, and the reason it tunnels protocols it knows nothing about.

Mapping `REP` codes to real problems

REP	Meaning	Usual cause
`0x01`	General failure	Proxy backend could not open the upstream socket
`0x02`	Connection not allowed	Egress ACL / rule rejected the target
`0x03`	Network unreachable	Exit host has no route to the target
`0x04`	Host unreachable	Target DNS resolved but the host is down
`0x05`	Connection refused	Target reachable, port closed
`0x06`	TTL expired	Rare in practice
`0x07`	Command not supported	You asked for `BIND`/`UDP` on a `CONNECT`-only proxy
`0x08`	Address type not supported	You sent IPv6 to an IPv4-only endpoint

The distinction that saves the most time is 0x02 versus 0x05. A 0x02 means your proxy is healthy but policy said no — a credential, geo, or allowlist problem. A 0x05 means your proxy is healthy and policy said yes, but the destination refused — a target-side problem. Collapsing both into "the proxy is broken" sends you debugging the wrong end of the wire.

FAQ

Why does curl work with the same proxy but my Python socket does not?
curl handles the greeting, the RFC 1929 sub-negotiation, and the reply parsing for you; your script must do all three. The usual divergence is offering the wrong auth method set, or sending ATYP=0x01 with a hostname.

The connection opens but every request returns an error page. Where do I look?
Past the handshake. A successful REP = 0x00 means the tunnel is fine, so the failure is inside the tunnelled protocol — TLS handshake, HTTP status, or the target blocking the exit's ASN. Check the exit's IP class next, not the SOCKS layer.

Should I use domain (ATYP=0x03) or IP (ATYP=0x01) targeting?
Prefer the domain. It lets the proxy resolve the name from its network, which keeps DNS consistent with the exit IP. Sending a pre-resolved IP is a common leak: the name was resolved locally, so the DNS answer may point at the wrong region.

How do I check hundreds of endpoints without hand-rolling each one?
Read the bulk-validation pattern — connect, greet, and classify by REP in parallel — which is covered in the batch proxy check guide.

The handshake is unglamorous, but it turns "the proxy is broken" into one fixable sentence. For the client-side setup above it — Windows, mobile, browser, and router-level configuration — see the SOCKS5 usage guide this distils. To verify an exit before you commit to it, use the IP check center. Both are maintained by socks5ip.com.cn; confirm current terms with each platform directly for purchase details.

Account Isolation Is More Than an IP Swap: What Actually Links Two Sessions

全网低价IP — Mon, 05 Oct 2026 02:08:32 +0000

Two accounts, two proxies, two browser profiles — and the second is still restricted within a week. The usual conclusion is "the proxy was dirty." That is rarely the whole story. Swapping an exit changes one signal out of dozens, and the systems deciding your fate do not score signals in isolation. They score coherence.

The mental model: linking, not detecting

Fraud systems rarely ask "is this a proxy?" They ask "do these sessions plausibly belong to one human, or to a coherent new one?" Every session emits signals, the system builds an entity graph, and two nodes get merged when their signals are consistent in a way random users would not be.

That flips the objective. You are not trying to look clean. You are trying to look consistent — and consistently uninteresting.

Signals cluster into four layers: network (exit IP, ASN class, TLS/JA3, DNS resolver, WebRTC), environment (canvas, fonts, screen metrics, timezone, locale), behaviour (cadence, request ordering, local hours), and data (payment, phone, recovery email). The network layer is the one a proxy can change surgically. The others follow it — or betray it.

Where the mismatch actually shows up

The classic failure is a layered contradiction: a residential exit in Frankfurt, a browser on Asia/Shanghai, Accept-Language: zh-CN, a resolver in Virginia, a library-like TLS handshake. Each field is defensible alone; together they describe nobody.

Layer	Signal	A mismatch looks like	Align by
Network	Exit + ASN class	Residential exit, datacenter behaviour	One exit class per identity, held sticky
Network	Timezone vs. IP geo	IP in DE, clock on Asia/Shanghai	Derive TZ from the exit's geolocation
Network	`Accept-Language`	German exit, Chinese-only language list	Match locale ordering to the exit region
Network	DNS resolver	IP in EU, resolver in US	Resolve through the exit's network
Network	TLS / JA3	Browser-like UA, library-like handshake	Use a real browser stack, not a bare client
Network	WebRTC	Real ISP leaked behind the proxy	Disable it, or force it through the exit
Environment	Fingerprint drift	Canvas hash changes every session	Freeze the profile; never randomise per run

The two rules that do most of the work

One identity, one exit, held sticky. Rotating per request is the fastest way to look automated: no human changes city between two page loads. Rotation belongs to stateless fetching, where there is no identity to preserve — a different problem, covered in the proxy IP knowledge base.

Coherence beats cleanliness. An exit scoring a steady 20 for a month beats one scoring 0 today and 80 next Tuesday: only the first is predictable. If the IP changes character, every locale assertion built on it becomes a lie at once.

A workable procedure

Pick the exit first — region and class (consumer broadband for anything identity-bound), then pin it. Verify the ASN operator name, not a "residential" label.
Derive the environment from the exit — timezone, locale, Accept-Language, and date formats come from the exit's geolocation, not your workstation.
Freeze the profile — one per identity, no per-session randomisation. Drift within an identity is as suspicious as a clone across identities.
Close the leaks — WebRTC, DNS, and any extension that can route around the proxy.
Warm up — log in, browse, wait. High-risk actions on a cold session are the most common self-inflicted wound.
Measure before you scale — run the check below on a handful of identities, not the whole fleet.

A coherence check you can run daily

Assert that the network and environment layers agree before a session starts. Standard library only.

import json
import urllib.request

GEO_API = "https://ipapi.co/json/"

def probe(proxy=None):
    # Always probe *through the exit*. A local lookup tests the wrong hop.
    opener = urllib.request.build_opener(
        urllib.request.ProxyHandler({"http": proxy, "https": proxy})
        if proxy else urllib.request.ProxyHandler({}))
    with opener.open(GEO_API, timeout=15) as r:
        return json.loads(r.read().decode("utf-8"))

def coherence(g, expect):
    """Compare what the exit claims against what the profile asserts."""
    problems = []
    if g.get("country_code") != expect["country"]:
        problems.append(f"geo {g.get('country_code')} != {expect['country']}")
    if g.get("timezone") != expect["timezone"]:
        problems.append(f"tz {g.get('timezone')} != {expect['timezone']}")
    if not (g.get("org") or "").strip():   # ASN operator is the field people skip
        problems.append("ASN operator missing — checker returned a stub")
    return problems

for name, cfg in ACCOUNTS.items():        # {"acct-1": {"proxy": "socks5://...", "expect": {"country": "DE"}}}
    issues = coherence(probe(cfg["proxy"]), cfg["expect"])
    print(name, "OK" if not issues else "MISMATCH: " + "; ".join(issues))

Keep one expected-value record per identity; treat drift as a stop condition, not a warning.

Four mistakes that cost the most

Rotating per request for account work. It turns a stable identity into a high-velocity pattern; nothing else compensates.

Mixing exit classes inside one identity. Residential one hour, cloud the next, is a stronger signal than either alone.

Trusting a single score. Checkers disagree because they read different databases at different rates. Agreement between two sources is the signal; one number is a hint.

Forgetting the leaks. DNS, WebRTC, and timezone quietly undo an otherwise correct setup. Check them every session.

FAQ

Doesn't a residential IP alone solve account linking?
No. It removes one failure mode — ASN-based classification. Environment, behaviour, and data signals still do the linking.

How many accounts per exit is safe?
No universal number. The defensible rule is one identity per exit for anything identity-bound, and retiring an exit once an identity on it has failed.

Is a fingerprint browser mandatory?
For multi-account work on one machine, yes in practice: you need per-profile isolation of storage, fingerprint, and routing.

How do I verify the setup before committing?
Complete a real login and a normal session on the target, repeat over several days, and watch variance rather than the first reading.

The full guide this distils — proxy basics, scenario-to-IP-type mapping, protocol and tool choices, plus the router-level and fingerprint-browser setups — is at 代理IP与工具配置全方位指南. To check an exit before pinning it, use the IP check center. Both are maintained by socks5ip.com.cn; confirm current terms with each platform directly for purchase details.

IP Purity: What "Clean Enough" Really Means, and How to Check It

全网低价IP — Thu, 01 Oct 2026 02:23:42 +0000

"Clean IP" is used as if it were a property of the address. It is not. Purity is a relationship between an address, a database, and a target — and the target's own scoring rules decide the outcome. Two checkers can disagree about the same IP in the same minute and both be correct, because they are reading different databases with different update intervals.

The practical question is narrower, and it is answerable: will this address survive the flow I am about to run? Three checks get you most of the way.

Check 1 — blocklists and abuse history

The blunt instrument: is the address on a real-time blocklist, and does it carry recent abuse reports?

Consumer-facing consequence: sign-up flows that demand extra verification, or that silently never deliver the confirmation mail.
What to look at: multiple blocklists, not one. A single clean lookup proves nothing; a single dirty one is usually decisive.
Watch the recency, not the flag. An address delisted six months ago behaves differently from one flagged last week.

Check 2 — ASN ownership

This is the field that matters most, and the one people skip.

ASN type	How targets read it	Fits
Consumer broadband (residential)	A normal subscriber	Logins, accounts, anything identity-bound
Datacenter / cloud / hosting	A server, possibly a proxy	Stateless fetching, bulk collection
Mobile carrier	A real device, frequently re-assigned	App-level flows, tightly rate-limited targets

⚠️ A common trap: an address can belong to a cloud provider and still be described as "residential" by a cheap checker that only reads a country field. Verify the ASN operator name, not a categorical label.

Check 3 — neighbourhood

An IP's reputation is partly borrowed from the range it sits in. If the surrounding block has been heavily abused, individual addresses inherit the signal.

Look for how many addresses in the same /24 are flagged.
For dedicated work, prefer an exit that has been held for a while over one freshly rotated in from a noisy pool.
This is also why "rotate more" is not a fix for repeated blocks: it spreads the same pattern across more addresses, and the replacements inherit the range's reputation.

Two mistakes that cost the most

Reading "connects" as "clean". Connectivity is the network layer. Purity is the reputation layer. A proxy can connect perfectly and still be refused at the application layer by a risk score.

Chasing a perfect score. Public IPv4 space is recycled. The useful target is relatively clean and stable for the duration of the task — not absolutely spotless. An address that scores a steady 15 for thirty days is a better asset than one that scores 0 today and 80 next Tuesday, because only the first is predictable.

A workable procedure

Take 3–5 addresses from the vendor's trial allocation.
Run all three checks on each, and record the numbers.
Test against the actual target, not against a generic checker: complete a login, submit a form, navigate a session.
Repeat over several days. Look at variance, not the first reading.
Commit to the tier only after the target's own behaviour has repeated.

That sequence costs nothing extra and eliminates the expensive case: paying for a month of an exit that was never going to pass the target's risk layer.

FAQ

Is there a numeric threshold for "clean"?
No industry-wide one. Some operators describe thresholds internally, but they differ by target category. Use the three checks as a profile, not a grade.

Why does the same IP score differently on two checkers?
Different databases, different update frequencies, different weighting. Treat agreement between two or more sources as the signal; treat a single number as a hint.

Does a residential IP guarantee success?
No, it removes one specific failure mode (ASN-based classification). Flow shape, rate, and session behaviour still decide the outcome.

How often should an exit be re-checked?
Before each new workload, and periodically during long-running ones — reputations move, and the change is not announced.

A combined checker covering the three fields above runs at the IP check center. Method notes and the underlying decision tables live in the proxy IP knowledge base. Both are aggregation pages maintained by socks5ip.com.cn; for anything purchase-related, confirm current terms with the platform directly.

Choosing a Proxy by Use Case: Multi-Boxing, E-commerce, Scraping, Router-Level

全网低价IP — Mon, 28 Sep 2026 02:40:04 +0000

Most people buy a proxy the way they buy bandwidth: sort by price, take the cheapest tier that looks big enough, and only discover the mismatch after the first login fails. The ordering is backwards. Exit type decides whether a task is possible at all; tier and price only decide how much of it you can run. Get the order wrong and you spend the difference twice — once on the wrong tier, once on the replacement.

Three decisions, in order

Use case → exit type. Datacenter, residential, mobile; static or rotating. This is a capability question, not a cost question.
Exit type → the three hard numbers. Swap allowance, per-exit bandwidth cap, dedicated vs shared.
Those numbers → tier and price. Last, not first.

Comparing price across different exit types is meaningless. A shared rotating datacenter IP and a dedicated residential IP at the same monthly cost have nothing in common operationally.

Use case → exit type

Use case	Exit type that fits	Why
Game multi-boxing	Dedicated SOCKS5, one exit per window	Needs low latency and per-window isolation; several windows behind one exit read as a single origin
E-commerce accounts	Static residential (consumer broadband ASN)	Risk systems classify by ASN; datacenter ranges are the easy label
Scraping / collection	Rotating residential, metered per request	Needs many distinct origins; per-request billing is usually cheaper than a monthly commitment
Router-level / whole-network	L2TP, or SOCKS5 with router import support	Applies at the device layer; confirm the panel exports a config before buying
Overseas social / streaming	Foreign static residential	Needs a fixed exit in the target country or city, consistent with the account's history

The failure mode is almost never "the proxy was broken". It is "the exit type did not match the task", and no amount of tier upgrade repairs that.

The three hard numbers

Once the exit type is fixed, only three properties matter:

Swap allowance — how many times per month the exit may change, and what happens past the limit. A generous-looking tier with a 5-swap cap is unusable for anything session-bound.
Bandwidth cap — the ceiling on a single exit. Cheap tiers are often rate-limited rather than volume-limited; estimate from concurrency, not from the size of one request.
Dedicated vs shared — whether another customer can hold the same IP. Shared exits inherit someone else's reputation, which is invisible until a target starts demanding verification.

These three are comparable across vendors in a way that "speed" is not: they are contractual, measurable, and they do not depend on the target you happen to be testing against today.

Where teams lose money

Buying by unit price across tiers. The cheapest tier is cheap because it is small or slow, not because the vendor is generous. Buy the tier whose ceiling sits above the workload, then compare price within that tier.

Treating "it connects" as validation. Connectivity is the entry requirement, not the test. The test is whether the target's own flow — login, form submit, in-app navigation — completes repeatedly over several days.

Ignoring rotation semantics on authenticated targets. If the target issues a session cookie, changing country between page two and page three is itself a signal. Collection tasks want wide rotation; account-bound tasks want one fixed exit per identity.

FAQ

Is residential always better than datacenter?
No. Datacenter exits are faster and cheaper, and for stateless collection they are often the right answer. Residential matters specifically when a risk system scores the ASN — account-bound work, logins, anything where the platform's trust in the origin affects the outcome.

Do I need a dedicated IP?
Only if the workload has identity attached to it. Dedicated IPs exist to prevent other customers' behaviour from becoming your reputation. For anonymous bulk fetches, sharing is fine.

How long should I test before committing?
Long enough to see the target's behaviour repeat. A single successful login proves the configuration; three to five days of normal activity proves the exit's reputation. Use a free trial tier to run that window before paying.

What if the cheapest tier is the only one in budget?
Then reduce the workload rather than the exit type. A smaller allocation of the correct exit type outperforms a large allocation of the wrong one on every metric that matters downstream.

The full decision table — use case, exit type, and the three hard numbers side by side — is maintained on the proxy IP knowledge base, and live per-platform tiers are listed in the price center. Both are aggregation pages; always confirm the current offer on the provider's own site before purchase.

Proxy Rotation for Scrapers: Stickiness, Rate Limits, and Backoff That Works

全网低价IP — Thu, 24 Sep 2026 02:03:37 +0000

A scraper with a thousand exits still gets blocked in its first hundred requests if the traffic leaving those exits has the wrong shape. Blocks are rarely caused by one bad address. They come from the pattern around it: how fast you fire, how long you stay, and what you do when a target pushes back. Most teams treat rotation as one toggle; it is three, and rotating harder only touches the first.

Three independent knobs

Granularity — how often the exit changes: every request, every session, or pinned to a target.
Rate — requests per second, counted per exit and in aggregate.
Backoff — what the client does when the target signals "slow down".

If the rate is wrong, a larger pool is not a fix. It spreads the same abuse across more addresses and gets them flagged as a group — worse, because replacements then inherit the reputation of the range.

Granularity: choose by task, not by preference

Granularity	Exit changes	Fits	Breaks when
Per request	Every call	Stateless pages, price feeds, parallelising one query	The target binds a session to navigation; login or CSRF flows
Sticky per session	After N requests or T minutes	Logged-in browsing, pagination, multi-step forms	TTL too long → one exit carries all volume; too short → bot-like
Pinned per target	Never, until retired	Rate-sensitive targets, account-bound tasks	The pinned exit is silently shared with another worker

If the target issues a session cookie, honour it. A real visitor does not change country between page two and page three. What matters is not your preference but which granularity the target's session semantics allow: authentication flows need a coherent exit, anonymous page fetches do not. Account-bound tasks want one fixed address per identity; bulk collection wants a wide rotating range.

Rate: the number that actually gets you blocked

Two ceilings matter, and they are not the same:

Per-exit ceiling — what a real line plausibly does. Keep concurrency per exit at 1–4 and pace requests to a few per second at most.
Aggregate ceiling — what the site tolerates from its whole visitor population. This is what triggers a range ban, and rotation does not hide it.

If the pool holds N exits at b requests per second each, your crawl rate is at most N × b. That expression answers "tonight or next week", so pool sizing is arithmetic, not a purchase decision.

Backoff: read the signal before retrying

429 or 503 with Retry-After — obey the header literally. Ignoring it escalates a throttle into a ban.
403 or 444 on one exit while others succeed — retire that exit only. Tearing down the whole run because one address is spent is how an hour becomes three days.
Soft blocks — a 200 carrying a challenge page, an empty result set, or a truncated body. These are the expensive ones, because a naive client logs them as success and reports clean data.

Add jitter, and back off per exit rather than globally, so retries do not synchronise into a burst against a single address.

A pool that respects all three

import itertools, random, time, urllib.error, urllib.request


class Exit:
    def __init__(self, url, rps=1.0, max_fails=5):
        self.url, self.rps, self.max_fails = url, rps, max_fails
        self.next_at, self.fails = time.monotonic(), 0

    def take(self):
        """Token bucket: one slot per request, refilled at `rps`."""
        now = time.monotonic()
        if self.next_at > now:
            time.sleep(self.next_at - now)
        self.next_at = max(time.monotonic(), self.next_at) + 1.0 / self.rps

    @property
    def usable(self):
        return self.fails < self.max_fails


class SoftBlock(Exception):
    """200 OK whose body is a challenge page, not data."""


class Pool:
    def __init__(self, exits, sticky_ttl=300):
        self.exits = [Exit(u) for u in exits]
        self.ring = itertools.cycle(self.exits)
        self.sticky_ttl, self.sessions = sticky_ttl, {}

    def pick(self, key=None):
        if key and key in self.sessions:
            ex, expires = self.sessions[key]
            if expires > time.monotonic() and ex.usable:
                return ex
        for _ in range(len(self.exits) * 2):
            ex = next(self.ring)
            if ex.usable:
                if key:
                    self.sessions[key] = (ex, time.monotonic() + self.sticky_ttl)
                return ex
        raise RuntimeError("pool exhausted: every exit is retired")


def fetch(url, pool, key=None, attempts=4, min_bytes=500):
    for n in range(attempts):
        exit_ = pool.pick(key)
        exit_.take()
        opener = urllib.request.build_opener(urllib.request.ProxyHandler(
            {"http": exit_.url, "https": exit_.url}))
        try:
            with opener.open(url, timeout=20) as resp:
                body = resp.read()
            if len(body) < min_bytes:          # 200 with no payload
                raise SoftBlock("%d bytes from %s" % (len(body), exit_.url))
            exit_.fails = 0
            return body
        except (urllib.error.HTTPError, SoftBlock, OSError) as exc:
            if getattr(exc, "code", None) in (403, 429, 444) or isinstance(exc, SoftBlock):
                exit_.fails += 1               # retire the exit, keep the run
            time.sleep(min(2 ** n, 30) * random.uniform(0.5, 1.5))
    raise RuntimeError("gave up after %d attempts" % attempts)

Two details carry the value. pick() reuses a live sticky binding but still validates usability, so a retired address is never handed back. And the failure handler increments a counter instead of aborting — that is what turns a pool into a self-healing resource rather than a list you babysit.

How to tell you are being blocked

Track these per exit, not in aggregate:

Success rate — retire anything well below the pool median, not just at zero.
Median latency — a sharp drop usually means a cached challenge page.
Body-size distribution — real pages cluster; block pages do not.

Common mistakes

Rotating every request against a session-bound target. Aggressive rotation is itself a signal.

Treating 403 as a network error. Retrying the same exit against the same rejection turns a soft block permanent.

FAQ

How many proxies do I need?
Set the target rate first, then divide by the per-exit budget you can defend. A pool is a rate budget, not a quantity.

Per request or per session?
Follow the target's session semantics. Cookies and coherent navigation mean sticky sessions with a TTL; stateless pages can rotate freely.

The fuller Chinese guide behind this piece — matching pool types to scenarios, from account warm-up to bulk collection, and pairing exits with fingerprint isolation: IP environment for automated workflows. To measure pool health before rotating blindly, see the batch proxy check.

Residential vs Datacenter IPs: How Detection Systems Actually Tell Them Apart

全网低价IP — Thu, 24 Sep 2026 02:02:00 +0000

Every request announces three things before it carries a payload: the network it came from, the organisation that registered that network, and the reverse DNS its owner published. Anti-bot systems read all three, and care little which protocol you used to reach them.

So two proxies with identical credentials can have very different survival rates. The difference is rarely your configuration — it is the registry record behind the address.

What "residential" actually means

The word describes who an address block was allocated to, not how fast it is.

Registries allocate address space to organisations, and each allocation is announced under an Autonomous System with a number, a country and a registered organisation name. A block allocated to a consumer ISP — a company selling DSL, fibre or mobile subscriptions — is what the industry calls residential. A hosting company, cloud provider or colocation operator gets datacenter.

The other half of the vocabulary is orthogonal: static vs rotating is how long you keep an address, while residential vs datacenter is what it is registered as. Two axes, four combinations:

	Static	Rotating
Residential	A fixed address on a real subscriber line. Best for long-lived accounts.	A pool of subscriber addresses, reassigned per request or session. Best for wide crawling.
Datacenter	A fixed address on hosting infrastructure. Cheap, fast, obvious.	Hosting addresses cycled automatically. High throughput, low baseline trust.

Pricing arguments usually compare a rotating datacenter product against a static residential one, which is not a comparison at all. Read a spec as a coordinate on that grid.

What detectors actually look at

No serious system decides on one field. It builds a picture and asks whether the picture is internally consistent:

ASN classification. The organisation behind the AS — the strongest signal and the hardest to fake.
Reverse DNS. ISPs leave recognisable PTR patterns. A block with none reads as infrastructure, not a household.
Prefix geometry. Ranges where every host behaves identically look automated; consumer lines are sparse.
Reputation history. A recycled residential address can be dirty; a new, exclusive datacenter address can be spotless.
Request coherence. TLS fingerprint, header order, timezone, locale. A residential IP on a headless browser convinces nobody.

Coherence beats individual quality — a modest address with a matching client outperforms a pristine one with a mismatched client.

Classifying an exit IP yourself

Two free inputs — the ASN organisation name and the reverse DNS record — are enough for a first-order answer.

import ipaddress, json, re, socket, urllib.request

HOSTING_HINTS = ('amazon', 'google', 'microsoft', 'azure', 'digitalocean',
                 'linode', 'ovh', 'hetzner', 'vultr', 'alibaba', 'tencent')
RESIDENTIAL_PTR = re.compile(
    r'(dsl|ppp|dial|broadband|dynamic|pool|cable|client|comcast|telecom)', re.I)
INFRA_PTR = re.compile(r'(vps|server|cloud|host|colo|dedi|node|vm)', re.I)


def asn_lookup(ip):
    """{'asn': int, 'org': str}. BGPView is shown; swap in any equivalent
    BGP source."""
    url = 'https://api.bgpview.io/ip/%s' % ip
    req = urllib.request.Request(url, headers={'User-Agent': 'classify/1.0'})
    with urllib.request.urlopen(req, timeout=15) as r:
        prefixes = json.load(r)['data'].get('prefixes') or []
    asn = prefixes[0]['asn'] if prefixes else {}
    return {'asn': asn.get('asn', 0),
            'org': asn.get('name') or asn.get('description') or ''}


def reverse_dns(ip):
    try:
        return socket.gethostbyaddr(ip)[0]
    except (socket.herror, socket.gaierror, OSError):
        return ''                     # a missing PTR is itself a signal


def classify(ip):
    if ipaddress.ip_address(ip).is_private:
        return 'private', {'asn': 0, 'org': ''}, '', 0

    info = asn_lookup(ip)
    ptr = reverse_dns(ip)

    score = 0                     # positive leans residential, negative hosting
    if any(h in info['org'].lower() for h in HOSTING_HINTS):
        score -= 2
    if INFRA_PTR.search(ptr):
        score -= 1
    if RESIDENTIAL_PTR.search(ptr):
        score += 2
    if not ptr:
        score -= 1

    label = ('residential-like' if score >= 2 else
             'datacenter-like' if score <= -2 else 'ambiguous')
    return label, info, ptr, score

Run it across a pool rather than against one address, and print the label beside the ASN: the shape of that output says more than any single row.

Judge the distribution, not the sample. One ambiguous address proves nothing; a pool sold as residential that returns three quarters datacenter-like is a routing problem you should have been told about. Cache ASN lookups by prefix — every address in a /24 resolves to the same ASN.

Registry data answers "what is this registered as", not "how my target treats it", so cross-check live: the IP information lookup returns the ASN, organisation and registration type for any address — the same field this script consumes.

Common mistakes

Assuming residential means clean. Residential describes registration, not history. A recycled address inherits someone else's reputation.

Rotating every request when the target expects a session. Aggressive rotation is a signal of its own: a real visitor's address does not change between page two and page three.

Validating against the wrong target. A pool can pass every connectivity check and still fail on the site you care about. Test the real destination, not an echo endpoint.

Ignoring the client side. If the TLS fingerprint, timezone and language do not match the address's region, the mismatch is louder than the address is good.

Buying on price per IP alone. Compare cost per usable address after the replacement rate, not the sticker count.

FAQ

Is residential always better than datacenter?
No. Datacenter is faster and cheaper, and many targets do not care. Residential matters when a risk model penalises hosting ranges.

How do I tell static from rotating?
Ask what happens when a session drops. Static returns the same address; rotating returns a different one.

What if my address returns ambiguous?
Plan as if it were datacenter and test it against your real target. It usually means a small regional operator or a reseller behind another AS.

Can I make a datacenter IP look residential?
Not convincingly. The pattern would have to hold across ASN registration, PTR records and prefix behaviour at once.

The longer version of this guide, on choosing a static residential provider for cross-border selling and data collection: 海外静态住宅IP怎么选. Per-platform pricing: pricing centre.

How to Validate 100+ Proxy Endpoints in Minutes Without a Paid API

全网低价IP — Mon, 21 Sep 2026 02:07:18 +0000

A proxy pool does not fail loudly. Entries go stale one at a time: a node stops answering, an authentication credential rotates, an upstream line gets reassigned to another customer. Your pipeline keeps running, and the failures surface later as missing records, a partial dataset, or a suspension email.

Checking the pool before a run is cheaper than debugging a run that went wrong.

What is actually worth testing

Most proxy checkers return a single number — latency — and stop there. That number is the least useful of the five things you can measure:

Check	Catches	Cost
TCP connect	Dead host, closed port	One socket
Real HTTP request through the proxy	Auth failure, whitelist rejection, upstream outage	One request
Exit IP matches expectation	Wrong node returned, pool misconfiguration	Free (from the response)
Latency	Slow-but-alive nodes worth deprioritising	Free
Header leakage	`Via`, `X-Forwarded-For`, real IP in errors	Free

The important one is the second. A socket that connects is not a proxy that works — plenty of dead nodes still accept TCP and then hang or reject. You have to push a real request through and read the answer.

The checker

This uses only the standard library. It runs the whole battery concurrently and returns a structured report.

import json
import socket
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
from urllib.parse import urlparse

# Any endpoint that echoes the caller's IP works.
PROBE_URL = "http://ip-api.com/json/?fields=status,query,country,as"
TIMEOUT = 12
WORKERS = 40


def check(entry):
    """entry: {'id': ..., 'host': ..., 'port': ..., 'user': ..., 'password': ...}"""
    result = {
        "id": entry.get("id"),
        "host": entry.get("host"),
        "port": entry.get("port"),
        "tcp_ok": False,
        "http_ok": False,
        "exit_ip": None,
        "latency_ms": None,
        "error": None,
    }

    # --- 1. TCP reachability -------------------------------------------------
    t0 = time.perf_counter()
    try:
        with socket.create_connection((entry["host"], int(entry["port"])), timeout=TIMEOUT):
            result["tcp_ok"] = True
    except Exception as exc:
        result["error"] = f"tcp: {type(exc).__name__}"
        return result

    # --- 2. Real request through the proxy ----------------------------------
    # Uses a plain HTTP CONNECT-free request for SOCKS-compatible testing.
    # For a genuine SOCKS5 handshake use PySocks: socks.socksocket()
    try:
        import socks  # PySocks
        s = socks.socksocket()
        s.set_proxy(socks.SOCKS5, entry["host"], int(entry["port"]),
                    username=entry.get("user"), password=entry.get("password"))
        s.settimeout(TIMEOUT)
        s.connect((urlparse(PROBE_URL).hostname, 80))
        s.sendall(
            f"GET {urlparse(PROBE_URL).path} HTTP/1.1\r\n"
            f"Host: {urlparse(PROBE_URL).hostname}\r\n"
            f"User-Agent: pool-checker/1.0\r\n"
            f"Connection: close\r\n\r\n".encode()
        )
        chunks = []
        while True:
            chunk = s.recv(4096)
            if not chunk:
                break
            chunks.append(chunk)
        s.close()

        raw = b"".join(chunks).decode("utf-8", "ignore")
        body = raw.split("\r\n\r\n", 1)[-1]
        payload = json.loads(body)
        result["latency_ms"] = round((time.perf_counter() - t0) * 1000)
        if payload.get("status") == "success":
            result["http_ok"] = True
            result["exit_ip"] = payload.get("query")
            result["asn"] = payload.get("as")
    except Exception as exc:
        result["error"] = f"http: {type(exc).__name__}"
    return result


def validate(pool):
    healthy, dead = [], []
    with ThreadPoolExecutor(max_workers=WORKERS) as pool_exec:
        futures = {pool_exec.submit(check, e): e for e in pool}
        for fut in as_completed(futures):
            r = fut.result()
            (healthy if r["http_ok"] else dead).append(r)
    return healthy, dead


if __name__ == "__main__":
    pool = [
        {"id": "n1", "host": "127.0.0.1", "port": 1080},
        # ... load from your config
    ]
    healthy, dead = validate(pool)
    print(f"healthy {len(healthy)} / dead {len(dead)}")
    for r in sorted(healthy, key=lambda x: x["latency_ms"] or 0)[:10]:
        print(f'  {r["id"]:>6}  {r["latency_ms"]:>5} ms  exit={r["exit_ip"]}  {r.get("asn")}')

Two details that matter more than they look:

Concurrency is what makes this fast. 100 endpoints at 40 workers finishes in roughly the time of three bad nodes, not the sum of all of them. Serial checking with a 12-second timeout on 100 nodes can take twenty minutes when half the pool is down.

The timeout has to be per-connection, not global. A single global deadline means one hanging node poisons the whole batch result — which is exactly the failure mode you were trying to detect.

Reading the output

Three patterns are worth acting on:

High TCP success, low HTTP success. The nodes are reachable but the upstream is failing — usually an auth problem, an IP whitelist that does not include your machine, or a subscription that expired. This is a configuration issue, not a pool-quality issue.

Exit IPs clustered in one subnet. Your pool claims geographic diversity but is routing through a handful of machines. Check the returned as field: if most nodes share one ASN, the pool is not as diversified as advertised.

Bimodal latency. A cluster of fast nodes and a cluster of slow ones often means two different upstreams behind one entry point. Splitting them lets you route latency-sensitive work to the fast half.

Common mistakes

Only testing on port 443. Many proxy pools serve HTTP CONNECT on one port and SOCKS5 on another. Test the protocol you actually use.

Reusing one target site. Any site with per-IP rate limits will start refusing after a few hundred checks, and you will misread that as pool failure. Use a lightweight echo endpoint.

Ignoring the check count against the probe. If a source offers 45 requests per minute, 100 concurrent workers will get throttled and produce false negatives. Either throttle, or use multiple probe endpoints. The DNS-based lookup described in the ASN guide has no such limit.

Treating a green run as permanent. Reputation and availability are both time-varying. Validate before each run, or on a schedule.

FAQ

Do I need PySocks?
Only for genuine SOCKS5 handshakes. For HTTP and HTTPS proxies the standard library's urllib accepts a proxy URL directly, and requests does the same with the proxies argument.

How many workers should I use?
Start at 40. Past a few hundred you will saturate the local NIC or hit probe rate limits, and the extra failures are your own doing rather than the pool's.

Can I check without sending a request to a third party?
Not meaningfully. A handshake proves the listener exists; it does not prove the upstream works or what exit IP you get. Some target has to answer.

What latency should I accept?
It depends on the workload, but if the 90th percentile is above roughly ten times the median, you have a multi-tier pool and should treat the tiers separately.

How often should I re-validate?
Before every large run, plus a scheduled sweep on a fixed interval. Pools degrade between your runs, not during them.

A longer walkthrough of the same procedure, including how the checks are scheduled and what the pass thresholds are in practice, is here: batch proxy validation tutorial. For current per-platform pricing across the providers referenced in this series, see the pricing centre.

Router-Level Proxying on OpenWrt: When a SOCKS5 Client Is Not Enough

全网低价IP — Thu, 17 Sep 2026 08:44:34 +0000

Most proxy guides assume you can install software on the device. That assumption breaks the moment the device is a smart TV, a game console, a security camera, or an IoT sensor. There is no client to configure, no SOCKS5 field to fill in.

The only place left to intervene is the router.

Two ways to route at the router

Once you move the decision up to the router, you have to choose how much of the traffic to divert. That choice is between an application-layer redirect and a device-level tunnel.

Transparent proxy (redsocks / tproxy). You capture TCP traffic on the router and forward it to a SOCKS5 upstream. Rules decide which destinations get redirected. Works with any device, no per-device configuration.

Tunnel protocol (L2TP, PPTP, WireGuard, OpenVPN). The router becomes a client of the upstream and pushes a default or policy route down to the LAN. Everything behind the router shares one exit.

Both approaches reach the same outcome — devices with no client software get proxied. The differences show up in routing granularity, protocol support, and how much per-connection overhead you accept.

Choosing between them

Dimension	Transparent SOCKS5	L2TP tunnel
Granularity	Per-destination rules	Whole tunnel, or policy routes
UDP support	Requires extra work (often breaks)	Native
Work on the same network	Yes, mixed with direct traffic	Yes, via policy routing
Typical upstream product	SOCKS5 proxy pool	L2TP line, usually residential
Overhead	Low	Slightly higher (encapsulation)
Device support	Anything on the LAN	Anything on the LAN
Best fit	Selective routing, web-heavy traffic	Uniform exit for all devices

The practical rule: if you need different devices to exit through different IPs, use transparent SOCKS5 with rules. If every device should share one clean residential exit, use L2TP. Gaming consoles, streaming boxes and cameras usually fall into the second category, because the destination application is not something you can meaningfully split by rule.

OpenWrt specifics

OpenWrt is the common choice here because it gives you a real package manager and iptables/nftables access on cheap hardware. The shape of the setup:

For transparent SOCKS5:

LAN clients
    │
    ▼
OpenWrt (iptables/nftables rules)  ──redirect──▶  redsocks / redsocks2
    │                                                     │
    │                                                  SOCKS5 upstream
    ▼
Direct traffic (rules excluded)

You install redsocks2 (or redsocks plus iptables-mod-tproxy), point it at your upstream SOCKS5 endpoint, and add rules that mark the traffic you want redirected. A common pattern is a destination list — redirect specific domains or address ranges, leave everything else direct.

# illustrative: redirect traffic marked with fwmark 0x1
iptables -t nat -A OUTPUT -p tcp -m mark --mark 0x1 -j REDIRECT --to-ports 12345

For L2TP:

WAN ──L2TP client (xl2tpd + pppd)──▶ upstream
     │
     └── LAN: default route or policy routes

OpenWrt's xl2tpd plus ppp-mod-pppol2tp handles the client side. Once the interface comes up you assign it a firewall zone and either make it the default route or use policy routing to send only chosen subnets through it. Watch the MTU — L2TP encapsulation reduces it, and a wrong MTU presents as "pages load halfway" rather than as a clean failure.

Pitfalls that cost the most time

UDP does not come along for free. Transparent SOCKS5 setups frequently break DNS, QUIC and game traffic because SOCKS5 UDP relay is either unsupported upstream or poorly implemented. If the devices behind the router care about UDP, prefer the tunnel approach.

DNS is a separate decision from routing. Redirecting TCP to port 443 does nothing for DNS. If your clients still resolve names through the ISP resolver, you have a leak regardless of how good the tunnel is. Force DNS through the tunnel or to a resolver you control, and test it.

The router's own traffic is easy to forget. Rules placed in OUTPUT cover traffic originating on the router; PREROUTING covers forwarded LAN traffic. Getting this backwards produces the confusing result where the router itself is proxied but the devices behind it are not.

Cheap hardware has a ceiling. Tunnels and transparent redirection both cost CPU. A low-end router can handle a few encrypted streams and then quietly drop throughput. Test with real load, not with a single ping.

The upstream line is not the bottleneck you think it is. Residential and L2TP lines are often bandwidth-capped at the product level. Negotiating 100 Mbit on the interface means nothing if the line is provisioned at 20 Mbit.

Verifying the result

Do not trust the router UI. Verify from a client behind it:

# the exit IP each device actually uses
curl -s https://api.ipify.org

# whether DNS is resolving through the tunnel
dig +short whoami.akamai.net @<your-resolver>

Run both from the router, from a laptop on the LAN, and from the device that motivated the whole exercise. A setup that works from the router and fails from the console is almost always a forwarding rule problem, not a tunnel problem.

FAQ

Do I need a dedicated machine for this?
No. OpenWrt runs on hardware ranging from a 15-dollar travel router to a small x86 box. The deciding factor is throughput and whether you need containerisation, not the routing approach itself.

Can I combine both — SOCKS5 rules and an L2TP tunnel?
Yes, and it is a common production pattern: route the console and TV through L2TP for a stable residential exit, and send the traffic that needs fine-grained destination control through transparent SOCKS5.

Will the ISP see what I am doing?
With L2TP the tunnel is encrypted between your router and the upstream, and the ISP sees only the tunnel endpoint. That is a transport property, not an anonymity guarantee — the upstream still sees your requests.

What about IPv6?
Dual-stack setups are a frequent source of leaks: the tunnel carries IPv4 while IPv6 traffic goes out natively. If the upstream is IPv4-only, disable IPv6 on the LAN or route it through the tunnel explicitly.

Is a residential L2TP line better than a datacenter one for this?
For anything that scores traffic by network type, yes — see the ASN discussion in the IP quality guide. For pure bandwidth-heavy workloads where classification does not matter, a datacenter line is cheaper.

The full router configuration walkthrough, including the rule sets and MTU values that worked in testing, is here: OpenWrt proxy configuration tutorial. Current per-platform pricing for both SOCKS5 and L2TP lines is listed in the pricing centre.

What Is an ASN — and Why It Decides Whether Your Proxy Looks Legit

全网低价IP — Thu, 17 Sep 2026 02:01:49 +0000

Every IP address belongs to an Autonomous System, and that AS carries a number. If you have ever wondered why one proxy gets blocked in minutes while another survives for weeks with identical settings, the answer is usually written in that number — not in your configuration.

This post is about reading it properly.

What an ASN actually is

An Autonomous System is a collection of IP networks operated under a single administrative authority with a single routing policy. Every AS gets a globally unique number from the regional internet registries — an ASN.

A few you may recognise:

ASN	Operator	Nature
AS4134	China Telecom	Consumer broadband + some enterprise
AS4837	China Unicom	Consumer broadband + some enterprise
AS15169	Google	Datacenter
AS16509	Amazon	Cloud / datacenter
AS14061	DigitalOcean	Cloud / datacenter

The distinction that matters for proxies is not which company, but what kind of network the AS is. Consumer broadband ASNs contain residential subscribers. Cloud and hosting ASNs contain rented virtual machines. When an anti-fraud system scores your request, this is one of the first things it looks at.

Why platforms treat ASN as a first-class signal

Reputation systems have to answer one question: does this traffic plausibly come from a real person?

A residential ISP ASN is expensive and slow to obtain at scale. Datacenter ASNs are cheap and instant. So ASN type works as a crude but effective proxy for "is this a farm."

This is why the same scraper, with the same user agent and the same request rate, can succeed from a home connection and get a CAPTCHA wall from a VPS. Nothing about your code changed. Your ASN changed.

How to look up an ASN

Three approaches, in increasing order of convenience.

1. whois — available on most Linux boxes:

whois -h whois.cymru.com " -v 8.8.8.8"

The origin field is the ASN, and AS Name gives you the operator.

2. DNS, via Team Cymru — no dependencies, no rate limits:

dig +short 8.8.8.8.origin.asn.cymru.com TXT
# "15169 | 8.8.8.0/24 | US | arin | 1992-12-01"

3. An HTTP API — easiest to integrate:

curl -s "http://ip-api.com/json/8.8.8.8?fields=as,asname,isp,proxy,hosting"

{"as":"AS15169 Google LLC","asname":"GOOGLE","isp":"Google LLC","proxy":false,"hosting":true}

That hosting: true flag is the useful part: it is a direct answer to "is this a datacenter IP?" without you maintaining a list of ASN ranges.

The four-signal check

ASN alone is not enough. A residential IP can still be dirty — shared by thousands of users, previously abused, or listed in a spam database. Run all four:

Signal	What it tells you	Why it matters
ASN type	Residential vs datacenter vs mobile	The strongest single predictor
IP type databases	How third parties classify the IP	Vendors compare notes; a mismatch is a red flag
Blocklists / risk score	Abuse history	A clean ASN does not clear an IP's past
DNS and WebRTC leakage	Whether your real IP escapes	A perfect proxy that leaks DNS is not a proxy

The last one is the most commonly skipped. If your browser resolves DNS outside the tunnel, the destination site may never see your proxy IP at all — it sees your resolver, and often your ISP with it.

Putting it in a script

This runs the ASN portion of the check for a list of IPs:

import json, urllib.request

def asn_lookup(ip):
    url = f"http://ip-api.com/json/{ip}?fields=status,country,as,asname,isp,proxy,hosting,mobile"
    with urllib.request.urlopen(url, timeout=10) as r:
        d = json.load(r)
    if d.get("status") != "success":
        return None
    if d.get("hosting"):
        kind = "datacenter"
    elif d.get("mobile"):
        kind = "mobile"
    else:
        kind = "residential"
    return {"ip": ip, "asn": d.get("as"), "isp": d.get("isp"), "type": kind}

for ip in ["8.8.8.8", "114.114.114.114"]:
    print(asn_lookup(ip))

Free tier caveat: ip-api.com allows 45 requests per minute from one IP. For larger batches, throttle or split across resolvers. The DNS method above has no such limit if you only need the ASN and country.

Common mistakes

Treating "residential ASN" as a guarantee. Many residential proxy pools are sourced from devices the operator does not fully control. Quality varies enormously between vendors within the same ASN category.

Ignoring the proxy flag. Some databases flag known proxy ranges independently of hosting status. A residential ASN can still carry a proxy: true mark if the range is widely resold.

Checking once. IP reputation is dynamic. A pool that was clean last month may be burnt now. Validate on a schedule, not on setup day.

Assuming a mobile IP is always better. Mobile ASNs are shared by design — hundreds of users behind one carrier NAT. For account-based work, that sharing is a liability disguised as legitimacy.

FAQ

Does ASN affect SEO or ad delivery?
Yes — search engines and ad networks geolocate and classify by ASN. An inconsistent ASN pattern can trigger suspicious-traffic filters independently of what your content is.

How do I know whether an ASN is a hosting ASN?
Look for the hosting flag in an IP API, or compare against the AS's customer-facing description. Names containing Cloud, Hosting, Server, VPS, or CDN are near-certain datacenter ASNs.

Can I move a proxy from one ASN to another?
You cannot change an IP's ASN — it is assigned at the network level. You change provider, or you change the type of addressing you purchase.

Why do two IPs from the same provider have different ASNs?
Larger providers operate multiple ASes across regions and product lines. Residential and datacenter offerings from one brand are frequently announced from different ASNs.

If you want to run the four-signal check without writing the code yourself, there is a free checker here: IP quality and network-type check. For the platform-by-platform price comparison referenced throughout this series, see the proxy IP pricing centre.

SOCKS5 vs L2TP: Choosing the Right Proxy Layer (and When You Need Both)

全网低价IP — Wed, 16 Sep 2026 09:47:42 +0000

The question "SOCKS5 or L2TP?" is usually asked as if they were two options on the same menu. They are not. They operate at different layers of the stack, and the correct answer for a non-trivial setup is frequently "both, for different parts of the network."

The decision rule

SOCKS5 decides per application. L2TP decides per device.

That single difference explains almost every real-world choice:

If the thing needs a proxy inside it — a browser profile, an automation script, an emulator instance — it needs SOCKS5 (or HTTP), because that is where application-level proxy configuration exists.
If the thing cannot run a proxy client at all — a TV, a game console, a camera, an IoT device — it needs the decision made at the network layer, which means a tunnel (L2TP) or a router-level proxy.

Protocol comparison

Protocol	OSI layer	UDP	Scope	Configured in	Best for
SOCKS5	Session (L5)	✅ Yes	Per application	The application	Browsers, automation tools, emulators, one-exit-per-profile isolation
HTTP/HTTPS	Application (L7)	❌ No	Per application	The application	Simple HTTP clients, scraping where CONNECT is enough
L2TP	Data link (L2)	Limited	Per device / network	OS or router	Routers, whole-home routing, devices with no proxy support
PPTP	Data link (L2)	Limited	Per device / network	OS or router	Legacy only — deprecated, do not build new setups on it

Two rows in that table carry most of the practical weight.

UDP support. SOCKS5 carries UDP. L2TP does not carry it cleanly — which matters if your workload includes game traffic, QUIC, or anything else riding on UDP. If it does, the app-level route is not optional.

Scope. This is the one that forces mixed setups. A SOCKS5 proxy configured in a browser does nothing for a console plugged into the same switch. An L2TP tunnel on the router covers every device behind it — including the ones you cannot install anything on.

When SOCKS5 is the right call

You need a different exit per browser profile, and you want each profile fully isolated by construction rather than by discipline.
You are running automation (Playwright, Selenium, scripted clients) where per-request or per-session routing is the whole point.
You need UDP.
Your devices can all run the client software you are using.

The tradeoff: nothing outside the configured applications is proxied. Any traffic the app sends outside that path — DNS, background calls, WebRTC — follows your normal route. This is the source of most "I set a proxy and it still leaked" incidents.

When L2TP is the right call

Devices you cannot install a client on: TV boxes, consoles, cameras, appliances.
Whole-home or whole-office routing where every device should share one exit by default.
You want the routing decision made once, at a boundary, instead of configured per-application and re-verified per device.
Router-level setups (OpenWrt and similar) where you control the gateway.

The tradeoff: everything behind that gateway shares one exit. That is exactly the point in some scenarios and disqualifying in others — for per-account isolation, sharing an exit across all devices defeats the purpose.

The mixed setup that covers both

The pattern that shows up most often in practice:

                    ┌─────────────────────────────┐
                    │  Router (OpenWrt)           │
   Devices with     │  L2TP tunnel → one exit     │
   no proxy client ─┤                             │
   (TV / console)   │                             │
                    └──────────────┬──────────────┘
                                   │
   Devices with     ┌──────────────▼──────────────┐
   per-app needs ───┤  SOCKS5 per application     │
   (browsers,       │  one exit per profile       │
    automation)     └─────────────────────────────┘

L2TP at the gateway handles the devices that cannot be configured. SOCKS5 inside each application handles the workloads that need separate exits. The two do not conflict — they apply to different traffic.

Practical notes

Test the layer, not just the IP. A clean IP behind a leaking DNS resolver still attributes your real origin. Verify what the destination sees, end to end.

UDP is the underrated filter. If you are evaluating protocols for anything interactive, check UDP support before anything else — it eliminates options quickly.

PPTP is not a real choice anymore. It appears in provider lists as a checkbox. Do not build a new setup on it.

Static vs rotating applies to both. L2TP tunnels can be static or rotating, and SOCKS5 lines can be either. The protocol choice and the rotation policy are independent decisions — pick the protocol by layer, then pick rotation by workload.

Summary

SOCKS5 = per application, UDP-capable, precise isolation. Use it where you can configure the client.
L2TP = per device/network, covers anything behind the gateway. Use it where you cannot.
Most real setups need both, split by whether the device can run a client.
Protocol and rotation are separate decisions; decide them in that order.

The full protocol reference — including where HTTP and PPTP fit and the specific selection criteria per scenario — is at socks5ip.com.cn/daili-xieyi. Provider price comparison across 20+ vendors is at socks5ip.com.cn/jiagezhongxin.

How to Check If a Proxy IP Is Clean: 4 Signals That Actually Matter

全网低价IP — Wed, 16 Sep 2026 09:47:35 +0000

If you work with proxies — for scraping, for geo-testing, for anything that needs an exit IP other than your own — you have probably pasted an IP into a "proxy checker" and gotten back a confidence score between 0 and 100.

Those scores are mostly useless on their own. They are one vendor's opinion, derived from signals you cannot inspect, on a scale nobody defined.

The underlying signals, on the other hand, are inspectable. There are four that matter, and they are not equally weighted.

The short answer

An IP is "clean" only if all four of these hold:

ASN ownership — the IP belongs to a consumer ISP, not a hosting/cloud provider
IP type classification — third-party databases label it residential, not hosting or known-proxy
Blocklist status — it does not appear in abuse/fraud databases
Leak behavior — DNS and WebRTC do not expose your real exit IP

If any one fails, the IP will get flagged in account-facing work regardless of how the other three look. Signal 1 is the most important, and it is the one most people skip.

Signal 1: ASN ownership (the one that actually decides)

Every IP belongs to an Autonomous System, and every AS has an owner. That owner is the signal anti-fraud systems weight most heavily, because it is the hardest to fake and the most stable over time.

An IP announced by a consumer broadband AS looks like a home user. An IP announced by a hosting AS looks like a server — because it is one. Platforms have been classifying by ASN owner for years, and it is cheap to do.

Look it up:

# Get the ASN for any IP
whois -h whois.cymru.com " -v 203.0.113.45"

# Or via Team Cymru's DNS interface (no client needed)
dig +short 45.113.0.203.origin.asn.cymru.com TXT

You will get back something like:

203.0.113.45 | 64512 | 203.0.113.0/24 | CN | ripencc | 2011-03-14 | AS64512 Example Broadband Co.

The last field — the AS name — is what you read. "Broadband", "Telecom", "Communications" suggests consumer. "Cloud", "Hosting", "Datacenter", "VPS", "LLC" is almost always a hosting AS.

A note on residential proxies specifically: a residential IP is one announced by a consumer AS. A static residential IP is one that stays assigned to you and does not rotate mid-session. Those are two different properties, and you need both for account-facing work.

Signal 2: IP type classification

Independent databases maintain their own residential/hosting/proxy labels. They disagree with each other more often than you would expect, which is exactly why it is worth checking more than one.

The useful check is whether a given database disagrees with the ASN evidence. If the AS says "consumer broadband" but two databases label the range as hosting or a known proxy pool, the range has a history you should know about.

This is also where "shared" versus "dedicated" shows up. A dedicated IP has only your traffic in its history. A shared IP carries the reputation of everyone who used it before you — including, potentially, someone who burned it. That history does not appear in any single lookup; it shows up as disagreement between sources.

Signal 3: Blocklist status

This is the one people check first and it is the least decisive. Most blocklists are narrow, lag behind reality, and are trivially avoided by anyone actually abusing an IP.

Still worth a look, because appearing on one is a hard fail:

# Quick multi-list check (DNSBL style)
for bl in zen.spamhaus.org b.barracudacentral.org dnsbl.sorbs.net; do
  result=$(dig +short 45.113.0.203.$bl A)
  if [ -z "$result" ]; then
    echo "$bl: clean"
  else
    echo "$bl: LISTED ($result)"
  fi
done

Absence from blocklists is necessary but nowhere near sufficient. Plenty of burned IPs are absent from every public list.

Signal 4: DNS and WebRTC leaks

This one is about your setup rather than the IP itself, and it is the most common way a technically clean IP still gets a connection attributed to the wrong origin.

DNS leak — your queries resolve through your real ISP's resolver instead of through the proxy path. Test with a DNS leak test service while the proxy is active and confirm the resolver matches the exit region.
WebRTC leak — browsers can expose local and public IPs through WebRTC even when a proxy is configured at the application layer. Disable or restrict WebRTC if the application does not need it.

Application-layer proxies (SOCKS5, HTTP) only cover what you route through them. Anything the application sends outside that path is not proxied — which is why a browser-level leak can attribute your real IP to a session you believed was isolated.

Putting it together

Signal	What to check	Weight	How often it fails silently
ASN ownership	`whois` / Team Cymru lookup — consumer ISP vs hosting	Highest	Rarely checked at all
Type classification	Two or more independent databases, and whether they agree with the ASN	Medium	Often — sources disagree
Blocklist	A few DNSBL lookups	Low	Rarely (lists lag)
Leak behavior	DNS leak test + WebRTC state with proxy active	Medium	Frequently — client misconfiguration

The mistakes that cost the most time

Trusting a single score. A composite score hides which signal failed. When something breaks, you cannot tell whether to change IPs, change clients, or change the provider.

Checking blocklists and stopping there. It is the easiest check and the weakest one. An IP absent from every public list can still be announced by a hosting AS with a range that has been used for automation for years.

Confusing "works right now" with "clean". An IP can pass every check today and be burned tomorrow, because classification is continuous and history accumulates. For account-facing work, prefer dedicated static residential over shared anything.

Ignoring the client. Half of the real-world failures are leak or routing misconfiguration, not IP reputation. Verify what the destination actually sees, not what you configured.

What to do with this

Check signals in order: ASN first, type second, leaks third, blocklists last. If the ASN is a hosting AS and your workload is account-facing, stop there — no other signal will save it.

If you want to run signals 1–4 without setting up each lookup yourself, there is a free check that reports them together at socks5ip.com.cn/ip-check-center. And if you are selecting providers rather than debugging one, the pooled comparison across 20+ vendors is at socks5ip.com.cn/jiagezhongxin.

The important part is not the tool. It is knowing which signal you are actually looking at, and what a failure in that signal tells you to change.

DEV Community: 全网低价IP

Debugging SOCKS5 at the Wire Level: An RFC 1928 Walkthrough

Four phases, strictly ordered

The byte layout, phase by phase

Auth is what silently kills a connection

Mapping REP codes to real problems

FAQ

Account Isolation Is More Than an IP Swap: What Actually Links Two Sessions

The mental model: linking, not detecting

Where the mismatch actually shows up

The two rules that do most of the work

A workable procedure

A coherence check you can run daily

Four mistakes that cost the most

FAQ

IP Purity: What "Clean Enough" Really Means, and How to Check It

Check 1 — blocklists and abuse history

Check 2 — ASN ownership

Check 3 — neighbourhood

Two mistakes that cost the most

A workable procedure

FAQ

Choosing a Proxy by Use Case: Multi-Boxing, E-commerce, Scraping, Router-Level

Three decisions, in order

Use case → exit type

The three hard numbers

Where teams lose money

FAQ

Proxy Rotation for Scrapers: Stickiness, Rate Limits, and Backoff That Works

Three independent knobs

Granularity: choose by task, not by preference

Rate: the number that actually gets you blocked

Backoff: read the signal before retrying

A pool that respects all three

How to tell you are being blocked

Common mistakes

FAQ

Residential vs Datacenter IPs: How Detection Systems Actually Tell Them Apart

What "residential" actually means

What detectors actually look at

Classifying an exit IP yourself

Common mistakes

FAQ

How to Validate 100+ Proxy Endpoints in Minutes Without a Paid API

What is actually worth testing

The checker

Reading the output

Common mistakes

FAQ

Router-Level Proxying on OpenWrt: When a SOCKS5 Client Is Not Enough

Two ways to route at the router

Choosing between them

OpenWrt specifics

Pitfalls that cost the most time

Verifying the result

FAQ

What Is an ASN — and Why It Decides Whether Your Proxy Looks Legit

What an ASN actually is

Why platforms treat ASN as a first-class signal

How to look up an ASN

The four-signal check

Putting it in a script

Common mistakes

FAQ

SOCKS5 vs L2TP: Choosing the Right Proxy Layer (and When You Need Both)

The decision rule

Protocol comparison

When SOCKS5 is the right call

When L2TP is the right call

The mixed setup that covers both

Practical notes

Summary

How to Check If a Proxy IP Is Clean: 4 Signals That Actually Matter

The short answer

Signal 1: ASN ownership (the one that actually decides)

Signal 2: IP type classification

Signal 3: Blocklist status

Signal 4: DNS and WebRTC leaks

Putting it together

The mistakes that cost the most time

Mapping `REP` codes to real problems