DEV Community: 全网低价IP

Concurrency, Connections, Threads: Which Number Your Proxy Plan Actually Meters

全网低价IP — Mon, 02 Nov 2026 02:08:58 +0000

You raised the thread count because requests were timing out. Throughput improved for an afternoon, then the provider's endpoint started returning errors and half the workers stalled. The plan advertised 200 concurrency, so the ceiling was supposed to be somewhere far away.

Four different numbers get described as "how much you can run at once", and they sit on three different layers. Mixing them up is how people buy a bigger tier to fix a problem that was never on the provider's side.

Four terms, three layers

Layer	Numbers that live here	Who sets it	What exceeding it looks like
Your machine	threads, open sockets, upstream bandwidth	your client settings, your NIC	queueing, timeouts, CPU or bandwidth saturation
Your plan	concurrency, rotation quota, extraction frequency, IP allowlist	the provider, per tier	endpoint rejection or a limit-exceeded message
The destination	per-IP rate limits, fingerprint scoring	the site you are calling	CAPTCHAs and 429s however many IPs you rotate

That third row is where the money goes missing. When the destination throttles you, more concurrency and more threads make it worse. Backing both off is frequently the actual fix.

Threads are yours; concurrency is theirs

Concurrency is an authorisation number printed on the plan: connections the provider agrees to hold open for you at one instant. It is a contract, not a measurement.

Threads are your own parallelism unit inside a scraper or a multi-boxing tool. Connection count is what the machine is holding right now — visible in Proxifier, NekoBox, or ss -tn. The three move together, but not one to one.

A thread that issues one request and waits holds one connection. A thread with keep-alive across ten hosts can hold ten.

So "raise the threads" pushes on all three layers at once. Hit your machine's wall first and you get timeouts with a sagging success rate. Hit the plan's wall first and you get endpoint errors. The symptoms differ, so read them before changing anything.

Do the arithmetic before upgrading: 40 threads touching two hosts each is up to 80 sockets. Against a tier that allows 50 concurrency, a configuration with "only" 40 threads is already over.

Extraction frequency is a rhythm, not a capacity

Extraction frequency governs how often you may call the endpoint that hands out new IPs. It says nothing about how long an IP stays usable — that is session length or rotation quota, a separate line item.

Pattern	Rhythm	Fits	Watch out for
Timed batch	one list per fixed interval	crawling, batch registration	missing the window costs a whole cycle; the script must wait
On-demand	one call, immediate response	flash sales, short bursts	the rate cap usually tracks the tier
Manual pull	a human clicks in a dashboard	topping up a handful of IPs	cannot be scripted, so it does not scale

One question decides which pattern you need: does a script or a human trigger the rotation? If a script does, the interval and its retries belong in the code, with a backoff that respects the window.

Measure your own ceiling

Provider pages describe the tier, not your NIC, your CPU, or your distance from the exit. The only trustworthy number is the one you measure, and it takes about ten minutes.

Ramp the level and record the first failure. A minimal SOCKS5 greeting is enough to test connection slots — you do not need to fetch a real page to find out when sockets stop opening.

import socket, time
from concurrent.futures import ThreadPoolExecutor

PROXY = ("203.0.113.10", 1080)          # your exit

def probe(_):
    t0 = time.time()
    try:
        s = socket.create_connection(PROXY, timeout=8)
        s.sendall(b"\x05\x01\x00")                     # ver 5, 1 method, no-auth
        if s.recv(2) != b"\x05\x00":
            return None
        req = b"\x05\x01\x00\x01" + socket.inet_aton("1.1.1.1") + (443).to_bytes(2, "big")
        s.sendall(req)
        ok = s.recv(10)[1] == 0                        # REP byte
        s.close()
        return (time.time() - t0, ok)
    except OSError:
        return None

for level in (10, 20, 40, 80, 120):
    with ThreadPoolExecutor(level) as ex:
        rows = list(ex.map(probe, range(level)))
    ok = sorted(r for r in rows if r and r[1])
    p50 = f"p50={ok[len(ok)//2][0]:.2f}s" if ok else "-"
    print(level, f"ok={len(ok)/level:.0%}", p50)

Read the output as a curve, not a single figure. The level just before the success rate drops is your sustainable setting; the level just before median latency doubles is your burst setting. Re-run after changing machines, exits, or targets, because the line moves.

Five mistakes that cost a tier upgrade

Reading "unlimited" as unlimited concurrency. It usually modifies rotation count. Concurrency is a separate authorisation, often printed in the same table two columns away.
Counting threads and calling it concurrency. Threads are yours and are bounded by hardware, not by the plan.
Assuming a missing allowlist entry means a dead line. An unauthorised source returns an endpoint-level rejection while the exit is perfectly reachable. If the socket opens, the line is not the problem.
Rotating IPs to escape a destination rate limit. Per-IP limits reset; account and fingerprint signals do not. More IPs against one account is the standard way to burn a whole pool.
Sizing on peak, buying on average. Pick the tier from the level you can hold for a full business cycle, not from a burst you hit twice a day.

FAQ

Is concurrency the same as connection count? No. Concurrency is the cap the provider grants per tier; connection count is what your machine holds right now. Compare them deliberately or you will never know which one you exceeded.

The plan says unlimited — can I run unlimited threads then? No. Unlimited typically refers to rotations. Your host still has a socket and bandwidth ceiling, and the tier lists concurrency separately.

Why do I get CAPTCHAs with 200 healthy exits? Because the limit lives at the destination, not in your pool. Per-IP limits may reset while account and fingerprint signals persist across rotations.

I rotated faster and throughput fell. Why? Every rotation costs a handshake, a TLS session, and often a cold cookie jar. Past some point the switching cost exceeds the gain, and the pool looks healthy while success rate drops.

Where to verify the numbers

Term definitions and per-tier comparisons sit side by side at the proxy IP knowledge base, and exits can be measured before you commit at the IP check center. If a tier's wording is ambiguous, ask the vendor to confirm the concurrency cap and the rotation quota in writing before paying — those two numbers, not the headline price, decide whether the plan fits.

Your SOCKS5 Proxy Works Fine. Your DNS Is What Leaks the Location.

全网低价IP — Thu, 29 Oct 2026 02:20:12 +0000

You pointed a client at a SOCKS5 exit, checked the address, and it geolocates to the country you paid for. Then the site still serves you the home-language version, and a login from an unfamiliar city shows up in the account history two days later.

The tunnel is not broken. SOCKS5 is a connect verb over a byte pipe — it carries exactly the traffic you hand it, from the process you configured. Name resolution is a separate conversation, and it habitually happens outside that pipe.

One byte decides where the lookup happens

RFC 1928 defines a single request type that matters here. The client asks the proxy to open a TCP connection to a destination, and the destination is encoded in the ATYP field:

ATYP=0x01 — a raw IPv4 address. The client already resolved the name itself, so the DNS query left through the machine's own resolver before the tunnel was ever involved.
ATYP=0x03 — a domain name. The client hands over the hostname and the proxy resolves it on the exit side.
ATYP=0x04 — an IPv6 address, with the same consequence as 0x01.

So "SOCKS5 is configured" covers two different behaviours, decided by one byte set by a library flag most people never read.

Who resolves the name, by client

Client and setting	ATYP sent	Resolver actually used	Leaks
`curl --socks5`	0x01	local stub resolver	yes
`curl --socks5-hostname`	0x03	proxy egress	no
PySocks, `rdns=False` (default)	0x01	local stub resolver	yes
PySocks, `rdns=True`	0x03	proxy egress	no
Chromium `--proxy-server=socks5://`	0x03	proxy egress	only via DoH or bypass
OS-wide TUN on a router	n/a	whatever the host emits	depends on port 53

The two curl flags look interchangeable and are not. A scraper moved from --socks5-hostname to --socks5 keeps working perfectly while quietly publishing every hostname it visits.

Three escape paths that survive a working tunnel

The client resolves locally. This is the common case; most HTTP libraries default to it. Nothing about the exit looks wrong afterwards — the IP and the ASN are correct — but a resolver upstream logged every domain.

UDP port 53 never enters the tunnel. A SOCKS5 CONNECT is TCP-only. Plain DNS over UDP is simply not carried, so an app-level proxy setting leaves the system resolver untouched. UDP ASSOCIATE exists for this, but support on the proxy side is uneven and most clients never request it.

Split tunneling on a network-level tunnel. L2TP with default-gateway routing disabled, or a TUN interface with a bypass list, sends the resolver query out of the physical interface while the browser still shows the remote address. The tunnel is up; one route is wrong.

Symptom to cause to fix

What you observe	What it means	What actually fixes it
Exit IP correct, site language still local	names resolved locally (`ATYP=0x01`)	switch the client to remote resolution
Proxy on, unrelated apps still resolve	app-level scoping only	drop or redirect outbound 53 at the gateway
Tunnel up, leak test shows home resolver	split tunneling	restore default route, push DNS to the tunnel
Fixed by restarting the browser only	resolver or browser cache	flush, then retest with a fresh hostname

The fourth row is worth sitting with. A test run right after a fix can measure the state before the fix.

Proving it with 20 lines

This performs the handshake by hand and sends ATYP=0x03, which delegates resolution to the exit. Run it against a hostname that only the exit can resolve, then block outbound port 53 and run it again.

import socket, struct

def socks5_connect_domain(proxy, pport, host, dport):
    s = socket.create_connection((proxy, pport), timeout=8)
    s.sendall(b"\x05\x01\x00")                  # VER, NMETHODS, NO-AUTH
    if s.recv(2) != b"\x05\x00":
        raise OSError("method negotiation failed")
    name = host.encode("idna")
    req = b"\x05\x01\x00\x03" + bytes([len(name)]) + name + struct.pack(">H", dport)
    s.sendall(req)                              # ATYP=0x03: exit resolves
    rep = s.recv(4)
    if len(rep) < 4 or rep[1] != 0:
        raise OSError("SOCKS5 reply code %s" % (rep[1] if len(rep) > 1 else "short"))
    return s

If the second run still connects while socket.getaddrinfo() for the same name fails, your names are being resolved inside the tunnel — that is the behaviour you want, and it is now measured rather than assumed.

Mistakes that keep the leak alive

Treating a browser proxy extension as an operating-system setting. It is not; every other process keeps its own path out.
Copying --socks5 instead of --socks5-hostname into a scraper template, then wondering why the exit logs look clean and the target still localises you.
Enabling DNS over HTTPS to "solve" leaks while DoH is pinned to a provider outside the tunnel. The query moved; it did not move into the pipe.
Believing the leak-test page, when that page was itself loaded through the proxy. Test from the machine's own stack with port 53 blocked.
Ignoring negative caching and TTLs, then re-testing inside the same minute and reading a stale answer as a regression.

FAQ

Does SOCKS5 carry DNS at all?
Yes, through ATYP=0x03 for TCP destinations, and through UDP ASSOCIATE if the proxy implements it. Neither is automatic — the client has to choose it, which is why library defaults matter more than the proxy vendor.

Is DNS over HTTPS a fix?
It relocates the resolver, and whether that relocation is inside the tunnel depends entirely on where DoH is configured. Configured inside the proxy scope it helps; configured on the device with a bypass list it is another exit path.

Port 53 is blocked but names still resolve. Why?
Something is answering without a network query: a stub resolver cache, a browser's own resolver, or a DoH endpoint over 443. Flush, use a hostname never queried before, and repeat.

Does this affect API clients and scrapers, not just browsers?
It affects them more. Browsers usually delegate hostnames correctly; Python, Go and Node clients often resolve locally by default, and their traffic never looks different from the outside.

Where this sits in a proxy stack

Resolution policy is a property of the client, not of the exit, so a clean IP reputation and a correct tunnel still leave one path open until the client is configured to delegate. The DNS leak detection walkthrough on socks5ip.com.cn covers the per-platform fixes, and the IP check centre confirms what the exit actually looks like to the outside before you go chasing resolver behaviour.

Measure the path, then fix one layer at a time. A tunnel that carries the names is worth more than a larger pool of addresses.

Region Locks Are Not IP Locks: What a Proxy Actually Changes for Overseas Game Clients

全网低价IP — Mon, 26 Oct 2026 02:04:26 +0000

You buy a residential exit in the right country, log in, and the client still greets you in the wrong language. The store prices in the wrong currency, matchmaking drops you into the wrong pool, and a verification prompt appears two sessions later.

The instinct is to blame the exit. Usually the exit is doing exactly what you paid for. A game client does not consult a single "region" — it reads four different signals, and a proxy only writes to one of them.

Four signals, one of which you control

IP geolocation at the edge. The publisher queries a commercial geo database with your exit address. This is the only signal your proxy rewrites directly — and it rewrites it in their vendor's database, which may not agree with the lookup tool you used.

Store and account country. Fixed when the account was created or by the issuing country of the payment instrument on file. This is an account attribute, not a network one, so no amount of re-routing moves it.

Measured latency. Matchmaking picks a datacenter by round-trip time, not by the country string in your IP record. A block registered in Frankfurt that tunnels traffic back to Singapore measures like Singapore.

Behavioural history. Login countries, device IDs, time-of-day patterns. This one only degrades when you change exits — it never improves by changing them.

Signal	Source of truth	Does swapping the exit IP change it?
IP geolocation	Publisher's geo vendor	Yes — but only in their view of the address
Store/account country	Account creation, payment instrument	No
Matchmaking pool	RTT measured to datacenter	Partly — by physics, not by registration
Trust score	Login history, device fingerprint	No, and it usually gets worse

Why the store region stays put

Most storefronts bind purchase region to the country of the payment method, because that is the field with a bank behind it. Your IP is a hint; the card's issuing country is a fact.

This is why "buy a local IP, get local prices" fails so consistently. The store accepts the new IP and then declines the purchase because the instrument does not match the region you switched into.

Console ecosystems are stricter still: the account's country is chosen at creation and changing it typically requires a local payment method plus a support path. A proxy is not part of that flow at all.

Audit instead of guessing

Measure two things from the same machine: what the exit looks like to a geo database, and how far the traffic actually travels. If the country says "close" and the RTT says otherwise, the block is resold or tunnelled.

import socket, time, json, urllib.request

TARGETS = {"steam": ("store.steampowered.com", 443),
           "riot-na": ("na.leagueoflegends.com", 443)}

def rtt(host, port, n=3):
    best = None
    for _ in range(n):
        s = socket.socket(); s.settimeout(3); t = time.perf_counter()
        try:
            s.connect((host, port))
            d = (time.perf_counter() - t) * 1000
            best = d if best is None else min(best, d)
        except OSError:
            pass
        finally:
            s.close()
    return None if best is None else round(best, 1)

def exit_info():
    with urllib.request.urlopen("https://api.ipapi.is/", timeout=8) as r:
        d = json.loads(r.read())
    return d.get("location", {}).get("country"), d.get("asn", {}).get("org")

print("exit:", exit_info())
for name, (h, p) in TARGETS.items():
    print(f"{name:9s} {rtt(h, p)} ms")

Read the pair together, not separately. A US-registered exit measuring 190 ms to a US endpoint is not in the US — the announcement is American, the packet path is not. A non-US-registered exit measuring 20 ms to a US endpoint is where it claims not to be, and the game will still see the wrong country, because the edge lookup runs before any latency measurement.

Symptom	Likely cause	What actually fixes it
Store keeps old currency	Purchase region bound to payment instrument	Local payment method; a new account in-region
Country correct, RTT 150 ms+	Resold block tunnelled back to origin	An exit with genuine local egress
Verification prompt after switch	Login country jumped between sessions	Stable exit per account; match prior country first
Matchmade into the wrong pool	Matchmaker uses its own RTT probe	Exit nearer the datacenter, not "nearer the country"
Worked for weeks, then dead	Block re-classified as hosting or VPN	Rotate exits and re-check purity before reusing

Five mistakes worth avoiding

Judging an exit by a country string alone. Run the RTT probe; the string is a database opinion.
Forcing a store region with a foreign card. You get declines, and in some cases a frozen account.
Changing exit mid-session. Logging in from one country and purchasing from another ten minutes later is the pattern fraud systems are built to catch.
Assuming SOCKS5 handles game traffic. TCP works everywhere; most titles also need UDP, and UDP relay (RFC 1928 UDP ASSOCIATE) is optional and unevenly implemented by both proxies and clients.
Treating a fixed exit as a permanent asset. Residential blocks get reclassified. Re-audit monthly, not once.

FAQ

Does a proxy change my game store region?
No. The store region is an account attribute tied to your payment instrument's issuing country. The proxy changes which country the store thinks you are browsing from, which affects pricing display and availability in some cases, but it does not rewrite the purchase region itself.

Why is my ping unchanged after switching to a "local" IP?
Because ping measures the packet path, not the registration record. If the block is announced locally but tunnels back to another continent, RTT reflects the tunnel. Check the pair — country and RTT — before concluding the proxy is slow.

Can I play over SOCKS5?
For TCP-based traffic, yes. Many games and nearly all voice chat need UDP, which requires the proxy to support UDP ASSOCIATE and the client to implement it. A router-level setup or a client with a UDP relay path is usually more reliable than a browser-style SOCKS5 proxy.

Will switching countries flag my account?
It can. Rapid country changes on an established account are a recognisable pattern, and the response is usually a verification challenge rather than a ban. Keep one stable exit per account and change countries deliberately, not casually.

Region selection is really a consistency problem: the exit, the account, and the measured path have to tell the same story. The guide to region-based IP selection for overseas game clients covers the selection side in more depth, and the proxy knowledge base covers exit types and protocol choices.

Why Three Geo-IP Databases Give Three Answers for the Same Address

全网低价IP — Thu, 22 Oct 2026 02:20:50 +0000

Ask three free lookup services where an address is and you will often get three answers: one says the city, one says the province capital, one says the country and nothing more. A tool flags the address as a crawler; the ISP's own whois says consumer line.

This is not a bug in any single service. "Geo-IP" names three different datasets that happen to share an output format, and most disagreements come from comparing the wrong one. Knowing which layer answered turns a confusing result into a diagnosis.

Three layers, three sources of truth

Registration data comes from RIR records — who holds the block, which country it was allocated in. Authoritative for the holder, weak for the user: a block allocated to a German subsidiary can be routed to Singapore tomorrow.

Routing data comes from BGP: which ASN announces the prefix, and where peers see it. It tells you where traffic physically lands, and it responds within hours to a network change.

Observed data comes from panels that record where real users of that address appear. Most accurate for consumer geography, slowest to update — a static residential IP that changes hands can keep its old city for months.

Layer	Owner of the truth	Typical failure
Registration (whois/RDAP)	RIR	Block allocated in one country, operated in another
Routing (BGP/ASN)	Network operator	Anycast: one prefix, many locations
Observed (panel-based)	Data vendor	Thin samples, stale history, over-generalised centroids

A vendor's answer is usually a blend, weighted by what its own customers observed. That weighting is proprietary, which is why two vendors disagree and both claim 99% accuracy.

Why the answers diverge

Anycast. A CDN prefix is announced from dozens of sites. Which one your lookup resolves to depends on where the query comes from, not where the address is.

Registration lag. Blocks are re-allocated faster than databases update: a /24 sold to a hosting provider in March may still read as a residential ISP in June.

Country-level fallback. With no city-level confidence, a vendor returns the country centroid — a specific coordinate that looks precise and means nothing. In testing, some services return the same national coordinate for every address in a country while still reporting the correct region name.

Heuristic side effects. Provider-maintained "datacenter" lists are the worst offender: they are built from ASN lists, and ASN lists leak. In our own spot checks, one widely copied list included 16 Chinese carrier ASNs, which misclassifies consumer lines wholesale. A lookup that says "datacenter" often means "someone's ASN list says so", not "this is a server".

Make the disagreement measurable

Query three independent sources and compare country, region, and city separately; aggregate agreement hides the case where all three agree on country and none on city.

import json, urllib.request

SRC = {
    "ipapi.is": "https://api.ipapi.is/?q={ip}",
    "ip.sb":    "https://api.ip.sb/geoip/{ip}",
    "ipinfo":   "https://ipinfo.io/{ip}/json",
}

def look(ip):
    out = {}
    for name, tpl in SRC.items():
        try:
            req = urllib.request.Request(tpl.format(ip=ip),
                                         headers={"User-Agent": "geo-probe/1.0"})
            with urllib.request.urlopen(req, timeout=8) as r:
                d = json.loads(r.read())
            out[name] = (d.get("country") or d.get("country_code"),
                         d.get("region"), d.get("city"),
                         d.get("is_datacenter") or d.get("org", "")[:24])
        except Exception as e:
            out[name] = ("ERR", type(e).__name__, "", "")
    return out

for ip in ["1.1.1.1", "8.8.8.8"]:
    print(ip, look(ip))

Run it against addresses you already know, not random ones: you need a control. If one source is the outlier on the same field across every address, its dataset is stale for your region — not merely imprecise.

Reading the disagreement

Symptom	Likely layer at fault	What to trust
Country differs	Anycast or BGP change	Routing data, checked today
Region correct, city is a national centroid	Observed data with country fallback	Region name; discard coordinates
Country/region right, "datacenter" flag wrong	Provider ASN heuristic	ASN holder type from RDAP, not the flag
Everything right except ISP name	Registration lag after re-allocation	Routing data (ASN) again
Different answer per request	Load-balanced vendor backends	Pin one endpoint for reproducibility

Two rules follow. Never mix fields from different sources in one decision — country from vendor A and city from vendor B is how a consistent result becomes inconsistent. And record which vendor answered: a comparison with unknown provenance is unreproducible.

Five mistakes worth avoiding

Treating country-centroid coordinates as data. If region is right and city is the capital of a huge country, the coordinates are a placeholder.
Trusting a "datacenter" boolean over the ASN. The flag is a list lookup; the ASN is a fact.
Comparing vendors at different times. Datasets update weekly; a run from last month is a different experiment.
Judging a proxy by one lookup. Check it against the platform you target.
Assuming a mismatch means the proxy is bad. Often the database is late and the session is healthy.

FAQ

Which database should I trust for a proxy exit?
None single-handedly. Use routing data (ASN, prefix) to establish what the exit is, and observed data to establish where the platform thinks it is. When they conflict, the platform's vendor decides your outcome — even when it is wrong.

Why does one service report a precise city and another only a country?
Precision is a claim about confidence, not an extra fact. Services with thin panel data fall back to country centroids and label them as cities; the coordinate looks exact but is a national placeholder.

Can a residential IP be flagged as a datacenter?
Yes, regularly. The usual cause is a provider-maintained ASN list that includes carrier blocks, or a hosting reseller announcing consumer space. Check the ASN holder type first.

Does geolocation affect whether an account gets flagged?
Indirectly. Platforms score consistency: the region your session claims must match the region your exit resolves to in their database. An accurate IP their vendor misplaces is still a mismatch to them, which is why the fix is a different exit, not a better lookup tool.

Reading query results correctly matters most when a proxy "looks wrong" but behaves fine — the note on why router-level IP lookups report crawlers covers those false positives, and the proxy knowledge base covers exit selection generally.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Any account, group, or site claiming to be our "official" contact — including phone numbers or WeChat IDs that appear in third-party posts and listings — is not operated by us. Please do not send payment or account credentials to channels that are not in the list above.

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

How to Audit a Proxy Vendor's Numbers Before You Pay

全网低价IP — Mon, 19 Oct 2026 02:07:21 +0000

Every proxy vendor sells the same three sentences: a pool size in the millions, an uptime figure with a decimal point, and the word "residential". None are measured by anyone except the vendor. Two can advertise five million IPs while one hands you the same four hundred addresses all week.

The useful skill is not picking the better-sounding vendor, but turning a claim into a number your script can falsify.

Pool size means at least four different things

"5M IPs" can mean any of these, with a gap of two orders of magnitude between them:

Cumulative addresses ever seen — everything routed since launch, often already burned.
Unique addresses served per hour — closer to reality, still inflated by churn.
Concurrent addresses available now — the pool you can draw from while sessions live.
Distinct /24 blocks and ASNs — the only figure that predicts whether two sessions look like neighbours.

Only the last two change outcomes: a million addresses inside forty ASNs is a smaller pool than twenty thousand spread across four thousand, if your problem is correlation rather than volume.

What to measure, and how to falsify it

Vendor claim	Number that actually constrains you	How to falsify it
"Millions of IPs"	Unique exits per hour, distinct /24s	Sample 200 sessions, count distinct IPs and prefixes
"99.9% uptime"	Success rate of a full request, not a TCP connect	Fetch a small payload through the proxy, score HTTP 200
"Residential"	ASN class of the exit, not the product name	Resolve each exit IP to its ASN and check the holder type
"Unlimited concurrency"	Success rate as you raise parallel sessions	Ramp 4 → 16 → 64 workers, watch failure mode
"Fast nodes"	Time to first byte of a real request	Time the request body, not a ping

Measure the end-to-end operation: a 40 ms handshake proves nothing about a request that dies at TTFB.

A harness small enough to trust

Standard library only. It reads host:port lines, performs a real SOCKS5 handshake, requests a plain-text echo endpoint, and records the exit IP, latency, and prefix key. Concurrency stays low on purpose: hammering a trial endpoint is the fastest way to get your test IP blocked.

```pythonimport socket, struct, time
from concurrent.futures import ThreadPoolExecutor

def socks5_get(ep, host="api.ipify.org"):
h, p = ep.split(":")
t0 = time.time()
s = socket.create_connection((h, int(p)), timeout=8)
s.sendall(b"\x05\x01\x00") # greeting: no auth
if s.recv(2) != b"\x05\x00":
raise OSError("method rejected")
q = host.encode()
s.sendall(b"\x05\x01\x00\x03" + bytes([len(q)]) + q + struct.pack(">H", 80))
rep = s.recv(4)
if rep[1]:
raise OSError("connect failed rep=%d" % rep[1])
s.recv({1: 4, 4: 16}.get(rep[3], s.recv(1)[0] + 1) + 2) # drain BND.ADDR
s.sendall(("GET / HTTP/1.1\r\nHost: %s\r\nConnection: close\r\n\r\n" % host).encode())
data = b""
while chunk := s.recv(4096):
data += chunk
s.close()
ip = data.rsplit(b"\r\n\r\n", 1)[-1].decode().strip()
return {"exit": ip, "ms": round((time.time() - t0) * 1000),
"prefix": ".".join(ip.split(".")[:3])}

def one(ep):
try:
return socks5_get(ep)
except Exception as e:
return {"exit": None, "err": type(e).name} # failures are data

eps = [l.strip() for l in open("proxies.txt") if l.strip()]
with ThreadPoolExecutor(max_workers=4) as pool:
rows = [r for r in pool.map(one, eps) if r.get("exit")]




Write every row to JSONL as you go: a sample you cannot re-analyse is one you pay for twice.

## Designing the sample so the result means something

**Sample across time, not once.** Run the harness in three windows (morning, evening, late night in the target market's timezone). Vendors oversubscribe; the 03:00 pool is not the 21:00 pool.

**Size the sample for the claim under test.** Two hundred attempts give a success rate with a ±6 point confidence interval — enough to separate 85% from 98%, useless for 98.5% versus 99.3%. The second decimal is unverifiable in an afternoon; price it as such.

**Count unique exits, not requests.** The ratio of distinct exit IPs to successful requests is the most diagnostic number in the sample. Below 0.5 you are buying a static pool dressed up as rotating; near 1.0 with high ASN diversity, the claim has substance.

## Reading the result

| Observation | Likely cause | What to do |
|---|---|---|
| High connect success, low request success | Exit rate-limited or gateway swapping mid-session | Re-test with sticky sessions; read refund terms |
| Distinct exits high, distinct /24s low | Single-housing provider | Judge by correlation risk, not pool size |
| Failure rate rises sharply above 16 workers | Undisclosed concurrency cap | Price the real concurrent capacity |
| HTTP 403 only on the target site | Target-side fingerprinting, not proxy health | Change exit class, not vendor |

None of these verdicts need the vendor's cooperation, and all fit a diffable JSONL file.

## Five mistakes that invalidate the test

1. **Measuring at one in the morning.** Low-load conditions flatter every provider.
2. **Counting retries as successes.** Log the first attempt separately or your uptime figure is fiction.
3. **Using ping instead of a payload.** ICMP never touches the exit's egress path or rate limiter.
4. **Not recording the exit IP.** Round-robin pools then hide dead nodes behind good results.
5. **Testing against a site that blocks datacenter ranges.** You measure its policy, not vendor quality.

## FAQ

**How many endpoints do I need for a trustworthy audit?**
Two hundred attempts per window is a practical floor; below fifty, one bad node swings the average by several points. Sample randomly, not the first N entries.

**Does a failed handshake always mean a dead proxy?**
No. `REP=0x05` usually means the destination is blocked from the exit, while a greeting-stage timeout points at the proxy itself — which tells you whether to ask for a new node or a new region.

**Can I audit a vendor without buying first?**
Usually yes; most offer trial credit. Spread the sample across the window rather than spending it in ten minutes, and keep the JSONL so later tests stay comparable.

**What if the numbers are simply unverifiable?**
Treat them as absent and decide on what you can measure: request success and exit diversity. A provider that will not let you sample either has answered the question for you.

If you want this audit applied to concrete platforms — IP class, tool pairing, and which vendor fits cross-border marketing versus multi-account work — the [2026 proxy IP evaluation on socks5ip.com.cn](https://socks5ip.com.cn/zuixinzixun/jingxuanzixun/2026niandailiippingce/) walks through the comparison per scenario, and its [proxy knowledge base](https://socks5ip.com.cn/daili-ip-zhishiku/) covers the underlying concepts.

---

### Official contact channels (anti-impersonation)

**全网低价IP (socks5ip.com.cn)** is a proxy-IP **aggregation and price-comparison** site — we are **not** any provider's official website, and we do not resell accounts.

- **Support WeChat**: `17720135827` (primary)
- **Backup WeChat / QQ**: `878989347`
- **User group**: `1045307809`
- **Email**: `878989347@qq.com`

Any account, group, or site claiming to be our "official" contact — **including phone numbers or WeChat IDs that appear in third-party posts and listings** — is not operated by us. Please do not send payment or account credentials to channels that are not in the list above.

Signup links **with our invite codes** for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): <https://socks5ip.com.cn/provider-contacts.md>

Low Latency or High Anonymity? Choosing SOCKS5 IPs for Game Multi-Boxing

全网低价IP — Thu, 15 Oct 2026 02:04:11 +0000

Every multi-boxing setup eventually hits the same fork in the road. The boxes lag, so you go looking for lower latency. The accounts get linked, so you go looking for better anonymity. Then you find that both properties are delivered by the same IP pool, and the vendor's "premium" tier is fast while the "residential" tier is clean — never both at once.

That framing is wrong, and it costs people money. Latency and anonymity are not two ends of one dial. They sit on different axes, they are degraded by different mechanisms, and you can keep more of each than the vendor tiers imply — once you know which one your workload actually punishes.

What each property really means

Anonymity is about what the far side can infer from a connection. Only a few levels matter in practice: the proxy announces your real IP (transparent), announces it is a proxy but hides you (anonymous), or presents as an ordinary residential client with no proxy header and an exit that matches a real ISP (elite). Most "high anonymity" marketing maps to the last bucket.

Latency is not one number either. Three components stack up:

RTT — physical distance and routing quality between you and the exit.
Jitter — the variance of that RTT, which is what actually breaks real-time traffic.
Handshake cost — TCP plus the SOCKS5 negotiation, paid once per new connection.

A route averaging 30 ms with 40 ms swings plays worse than a stable 60 ms route. Vendors quote averages because averages sell; your game feels jitter.

Where the trade-off actually bites

Requirement	What it constrains	What it does not constrain
Low RTT	Exit location, peering quality	Anonymity level
Low jitter	Route stability, hop count, exit load	Exit geography
Elite anonymity	ISP class of the exit, absence of proxy headers	Throughput
Many boxes	Independent exits across subnets	Latency, directly

The last row is the important one. Multi-boxing fails on correlation, not on raw speed — and correlation comes from shared subnets, shared ASNs, and shared session timing, not from latency.

Measure before you buy

You cannot trade away the right property until both numbers are known. This stdlib-only probe times TCP connect plus the SOCKS5 negotiation separately, so a slow result can be attributed rather than guessed:

import socket, statistics, time

HOST, PORT, USER, PWD = "203.0.113.10", 1080, "u", "p"

def socks5_probe(rounds=10):
    lat = []
    for _ in range(rounds):
        t0 = time.perf_counter()
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(b"\x05\x02\x00\x02")                  # greeting: offer user/pass
        if s.recv(2) != b"\x05\x02":
            s.close(); continue
        s.sendall(b"\x01" + bytes([len(USER)]) + USER.encode()
                  + bytes([len(PWD)]) + PWD.encode())   # RFC 1929 auth
        if s.recv(2)[1] != 0:
            s.close(); continue
        host = b"api.ipify.org"
        s.sendall(b"\x05\x01\x00\x03" + bytes([len(host)]) + host
                  + b"\x01\xbb")                        # CONNECT :443
        s.recv(10)                                      # reply: BND.ADDR
        lat.append((time.perf_counter() - t0) * 1000)
        s.close()
    import statistics as st
    jitter = st.stdev(lat) if len(lat) > 1 else 0.0
    print("n=%d median=%.1fms jitter=%.1fms" % (len(lat), st.median(lat), jitter))

socks5_probe()

Three signals matter: a median inside your game's tick budget, a jitter figure smaller than that budget, and a stable exit. If the exit IP moves under you, no latency number is worth anything — your sessions are being correlated by rotation you never asked for.

Choosing by workload

Workload	Prioritise	Safe to give up
Single real-time session	Jitter	Everything else
Many boxes, one market	One distinct exit per box	Remote geography
Emulator farm, unattended	Exit diversity over speed	Lowest RTT

Chain the decision instead of averaging it: pick the anonymity tier first, because it fixes the exit pool; choose exits inside that tier by jitter; then verify with the probe above.

Five mistakes that cost the most

Buying "high anonymity" for a latency problem. If boxes lag, a cleaner IP changes nothing.
Judging a route by average RTT. Measure jitter — that is what breaks input.
Assuming different IPs mean independence. Ten addresses in one /24 are one neighbourhood.
Letting the pool rotate mid-session. An exit change during a login is a red flag.
Testing once and trusting forever. Routes degrade; probe on a schedule.

FAQ

Is a datacenter IP ever acceptable for multi-boxing?
Yes, where the far side does not profile connection origin — internal tooling, testing, non-account traffic. For account-bearing sessions, expect ISP class to be one of the scored signals.

Does lower latency mean less anonymity?
No. They are independent. Low-latency exits exist in every ISP class; the trade-off is commercial — clean exits are scarcer and priced higher — not physical.

How many exit IPs do I need for N boxes?
At least N, spanning multiple /24s and ideally multiple ASNs. Reusing one address across two boxes undoes the isolation you just paid for.

Can I improve both at once?
Partly. A closer, well-peered exit improves RTT and jitter together, and choosing elite-tier exits within that pool keeps anonymity. What no upgrade fixes is jitter, by adding a cleaner IP.

If you are assembling a domestic multi-boxing setup and want this tier logic mapped onto concrete platforms and tool pairings, the full guide on choosing low-latency vs high-anonymity IPs for game multi-boxing walks through the same decision with platform comparisons and per-genre recommendations. The measurement method above is what makes either choice verifiable rather than a guess.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

Proxy Pool Health Monitoring: Turning "It Works" into Metrics You Can Act On

全网低价IP — Mon, 12 Oct 2026 02:18:16 +0000

Most proxy pools die quietly. Nothing throws an exception, and one morning a third of your requests time out while the dashboard still says 200 OK — because a scraper that retries three times and finally succeeds looks identical to one that never had a problem.

That is the real failure mode: you are measuring your application, not your infrastructure.

Why "it works" is not a health check

A ping is not a proxy check, and neither is a TCP connect. What you need is whether a complete, correctly authenticated protocol exchange can carry traffic now — and how fast:

Layer	What breaks	A naive check reports
Network	Host unreachable, port filtered	Down (correct)
TCP	Port open, no service behind it	Up (wrong)
Protocol	Handshake rejected, bad credentials	Up (wrong)
Identity	Exit IP moved, or is not where you expect	Up (wrong)
Capacity	Handshake fine, throughput collapsed	Up (wrong)

Only the first row is caught by a ping — which is why a pool reporting "100% alive" can still cost you a day.

The five metrics that matter

Track these per endpoint, not per pool — averages hide the endpoints you need to evict.

Metric	Definition	Why it earns its place
Handshake latency	Time to complete protocol negotiation	Earliest sign of congestion
Rolling success rate	Successes / attempts over last N runs	Catches flapping, not just hard down
Exit IP stability	Did the observed exit IP change	Detects rotation you did not ask for
Exit IP correctness	Is the exit in the expected region and ASN	Catches silent rerouting
Throughput	Bytes per second on a fixed transfer	Catches "connected but useless"

Latency alone is not enough: a common trick is an endpoint that handshakes in 40 ms and then delivers 30 KB/s — the metric looks great while your pipeline stalls.

Measuring it with stdlib Python

You do not need a framework — a socket, a timer, and a small request are the whole check. The SOCKS5 version, following RFC 1928:

import socket, struct, time

def socks5_check(host, port, user=None, pwd=None, timeout=8.0):
    """Return (ok, handshake_ms, error)."""
    t0 = time.perf_counter()
    try:
        s = socket.create_connection((host, port), timeout=timeout)
    except OSError as e:
        return False, None, 'tcp:%s' % e
    try:
        s.sendall(b'\x05\x02\x00\x02' if user else b'\x05\x01\x00')
        ver, method = s.recv(2)
        if ver != 5 or method == 0xFF:
            return False, None, 'no acceptable auth method'
        if method == 0x02:                        # RFC 1929 user/pass exchange
            u, p = user.encode(), pwd.encode()
            s.sendall(b'\x01' + bytes([len(u)]) + u + bytes([len(p)]) + p)
            if s.recv(2)[1] != 0x00:
                return False, None, 'auth rejected'
        # CONNECT 1.1.1.1:443 -> reply VER REP RSV ATYP BND.ADDR BND.PORT
        s.sendall(b'\x05\x01\x00\x01' + socket.inet_aton('1.1.1.1') + struct.pack('!H', 443))
        rep = s.recv(10)[1]
        if rep != 0x00:
            return False, None, 'REP=0x%02x' % rep
        return True, (time.perf_counter() - t0) * 1000, None
    except (OSError, IndexError) as e:
        return False, None, 'handshake:%s' % e
    finally:
        s.close()

The timing wraps the entire exchange, not just connect() — that is what makes it a metric about the proxy rather than the network. And the structured error string matters: when half the pool fails at once, tcp: versus REP=0x05 separates a routing incident from a credentials incident.

To verify the exit IP, reuse the socket after the handshake: send GET / HTTP/1.1 with Host: api.ipify.org and read the body. A stable exit IP is a feature you pay for; a changing one is either a documented rotating product or a misconfiguration.

Thresholds worth alerting on

Absolute latency means little without your route, so set thresholds against a rolling per-endpoint baseline:

Signal	Condition	Action
Latency drift	p95 > 2× 7-day baseline	Warn — usually congestion
Success rate	< 95% over last 20 runs	Quarantine the endpoint
Consecutive failures	3 in a row	Evict from the active set
Exit IP change	Any change outside a maintenance window	Warn, verify it is intended
Throughput	< 50% of baseline for 3 runs	Demote; keep alive but deprioritize

The key word is quarantine, not delete. Keep a failing endpoint in a slow retry lane so it can re-earn its place — endpoints that fail during a maintenance window come back; endpoints that fail for three days do not.

Common mistakes

1. Checking the pool average instead of per endpoint. A pool at 90% success looks healthy until you notice all 10% of failures are the same three endpoints serving your most important account.

2. Only testing on failure. A check that runs when the pipeline breaks is a debugger, not a monitor. Run it on a schedule independent of traffic.

3. Treating one failure as death. Transient packet loss is real, so require a few consecutive failures before evicting.

4. Ignoring time of day. Your provider's peak hours are not yours, so compare like with like.

5. Forgetting the identity layer. Latency and success rate say nothing about whether the exit is still in the country you need. Check exit IP, region, and ASN together.

6. One aggressive probe. A tight loop looks like an attack and gets your IP rate-limited. Space your probes and rotate your sample.

FAQ

How often should I probe each endpoint?
A rolling sample every 2-5 minutes is plenty for a pool in the dozens. Probing everything every 30 seconds buys nothing and looks abusive.

What success rate should I target?
For a static pool, 95% over a 20-run window is a reasonable floor. For rotating pools expect lower and push the burden onto bounded per-request retries.

Does a failed UDP check mean the proxy is broken?
Usually not. Most SOCKS5 and HTTP proxy products do not forward UDP at all, so for HTTP or TCP workloads a UDP failure is expected.

How do I know a high-latency endpoint is actually bad?
Measure throughput, not just handshake time. Some endpoints negotiate fast and then collapse on bulk transfer; a fixed-size transfer test on a small slice of the pool surfaces them.

Where to go next

The signals above match what our public checking tools expose — a reference to compare your script against:

Proxy line availability tester (SOCKS5/HTTP handshake, latency grading, exit IP geolocation) — https://socks5ip.com.cn/zuixinzixun/zonghejiaocheng/dailiipcesugongjushiyongzhinan/
IP quality check center (residential vs datacenter, purity signals) — https://socks5ip.com.cn/ip-check-center/
Full platform comparison, one page per provider — https://socks5ip.com.cn/dailiip-jiage-duibi/

Measure first, then buy. A pool whose health you can see beats a slightly cheaper pool you have to guess about.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

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.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

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.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

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.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

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.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

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.

Official contact channels (anti-impersonation)

全网低价IP (socks5ip.com.cn) is a proxy-IP aggregation and price-comparison site — we are not any provider's official website, and we do not resell accounts.

Support WeChat: 17720135827 (primary)
Backup WeChat / QQ: 878989347
User group: 1045307809
Email: 878989347@qq.com

Signup links with our invite codes for 24 platforms, plus each platform's support channel (CC0-1.0, free to quote): https://socks5ip.com.cn/provider-contacts.md

DEV Community: 全网低价IP

Concurrency, Connections, Threads: Which Number Your Proxy Plan Actually Meters

Four terms, three layers

Threads are yours; concurrency is theirs

Extraction frequency is a rhythm, not a capacity

Measure your own ceiling

Five mistakes that cost a tier upgrade

FAQ

Where to verify the numbers

Your SOCKS5 Proxy Works Fine. Your DNS Is What Leaks the Location.

One byte decides where the lookup happens

Who resolves the name, by client

Three escape paths that survive a working tunnel

Symptom to cause to fix

Proving it with 20 lines

Mistakes that keep the leak alive

FAQ

Where this sits in a proxy stack

Region Locks Are Not IP Locks: What a Proxy Actually Changes for Overseas Game Clients

Four signals, one of which you control

Why the store region stays put

Audit instead of guessing

Five mistakes worth avoiding

FAQ

Why Three Geo-IP Databases Give Three Answers for the Same Address

Three layers, three sources of truth

Why the answers diverge

Make the disagreement measurable

Reading the disagreement

Five mistakes worth avoiding

FAQ

Official contact channels (anti-impersonation)

How to Audit a Proxy Vendor's Numbers Before You Pay

Pool size means at least four different things

What to measure, and how to falsify it

A harness small enough to trust

Low Latency or High Anonymity? Choosing SOCKS5 IPs for Game Multi-Boxing

What each property really means

Where the trade-off actually bites

Measure before you buy

Choosing by workload

Five mistakes that cost the most

FAQ

Official contact channels (anti-impersonation)

Proxy Pool Health Monitoring: Turning "It Works" into Metrics You Can Act On

Why "it works" is not a health check

The five metrics that matter

Measuring it with stdlib Python

Thresholds worth alerting on

Common mistakes

FAQ

Where to go next

Official contact channels (anti-impersonation)

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

Official contact channels (anti-impersonation)

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

Official contact channels (anti-impersonation)

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

Official contact channels (anti-impersonation)

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

Three decisions, in order

Use case → exit type

Mapping `REP` codes to real problems