DEV Community: Mathew

Proxy Bandwidth Checker: How to Measure Speed and Verify Billing Accuracy in 2026

Mathew — Wed, 22 Jul 2026 03:42:46 +0000

Proxy bandwidth billing is one of those areas where the number on your dashboard and the traffic you actually used can quietly diverge. A provider that rounds up to the nearest MB per request, counts TLS handshake overhead as metered traffic, or charges for failed and timed-out requests will show higher consumption than your actual payload transfer — and that gap compounds at scale.
This guide covers how to measure real proxy throughput and verify billing accuracy using command-line tools, Python, and a no-code online checker. The benchmark table at the end gives you a reference point across provider tiers so you know what numbers to expect before you start testing.
What "Bandwidth" Actually Means on a Metered Proxy Plan
On a per-GB proxy plan, bandwidth refers to the volume of data transferred through the proxy tunnel. But what counts toward that volume varies by provider, and the differences are significant enough to affect your cost per operation by 15–30% in some cases.
The main billing variables to watch for:
Payload-only billing counts the bytes of the actual HTTP response body — the content you requested. This is the most accurate method from the user's perspective.
Full request/response billing counts headers, handshake bytes, and protocol overhead in addition to the response body. A 1 MB payload request might consume 1.05–1.15 MB of metered bandwidth depending on TLS negotiation and header size.
Rounding behavior adds up quickly at scale. Rounding each request up to the nearest KB adds about 0.5 KB per request on average. At 100,000 requests per day, that's 50 MB of phantom consumption daily.
Failed request billing is the most expensive variable. If a proxy request fails — timeout, connection reset, 407 authentication error — some providers still charge for the attempted data transfer. If your failure rate is 5% and you're paying for those failures, your effective cost per successful request is 5% higher than the rate card suggests.
The only way to know how your provider bills is to measure it directly: pull a known payload size through the proxy and compare what you received against what your dashboard reports.
CLI Testing: curl Bandwidth Verification
The fastest measurement is a single curl command with explicit output formatting:

Pull a precisely sized payload through your proxy

Replace user, pass, host, port with your credentials

curl -x http://user:pass@host:port \
-o /dev/null \
--silent \
-w "status: %{http_code}\nbytes_received: %{size_download}\ntime_total: %{time_total}s\nspeed_avg: %{speed_download} B/s\n" \
https://httpbin.org/bytes/10485760

Expected output for a clean 10MB transfer:

status: 200

bytes_received: 10485760

time_total: 3.241s

speed_avg: 3234567 B/s

The critical field is size_download — this is the exact number of bytes your client received. Compare it against the expected payload size (10,485,760 bytes for a 10 MB payload). If they match, the proxy delivered the full payload without truncation or modification.
After running this, check your provider's dashboard and note the bandwidth consumed for this session. If the dashboard shows 11.2 MB consumed for a 10 MB payload pull, the delta represents overhead billing — either protocol overhead, rounding, or both.
Batch test across multiple proxy IPs:

!/bin/bash

Test bandwidth accuracy across a proxy pool

PAYLOAD_MB=50
PAYLOAD_BYTES=$((PAYLOAD_MB * 1024 * 1024))
URL="https://httpbin.org/bytes/${PAYLOAD_BYTES}"

PROXIES=(
"http://user:pass@host1:port"
"http://user:pass@host2:port"
"http://user:pass@host3:port"
)

echo "proxy,status,bytes_received,expected_bytes,time_s,speed_bps"

for PROXY in "${PROXIES[@]}"; do
RESULT=$(curl -x "$PROXY" \
-o /dev/null \
--silent \
--max-time 60 \
-w "%{http_code},%{size_download},${PAYLOAD_BYTES},%{time_total},%{speed_download}" \
"$URL" 2>/dev/null)
echo "$PROXY,$RESULT"
done

Run this across 5–10 IPs from your pool and compare the bytes_received column against expected_bytes. Consistent shortfalls indicate proxy-side content modification. Consistent overages in your dashboard indicate overhead billing.
Python: Throughput and Billing Verification
For integrating bandwidth testing into a workflow or running it on a schedule:
import requests
import time
from dataclasses import dataclass, field
from typing import Optional

@dataclass
class BandwidthResult:
proxy: str
status_code: Optional[int] = None
bytes_received: int = 0
expected_bytes: int = 0
elapsed_s: float = 0.0
throughput_mbps: float = 0.0
delta_pct: float = 0.0
error: Optional[str] = None

def measure_proxy_bandwidth(
proxy_url: str,
payload_mb: int = 50,
timeout: int = 60
) -> BandwidthResult:
payload_bytes = payload_mb * 1024 * 1024
url = f"https://httpbin.org/bytes/{payload_bytes}"
proxies = {"http": proxy_url, "https": proxy_url}
result = BandwidthResult(proxy=proxy_url, expected_bytes=payload_bytes)

start = time.perf_counter()

try:

    resp = requests.get(url, proxies=proxies, stream=True, timeout=timeout)

    result.status_code = resp.status_code

received = 0
for chunk in resp.iter_content(chunk_size=65536):
    received += len(chunk)

result.elapsed_s = round(time.perf_counter() - start, 3)
result.bytes_received = received
result.throughput_mbps = round(
    (received * 8) / (result.elapsed_s * 1_000_000), 2
)
result.delta_pct = round(
    (payload_bytes - received) / payload_bytes * 100, 2
)



except requests.exceptions.Timeout:

    result.error = "timeout"

except Exception as e:

    result.error = str(e)

return result

Run against your proxy list

proxies_to_test = [
"http://user:pass@host1:port",
"http://user:pass@host2:port",
"http://user:pass@host3:port",
]

print(f"{'Proxy':<35} {'Status':>6} {'Received MB':>11} {'Speed Mbps':>10} {'Delta %':>8}")
print("-" * 75)

for proxy_url in proxies_to_test:
r = measure_proxy_bandwidth(proxy_url, payload_mb=50)
if r.error:
print(f"{proxy_url:<35} {'ERR':>6} {r.error}")
else:
received_mb = round(r.bytes_received / (1024 * 1024), 2)
print(
f"{proxy_url:<35} {r.status_code:>6} "
f"{received_mb:>11} {r.throughput_mbps:>10} {r.delta_pct:>8}"
)

The delta_pct field is your billing accuracy signal. A value of 0.0 means you received exactly the payload you requested. A negative value (say, -2.1) means 2.1% less data arrived than expected, which could indicate proxy-side content stripping or compression. After running the test, compare total bytes_received across your session against what your provider's dashboard shows for the same window.
Using the NodeMaven Proxy Bandwidth Checker
For a no-code version of the same measurement, the NodeMaven Proxy Bandwidth Checker runs a payload transfer through your proxy and reports HTTP status, elapsed time, bytes received, and expected bandwidth side by side in the browser. Paste your proxy in host:port:user:password format, select payload size (up to 500 MB), and run. No SDK, no extension, no setup.
The tool works with any HTTP or SOCKS5 proxy — not just NodeMaven proxies — which makes it useful as a neutral verification step in any proxy workflow. The side-by-side display of bytes received vs expected bandwidth is specifically designed to surface the billing accuracy question: if your provider's dashboard shows more consumption than the checker measured on the same payload, the delta is overhead or rounding you're being charged for.
Practical uses:
Baseline a new provider before committing to a larger plan
Verify billing accuracy after noticing dashboard consumption higher than expected
Compare throughput across proxy types (residential vs mobile vs ISP) on your specific target
Pre-flight check before a bandwidth-intensive scraping run
Benchmark Reference: What to Expect by Proxy Type
The numbers below represent typical performance in 2026 on a clean payload endpoint. Real-world throughput on actual scraping targets will be lower due to target-side latency, JavaScript rendering overhead, and retry traffic. For residential proxy performance specifically, results depend heavily on IP quality — residential proxies with pre-filtered IPs consistently sit at the higher end of the throughput range compared to unfiltered pools.

For operations where throughput consistency matters more than pool size — long-running sessions, account management, tools that flag IP changes — ISP proxies typically deliver the most stable bandwidth numbers of any proxy type, as the table above reflects.
Provider Comparison: Bandwidth Billing Behavior
Not all providers are transparent about what counts toward metered bandwidth. Based on publicly documented billing policies and community testing in 2026:

The practical difference between payload-only billing and full request/response billing with per-KB rounding is roughly 8–15% on typical scraping workloads with small-to-medium response sizes. On large payload transfers (images, files, bulk data), the difference narrows. On high-frequency small-request patterns (API calls, status checks), the difference widens.
Interpreting Your Results
After running a benchmark session, you'll have three numbers: measured bytes received, expected payload bytes, and dashboard-reported consumption.
Measured ≈ expected, dashboard ≈ expected: Clean billing. What you pulled is what you were charged for.
Measured ≈ expected, dashboard significantly higher: Overhead billing. The proxy is charging for protocol and handshake bytes beyond the payload. Calculate the ratio across multiple tests to determine the effective markup.
Measured < expected: The proxy is modifying content — truncating responses, stripping content, or applying compression that reduces payload size. This is unusual on quality proxy infrastructure and worth raising with support.
Measured < expected on failed requests, dashboard shows consumption: The provider is billing for failed transfers. Run a test where you intentionally hit a timeout or connection reset and check whether the dashboard records bandwidth for the failed attempt.
Building Bandwidth Testing Into Your Workflow
For operations running daily, a lightweight pre-flight bandwidth check adds minimal overhead and catches degradation before it affects a production run:
def proxy_bandwidth_preflight(
proxy_url: str,
min_throughput_mbps: float = 2.0,
payload_mb: int = 10
) -> bool:
"""Returns True if proxy meets minimum throughput threshold."""
result = measure_proxy_bandwidth(proxy_url, payload_mb=payload_mb)
if result.error:
return False
return result.throughput_mbps >= min_throughput_mbps and result.status_code == 200

Example: filter a proxy list to only passing IPs before a scraping run

proxy_list = ["http://user:pass@host1:port", "http://user:pass@host2:port"]
healthy_proxies = [p for p in proxy_list if proxy_bandwidth_preflight(p)]
print(f"{len(healthy_proxies)}/{len(proxy_list)} proxies passed pre-flight check")

Set the min_throughput_mbps threshold based on your workflow's requirements — scraping static pages needs less throughput than rendering JavaScript-heavy sites. Run the check from the same server your scraping jobs run from, since network path to the proxy affects results as much as the proxy itself.
Bandwidth testing is one of the few proxy workflow steps that pays for itself immediately: a 30-second pre-flight check that catches a degraded proxy pool before a 6-hour scraping run is worth far more than the bandwidth it consumes.

DNS Leak Test: What It Is, Why It Happens, and How to Fix It in 2026

Mathew — Tue, 21 Jul 2026 03:02:34 +0000

You've configured a proxy or VPN, your HTTP traffic routes through the right exit IP, and from the outside everything looks clean. But your DNS queries — the requests your device makes every time it resolves a domain name — might be going somewhere else entirely. That's a DNS leak, and it's one of the most common privacy and operational failures in proxy-based workflows.
This guide covers what DNS leaks are, the root causes, how to test for them, what the results mean, and how to fix them across different environments. There's a checklist at the end you can use as a pre-flight step before any proxy session.
What DNS Actually Does and Why It Leaks
DNS (Domain Name System) is the layer that translates human-readable domain names into IP addresses. When you navigate to any site, your device first asks a DNS resolver: "What's the IP address for this domain?" The resolver returns the answer, your browser connects to that IP, and the page loads.
By default, your device uses the DNS resolver assigned by your ISP or your router's DHCP configuration. That resolver is almost certainly operated by your ISP — which means your ISP gets a log of every domain your device queries, regardless of what proxy or VPN you're using for the actual traffic.
A proxy routes your HTTP/HTTPS requests through a different IP. It does not automatically reroute your DNS queries. Unless the proxy explicitly handles DNS resolution (which requires remote DNS mode — more on this below), your device continues sending DNS queries to your ISP's resolver using your real network connection, bypassing the proxy entirely.
This is a DNS leak: your traffic exits through a proxy IP in another country, but your DNS queries are still being served by your home ISP's resolver. Any site or platform that monitors both signals — which sophisticated detection systems routinely do — sees an obvious inconsistency.
Why DNS Leaks Are a Bigger Problem Than Most People Realize
For general privacy, a DNS leak means your browsing habits are visible to your ISP despite using a VPN or proxy. For operational workflows, the consequences are more specific.
Anti-fraud and anti-bot systems compare your HTTP exit IP against your DNS resolver's ASN (Autonomous System Number) and geographic location. A profile connecting from a German residential IP but resolving DNS through Comcast's US resolver creates a clear inconsistency. That mismatch elevates the risk score even if every other signal looks legitimate.
For multi-account workflows, a DNS leak can create a cross-account linkage. If multiple accounts share the same DNS resolver (your home ISP) despite having different proxy IPs, the resolver identity becomes a correlation point.
There's also the geo-accuracy problem. Platforms that serve geo-localized content — pricing, search results, ads — sometimes use DNS resolver location as an additional geo signal. If your proxy says Germany but your DNS says Virginia, the content served may not accurately represent what a real local user sees.
Common Causes of DNS Leaks
HTTP proxies with local DNS resolution. HTTP and HTTPS proxies route web traffic but do not handle DNS by default. The browser resolves domain names locally before connecting to the proxy, meaning DNS queries go to your system's configured resolver rather than through the proxy tunnel.
SOCKS5 proxies without remote DNS. SOCKS5 supports two modes: local DNS resolution (the client resolves the domain before connecting) and remote DNS resolution (the proxy server resolves the domain). Most configurations default to local DNS. You need to explicitly enable remote DNS — in curl this means using socks5h:// instead of socks5://, and in browsers using the appropriate setting.
VPN split tunneling. Many VPN configurations route only specific traffic through the tunnel. If DNS queries are excluded from split tunneling, they travel outside the VPN on the regular connection.
OS-level DNS override. Windows, macOS, and Linux all have system-level DNS settings that can override application-level proxy configurations. Some ISPs and corporate networks also use transparent DNS proxies that intercept DNS queries regardless of what resolver you've configured.
Browser-level DNS caching. Chrome maintains its own internal DNS cache separate from the OS cache. Stale entries in Chrome's cache can cause queries to bypass your current proxy configuration entirely. The same applies to Firefox's internal DNS cache. Note that this is distinct from a full DNS resolution failure — if you're seeing a "DNS server not responding" error rather than a leak, that's a different problem covered in the NodeMaven DNS server not responding guide.
IPv6 DNS leaks. If your system has an IPv6 address and your proxy only tunnels IPv4, IPv6 DNS queries will bypass the proxy and go to your ISP's IPv6 resolver. This is particularly common in environments where IPv6 is enabled by default but the proxy doesn't support it.
How to Test for a DNS Leak
Manual browser test
The fastest method is running a DNS leak test in the browser you want to verify. The NodeMaven DNS leak test tool sends test queries from your browser and reports which DNS resolvers responded — their IP addresses, ISPs, and geographic locations. If the resolvers shown belong to your home ISP rather than your proxy provider or a neutral resolver like Cloudflare or Google, you have a leak.
Run this test with your proxy active. The result should show resolvers that match your proxy's geographic location, not your physical location or home ISP.
For deeper verification, BrowserLeaks' DNS test resolves 50 randomly generated domains (25 IPv4-only, 25 IPv6-only) to maximize the chance of catching intermittent leaks. It's the most thorough browser-based DNS test available and worth running when you're auditing a new proxy setup for the first time.
Command-line verification
For a quick check outside the browser, you can verify which DNS resolver your system is actually using with standard command-line tools:

Check which DNS server resolves a query

Linux / macOS

dig +short TXT whoami.ds.akahelp.net
nslookup example.com

Windows

nslookup example.com

More detailed: show the resolver being used

dig example.com +short

Compare the server line in the output with your expected proxy resolver

For SOCKS5 proxies, you can test whether DNS is resolving remotely or locally using curl:

socks5:// = local DNS resolution (potential leak)

curl --proxy socks5://user:pass@host:port https://ipinfo.io/json

socks5h:// = remote DNS resolution through proxy (no leak)

curl --proxy socks5h://user:pass@host:port https://ipinfo.io/json

The difference in output between the two commands tells you whether your DNS queries are actually going through the proxy. If both return the same resolver information, remote DNS is working. If socks5:// shows your real ISP's resolver and socks5h:// shows a different one, you've confirmed the leak vector.
Python: automated DNS leak check
For integrating DNS leak detection into a proxy workflow:
import requests
import socket

def check_dns_leak(proxy_url: str) -> dict:
"""
Check which DNS resolver handles queries when using a proxy.
Uses DNS leak test APIs that return resolver info.
"""
proxies = {"http": proxy_url, "https": proxy_url}

# Query a DNS leak test API that returns resolver information
try:
    # This endpoint returns the DNS resolver IP that resolved the request
    response = requests.get(
        "https://bash.ws/dnsleak/test/random_id_here?json",
        proxies=proxies,
        timeout=15
    )
    resolvers = response.json()

    # Get the HTTP exit IP for comparison
    ip_response = requests.get(
        "https://httpbin.org/ip",
        proxies=proxies,
        timeout=10
    )
    exit_ip = ip_response.json().get("origin", "unknown")

    return {
        "http_exit_ip": exit_ip,
        "dns_resolvers": resolvers,
        "leak_detected": any(
            r.get("ip") != exit_ip for r in resolvers
        ) if resolvers else None
    }
except Exception as e:
    return {"error": str(e)}

result = check_dns_leak("http://user:pass@host:port")
print(result)

A clean result shows DNS resolvers whose IP addresses are consistent with your proxy's exit IP location. If the resolver ASN or country differs from your proxy's exit IP, you have a leak.
What the Results Mean
When you run a DNS leak test, you'll see one or more resolver entries. Here's how to interpret them:
No leak detected. The resolvers shown belong to your proxy provider's infrastructure, your VPN provider, or a neutral third-party resolver (Cloudflare 1.1.1.1, Google 8.8.8.8) that doesn't identify you geographically. The ISP field in the results doesn't match your home ISP.
ISP resolver visible. Your home ISP's DNS servers are handling queries. This is a confirmed leak — your browsing activity is being logged by your ISP regardless of the proxy being active.
Geographic mismatch. The resolvers shown are in a different country than your proxy's exit IP. For example, your proxy exits in the Netherlands but your DNS resolves through a US-based resolver. Even if it's not your home ISP, the geographic inconsistency is a problem for workflows that depend on accurate geo-localization.
Multiple resolvers. Multiple resolvers in the results isn't automatically a problem, but if the list includes both expected resolvers and your home ISP, the ISP entries represent a leak that needs to be addressed.
How to Fix DNS Leaks
Fix 1: Use SOCKS5 with remote DNS
The cleanest fix for proxy-based workflows is switching from local DNS resolution to remote DNS. If you're using curl or a library, change socks5:// to socks5h://. In Python's requests library:
import requests

proxies = {
"http": "socks5h://user:pass@host:port", # h = remote DNS
"https": "socks5h://user:pass@host:port"
}

response = requests.get("https://example.com", proxies=proxies)

In Firefox: go to Settings → Network Settings → Manual proxy configuration → check "Proxy DNS when using SOCKS v5". This single checkbox routes all DNS queries through the SOCKS5 proxy rather than your system resolver.
Fix 2: Configure DNS over HTTPS (DoH) in the browser
Chrome and Firefox both support DNS over HTTPS, which bypasses the system resolver and sends encrypted DNS queries to a provider of your choice. This prevents ISP interception and resolver logging.
In Chrome: Settings → Privacy and security → Security → Use secure DNS → select a provider (Cloudflare, Google, or custom). This overrides the system DNS for Chrome's web traffic.
In Firefox: Settings → General → Network Settings → Enable DNS over HTTPS → select provider. Firefox has used Cloudflare's DoH by default on US connections for several years; verify it's enabled if you're running Firefox-based automation.
Fix 3: System-level DNS configuration
For a system-wide fix that covers all applications, configure your OS to use a reliable third-party resolver:

Linux: edit /etc/resolv.conf

Add or replace nameserver lines:

nameserver 1.1.1.1 # Cloudflare
nameserver 1.0.0.1 # Cloudflare secondary

nameserver 8.8.8.8 # Google alternative

macOS: System Settings → Network → your connection → DNS → add servers

Windows: Control Panel → Network → adapter → Properties → IPv4 → DNS server

Flush DNS cache after changing:

Windows

ipconfig /flushdns

macOS

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd)

sudo systemd-resolve --flush-caches

Fix 4: Disable IPv6 if not using it through the proxy
If your proxy doesn't support IPv6, IPv6 DNS queries will bypass it:

Linux: disable IPv6 temporarily

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1

Make permanent: add to /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

On Windows, disable IPv6 per network adapter in the adapter properties, or use netsh interface ipv6 set global disabled.
Fix 5: Flush Chrome's internal DNS cache
Chrome's internal DNS cache is separate from the OS cache and persists independently. Clear it before testing a new proxy configuration:
Navigate to chrome://net-internals/#dns and click "Clear host cache". Also check chrome://net-internals/#sockets and click "Flush socket pools" to close any existing connections that might be holding stale DNS entries.
Proxy Type and DNS Leak Risk
Different proxy types have different default behaviors around DNS:

For scraping or account management workflows, SOCKS5 with remote DNS is the recommended configuration — it routes both traffic and DNS queries through the proxy's network, which means the DNS resolver ASN matches the proxy exit IP and the identity is coherent across both layers.
DNS Leak Pre-flight Checklist
Run through this before any proxy session where DNS consistency matters:
[ ] Proxy is active and HTTP exit IP shows the expected location
[ ] Run the NodeMaven DNS leak test tool — no ISP resolvers visible
[ ] Resolvers shown are geographically consistent with proxy exit IP
[ ] If using SOCKS5, confirm remote DNS mode (socks5h:// or browser "proxy DNS" setting enabled)
[ ] IPv6 disabled or routed through proxy if IPv6 support is available
[ ] Chrome internal DNS cache cleared if recently changed proxy configuration
[ ] Cross-check with WebRTC leak test — NodeMaven WebRTC leak test confirms no IP exposure through browser peer connections
[ ] Re-run after any browser update, system update, or proxy provider change
DNS leaks and WebRTC leaks are the two most common vectors that break proxy isolation in browser-based workflows. Fixing DNS takes one configuration change in most environments. The test takes under 30 seconds. Running both checks as a standard pre-flight step costs almost nothing and closes the most frequently overlooked gaps in proxy setups.

What is a WebRTC Leak? How to Test and Fix It in 2026 — Developer Guide

Mathew — Tue, 21 Jul 2026 02:55:02 +0000

If you've set up a proxy, configured a VPN, or built a browser automation workflow, you've probably assumed that the IP your browser reports to external sites is the one you chose. WebRTC leaks are the reason that assumption is often wrong — and they're responsible for a surprising number of account flags, fingerprint inconsistencies, and privacy failures that developers trace back to the wrong place.
This guide covers exactly what WebRTC leaks are, why they happen at the protocol level, how to detect them manually and programmatically, and how to fix them in Chrome, Firefox, and Node.js-based automation environments.
What WebRTC Actually Does
WebRTC (Web Real-Time Communication) is a browser API built for peer-to-peer communication — video calls, voice chat, file transfer — without needing a plugin or server relay. To establish a direct connection between two devices, WebRTC needs to know both devices' actual IP addresses. It collects these through a process called ICE (Interactive Connectivity Establishment), which queries STUN servers to discover public IPs and gathers local network interface addresses simultaneously.
The result is a list of ICE candidates: a set of IP addresses and ports the browser is willing to use for a peer connection. This list typically includes your local LAN IP (192.168.x.x or 10.x.x.x), your public ISP-assigned IP, and any IPv6 addresses associated with your network interfaces.
Here's the problem: this IP discovery process happens at the browser level, using the underlying network stack — not through the proxy or VPN tunnel your traffic normally routes through. A proxy changes the IP your HTTP requests appear to come from. It does not prevent the browser from querying STUN servers directly via UDP and reporting back whatever IPs it finds on your actual network interfaces.
That mismatch is a WebRTC leak. Your HTTP traffic shows a proxy IP in Germany. Your WebRTC candidates show your real residential IP in the United States. Any site running standard fingerprinting JavaScript can see both.
Why This Matters for Proxy and Automation Workflows
For general browsing with a VPN, a WebRTC leak is a privacy concern. For anyone doing multi-account management, scraping, or ad verification with proxies, it's a workflow-breaking problem.
Modern anti-bot systems don't just check your HTTP connection IP. They compare it against WebRTC candidates, DNS resolver behavior, browser fingerprint signals, and geolocation data simultaneously. A profile where the HTTP IP says one country and WebRTC candidates say another country has an obvious inconsistency that elevates the risk score immediately — often enough to trigger a checkpoint or block without any other suspicious behavior.
For anti-detect browser users, this is particularly important because most profiles are built around maintaining a coherent identity across all signals. A WebRTC leak punches a hole in that identity at the network layer.
What Types of Leaks Exist
There are four distinct WebRTC leak types worth understanding:
Public IP leak — WebRTC exposes your real ISP-assigned public IP through ICE candidates, even while HTTP traffic routes through a proxy. This is the most damaging leak type because the exposed IP is directly tied to your real identity.
Local IP leak — WebRTC exposes a LAN address (192.168.x.x, 10.x.x.x, 172.16.x.x). Less critical for privacy than a public IP leak, but still contributes to fingerprint uniqueness — the same LAN IP appearing across profiles creates a cross-profile linkage.
IPv6 leak — IPv6 addresses are typically public and globally unique, unlike IPv4 LAN addresses. If your machine has an IPv6 address and WebRTC includes it in ICE candidates while your proxy only tunnels IPv4, the IPv6 address directly identifies your device. This is one of the most overlooked leak vectors in 2026.
mDNS obfuscation disabled — Chromium-based browsers replaced local IP exposure with mDNS hostnames (a random UUID like a3f2c1d0.local) in recent versions to mitigate LAN IP leaks. If mDNS obfuscation is disabled in your browser profile, raw LAN IPs are exposed instead.
How to Test for a WebRTC Leak
Manual browser test
The simplest test is loading a WebRTC leak checker in the browser you want to verify. The NodeMaven WebRTC leak test runs automatically on page load, collects ICE candidates from your browser, and compares them against your HTTP connection IP in a side-by-side display. If WebRTC candidates show any IP other than your proxy IP — especially a public IP from your real ISP — you have a leak.
The test also displays SDP output, which is useful for debugging automation environments where you need to see exactly what candidates the browser is generating.
Run this test every time you:
Configure a new proxy or change proxy providers
Update your browser or anti-detect browser profile
Add or change browser extensions related to privacy or networking
Set up a new automation environment
Manual JavaScript test
To understand what browsers expose at the API level — and to build your own detection logic into a workflow — you can run the ICE candidate collection process directly:
async function detectWebRTCLeak() {
const candidates = [];

const pc = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{ urls: 'stun:stun1.l.google.com:19302' }
]
});

// Create a data channel to trigger ICE gathering
pc.createDataChannel('');

pc.onicecandidate = (event) => {
if (!event.candidate) return;

const candidate = event.candidate.candidate;
// Extract IP addresses from SDP candidate strings
const ipRegex = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/;
const match = candidate.match(ipRegex);

if (match) {
  candidates.push({
    ip: match[1],
    type: candidate.includes('typ host') ? 'host' : 
          candidate.includes('typ srflx') ? 'srflx' : 'other',
    raw: candidate
  });
}

};

await pc.createOffer().then(offer => pc.setLocalDescription(offer));

// Wait for ICE gathering to complete
await new Promise(resolve => {
pc.onicegatheringstatechange = () => {
if (pc.iceGatheringState === 'complete') resolve();
};
setTimeout(resolve, 3000); // Fallback timeout
});

pc.close();
return candidates;
}

detectWebRTCLeak().then(candidates => {
console.log('WebRTC ICE candidates found:');
candidates.forEach(c => console.log(${c.type}: ${c.ip}));
});

The srflx (server-reflexive) candidates are the most important to examine — these are your public IPs as seen by the STUN server. If any srflx candidate shows an IP that doesn't match your proxy's exit IP, you have a public IP leak.
How to Fix WebRTC Leaks
Chrome and Chromium-based browsers
Chrome doesn't have a built-in toggle to disable WebRTC. The recommended approach is the WebRTC Network Limiter extension (official Google extension). In the extension settings, set the policy to "Use my default public interface only". This restricts WebRTC to using the same IP as your HTTP traffic rather than discovering all available interfaces.
For stricter control, the "Disable non-proxied UDP" option prevents WebRTC from making any UDP connections that don't go through the configured proxy. This eliminates leaks entirely but also breaks in-browser WebRTC applications like Google Meet.
For Chromium-based browsers in an automation context, the launch flag approach is cleaner:
chromium --force-webrtc-ip-handling-policy=disable_non_proxied_udp \
--proxy-server=http://user:pass@host:port

The disable_non_proxied_udp policy is the most reliable option for scraping and automation environments where you don't need WebRTC functionality.
Firefox
Firefox is the easier browser to configure for WebRTC leak prevention. Open about:config, search for media.peerconnection.enabled, and set it to false. This disables WebRTC peer connections entirely — no ICE candidates are generated, no IPs are exposed.
If you need WebRTC to remain functional but want to restrict which IPs it exposes, set media.peerconnection.ice.default_address_only to true. This limits ICE candidates to the default network interface rather than enumerating all available interfaces.
// Firefox about:config settings for WebRTC leak prevention:
// media.peerconnection.enabled = false // Disable WebRTC entirely
// media.peerconnection.ice.default_address_only = true // Restrict to default interface
// media.peerconnection.ice.no_host = true // Block local IP candidates

For proxy users who want to keep WebRTC active while preventing leaks, media.peerconnection.ice.default_address_only = true combined with a SOCKS5 proxy configured at the browser level (not system level) is the most reliable configuration.
Puppeteer and Playwright
In Node.js automation with Puppeteer, set the WebRTC policy at browser launch:
const puppeteer = require('puppeteer');

const browser = await puppeteer.launch({
args: [
'--force-webrtc-ip-handling-policy=disable_non_proxied_udp',
'--proxy-server=http://user:pass@host:port',
'--disable-features=WebRtcHideLocalIpsWithMdns' // Only if you want raw IPs (testing)
]
});

const page = await browser.newPage();

// Verify no WebRTC leak programmatically
const candidates = await page.evaluate(async () => {
const found = [];
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.createDataChannel('');
await pc.createOffer().then(o => pc.setLocalDescription(o));
await new Promise(r => setTimeout(r, 2000));
pc.onicecandidate = e => { if (e.candidate) found.push(e.candidate.candidate); };
pc.close();
return found;
});

console.log('ICE candidates from automated browser:', candidates);
// Should be empty or show only proxy IP if configured correctly

For Playwright, the equivalent configuration:
const { chromium } = require('playwright');

const browser = await chromium.launch({
args: [
'--force-webrtc-ip-handling-policy=disable_non_proxied_udp'
],
proxy: {
server: 'http://host:port',
username: 'user',
password: 'pass'
}
});

Anti-detect browsers
Anti-detect browsers handle WebRTC at the profile level. In AdsPower and Dolphin Anty, the WebRTC setting in each browser profile controls whether the profile exposes the proxy IP, a spoofed IP, or disables WebRTC entirely. The correct setting for most proxy workflows is to configure WebRTC to return the proxy IP rather than disabling it — a profile with WebRTC completely absent is itself a fingerprint signal, since almost no real browsers have it disabled.
The profile-level WebRTC setting needs to be verified after each proxy change. If you reassign a profile to a different proxy IP but the WebRTC setting still references the old IP, the inconsistency is detectable.
The Proxy and WebRTC Relationship
One important clarification: WebRTC leaks are a browser configuration problem, not a proxy quality problem. A high-quality residential proxy routes your HTTP traffic through a clean IP. It cannot, on its own, prevent the browser from generating ICE candidates using your real network interfaces via UDP.
That said, the quality of the proxy still matters for the overall setup. A clean proxy IP that matches the geographic location and ISP profile you're projecting creates a coherent identity. If your browser is correctly configured to route WebRTC through the proxy (or to disable non-proxied UDP), the ICE candidates will reflect the proxy IP, and the HTTP connection and WebRTC layer will be consistent. For workflows where IP reputation is critical — multi-account management, ad verification, scraping — residential proxies with pre-filtered IPs give you a stable foundation that WebRTC configuration alone can't provide.
For residential proxy workflows specifically, cross-linking the NodeMaven DNS leak test into your pre-flight checklist alongside the WebRTC test is worth doing — DNS leaks are a separate vector that can expose your real resolver even when WebRTC is properly handled.
Verification Checklist Before Any Proxy Workflow
Before running any account management, scraping, or automation session, run through this verification sequence:
Activate your proxy and confirm the HTTP exit IP matches your expected location
Run the WebRTC leak test — verify no ICE candidates show your real public IP
Check for IPv6 leaks specifically — IPv6 is the most commonly overlooked vector
Run a DNS leak test — verify your DNS resolver matches your proxy's location
If using an anti-detect browser, confirm the WebRTC setting in the active profile reflects the current proxy IP
Re-run verification after any browser update, extension change, or proxy rotation
The most common mistake is running verification once during initial setup and never again. Browser updates silently change WebRTC behavior. Extensions conflict after updates. A clean setup from three months ago may have a leak today.
Quick Reference: WebRTC Settings by Environment

WebRTC leaks are one of the most reliable ways a browser-based workflow gets fingerprinted, and they're entirely fixable with the right configuration. The test takes under 30 seconds. The fix is a single browser setting or launch flag. Running both as a standard pre-flight check costs almost nothing and eliminates an entire class of detection failure.

How to Set Up a Proxy on Android: Complete Guide for 2026

Mathew — Thu, 18 Jun 2026 08:06:33 +0000

Setting up a proxy on Android sounds like it should be a five-minute job, and for simple cases it is. But if you've ever tried to get a residential or mobile proxy working correctly on an Android device — especially one that needs authentication — you've probably hit at least one wall. The native Wi-Fi proxy settings don't support username/password authentication in the standard UI. Certain apps ignore system proxy settings entirely and need separate configuration. And some use cases, like running multiple proxied sessions simultaneously, need a different approach altogether.
This guide covers all of it: the built-in Wi-Fi method, HTTP vs SOCKS5 setup, authentication handling, per-app proxy configuration, and how to verify the connection is actually working. Whether you're setting up one proxy for personal use or configuring an Android device for a larger automation workflow, you'll have everything you need here.
What Android's Proxy Settings Actually Do
Before getting into the steps, it's worth understanding what Android's built-in proxy configuration actually covers — because the limitation matters.
When you configure a proxy through Android's Wi-Fi settings, you're setting a system-level HTTP proxy. This tells apps that use the standard Android HTTP networking stack to route their traffic through that proxy. Most browsers (Chrome, Firefox), and many apps, will respect this setting. But it has two significant limitations.
First, Android's native Wi-Fi proxy UI doesn't have fields for username and password authentication. If your proxy requires credentials — which every quality residential or mobile proxy does — the system will pass the connection attempt without credentials, get a 407 authentication error, and fail silently. You'll appear to be connected but your traffic won't be proxied.
Second, apps that use their own networking libraries (many social media apps, games, and tools) may bypass the system proxy entirely. For those, you'll need either a per-app proxy configuration or a VPN-based proxy client.
With that context in place, here's how each method works in practice.
Method 1: Built-in Wi-Fi Proxy Settings (HTTP)
This is the right starting point for HTTP proxies that either don't require authentication, or where you're going to handle authentication separately through a proxy app.
Open Settings on your Android device and navigate to Connections (on Samsung) or Network & Internet (on stock Android), then tap Wi-Fi. Long-press or tap the gear icon next to your connected network to open its settings. Depending on your Android version, look for Manage network settings or Advanced, then find the Proxy section.
Change the Proxy setting from None to Manual. You'll see two fields: Proxy hostname and Proxy port.
For a NodeMaven residential proxy, the hostname is gate.nodemaven.com and the port is in the range 8080–9080 (for HTTP) or 32000–33000 (for HTTP on a different port range). Use port 8080 as a default. Enter the hostname and port, then save.
At this point, the proxy is configured at the network level but not authenticated. Traffic will route to the proxy server, which will return a 407 authentication required response for most requests. For proxies requiring credentials, proceed to one of the app-based methods below.
When this method works without additional setup: If your proxy provider supports IP whitelisting — where the proxy authenticates based on your device's originating IP rather than username/password — the Wi-Fi method alone is sufficient. You whitelist your device's real IP in the provider's dashboard, and traffic is authenticated automatically without credentials in the request.
Method 2: Built-in Wi-Fi Settings (SOCKS5)
Android's native Wi-Fi proxy settings support SOCKS5 as well, though the field labeling in the UI doesn't always make this obvious.
Follow the same path: Settings → Wi-Fi → your network → Advanced → Proxy → Manual. In the Proxy hostname field, enter the SOCKS5 gateway address. For NodeMaven, this is gate.nodemaven.com. For the port, use 1080 (the standard SOCKS5 port) or the range 1080–2080.
The catch is the same: Android's native settings have no authentication fields. If your SOCKS5 proxy requires username and password — and all credential-based proxies do — you'll need to use an app that supports SOCKS5 with authentication. Shadowrocket (available for Android as well as iOS) is commonly used for this. Configure the SOCKS5 proxy details inside Shadowrocket, enable it, and your device will route traffic through the authenticated SOCKS5 connection regardless of the system proxy settings.
Method 3: Browser-Level Proxy Configuration
For proxying traffic through a specific browser only, you can configure the proxy inside the browser rather than at the system level. This approach is more contained — it only affects that browser's traffic — and typically handles authentication natively.
Firefox for Android supports proxy configuration directly in its settings. Open Firefox, tap the three-dot menu, go to Settings → General → Network settings, and select Manual proxy configuration. Enter your HTTP or SOCKS5 proxy details, including the hostname, port, and authentication credentials. Firefox will prompt you for the username and password the first time it makes a request through the proxy.
Chrome for Android doesn't have its own proxy settings and relies on the system-level configuration. For Chrome with an authenticated proxy, use a proxy extension approach on desktop, or on Android route through a proxy client app.
For multi-account workflows where you need different proxy configurations per browser profile, the browser-level method doesn't scale well — you'd need separate browsers for each proxy. Anti-detect browser apps that support Android, or a proxy manager app with per-app routing, are better solutions for that use case.
Method 4: Proxy Manager Apps (Per-App Routing and Authentication)
For the most flexible setup — handling authentication, routing specific apps through different proxies, or running multiple proxied sessions — a dedicated proxy manager app is the right tool.
Shadowrocket is the most widely used option and supports HTTP, HTTPS, SOCKS5, and several other protocols, all with authentication. You add a proxy server configuration with hostname, port, username, and password. Once enabled, it creates a local VPN interface that intercepts your device's traffic and routes it through the configured proxy. You can set it to proxy all traffic or configure rules to proxy only specific apps.
Proxyman and NetGuard are alternatives worth knowing, though their feature sets differ. Proxyman is more debug-focused (useful for development workflows), while NetGuard focuses on per-app traffic control.
Setup in Shadowrocket for a NodeMaven proxy looks like this:
Open Shadowrocket and tap the + button to add a new server. Select the proxy type (HTTP for HTTP/HTTPS proxies, SOCKS5 for SOCKS5). Enter the server details:
Host: gate.nodemaven.com
Port: 8080 (HTTP) or 1080 (SOCKS5)
Username: your NodeMaven proxy username (includes targeting parameters)
Password: your NodeMaven proxy password
The NodeMaven username format encodes your configuration options directly in the credential string. A username targeting the US with a sticky session and quality filter enabled looks like: PROXYUSER-country-us-sid-yoursessionid-filter-medium. You generate this string in the NodeMaven dashboard when setting up your proxy endpoint — the dashboard builds the username based on the location, session type, and filter settings you select.
Once the server is saved in Shadowrocket, toggle it on. The app creates a VPN connection on your device (you'll see the VPN key icon in the status bar), and all device traffic routes through the proxy with full authentication.
Verifying the Proxy Is Working
Never assume the proxy is active just because the settings are saved. Always verify.
The simplest check is opening a browser and visiting an IP-checking site like ipinfo.io or whatismyipaddress.com. The IP shown should match your proxy's location, not your real IP or ISP. If it still shows your real IP, the proxy isn't routing your traffic.
For SOCKS5 specifically, also check for WebRTC leaks using browserleaks.com/webrtc. SOCKS5 routes TCP traffic but can leave WebRTC connections going directly. If the WebRTC check shows your real IP, configure your browser to disable WebRTC (Firefox: media.peerconnection.enabled = false in about:config) or use a browser that doesn't expose it.
If you're testing a NodeMaven proxy, the dashboard shows your connection status and the IPs being used in real time, which is a faster way to confirm the setup than external IP checkers.
Credential Format: What Goes in the Username Field
This is the part that trips people up most often with residential proxies on Android, because the username isn't just a simple account identifier — it's a configuration string.
For NodeMaven Android proxy setup, the username follows a structured format that controls location targeting, session behavior, and IP quality filtering. A full username string looks like:
PROXYUSER-country-us-city-newyork-sid-abc123xyz-filter-medium

Where each segment does the following: country-us targets US IPs, city-newyork narrows to New York specifically, sid-abc123xyz is your session ID (keeps the same IP for the duration of the session — omit this for rotating behavior), and filter-medium applies the IP quality filter at medium threshold.
You don't need to construct this manually. The NodeMaven dashboard has a proxy configuration widget where you select your target country, city, session type, and filter level, and it generates the complete username string. Copy that string into the username field of your proxy app or browser config.
The password is a fixed credential from your account — it doesn't change with targeting parameters.
Proxy Per App vs System-Wide: Which to Use
For most single-proxy use cases, a system-wide proxy configured through Shadowrocket is simplest. All apps route through the same proxy, and you configure it once.
For multi-proxy setups — where different apps need different IPs or countries — Shadowrocket's rule-based routing lets you specify which apps use which proxy profile. You can set Instagram to use a US residential proxy while another app uses a UK residential proxy, all from the same device.
For development or testing workflows where you want to inspect the proxied traffic, Proxyman is better suited — it can decrypt HTTPS traffic for debugging purposes, which Shadowrocket doesn't do.
Common Issues and Fixes
Proxy connects but traffic still shows real IP: The proxy is configured but authentication is failing. Double-check the username format — especially if you're using a residential proxy with targeting parameters in the credential string. A single typo in the username (like a missing hyphen in the session ID parameter) will cause authentication to fail silently on some apps.
Some apps bypass the proxy: Apps with their own certificate pinning or networking stack will ignore system-level and Shadowrocket proxies. There's limited recourse here without rooting the device. For rooted devices, transparent proxy setups using iptables rules can intercept all traffic regardless of the app.
Proxy works in browser but not in a specific app: The app may be using its own networking library rather than the system stack. Configure the proxy inside the app directly if it supports it, or use the VPN-based approach (Shadowrocket) which intercepts at the network interface level rather than the application level.
Session drops after a few minutes: Your sticky session ID may have expired, or the proxy IP was rotated by the provider. Check your session duration settings in the dashboard — for long-running sessions on Android, set the session type to "keep IP as long as possible," which holds the same IP for up to 24 hours.
Protocol Choice: HTTP vs SOCKS5 on Android
For standard browsing and most app traffic, HTTP proxies work fine on Android. They handle HTTP and HTTPS connections and are compatible with the broadest range of apps and configuration methods.
SOCKS5 is the better choice for use cases involving non-HTTP traffic (anything using UDP, custom TCP connections, or protocols beyond standard web requests), or when you want to avoid the proxy inspecting or modifying packet headers. SOCKS5 proxies simply forward packets without touching their contents, which can reduce latency slightly and improves compatibility with apps that do protocol-level checks.
For social media automation, scraping, or multi-accounting workflows on Android, either protocol works — the IP quality and session stability matter more than the protocol choice.

How to Check Proxy Bandwidth Speed: Tools and Benchmarks for 2026

Mathew — Thu, 18 Jun 2026 07:57:01 +0000

If you're running any proxy-dependent workflow at scale — scraping, multi-account management, automation — proxy speed and bandwidth accuracy are two of the most consequential variables in your stack. Yet most people only think about them after something breaks: a scraping job that runs 3x slower than expected, a billing discrepancy that's hard to explain, a provider whose latency spikes under load.
This guide covers the practical methods for measuring both throughput and latency from the command line and from Python, explains what the numbers actually mean, and includes a benchmark comparison across proxy types so you have a reference point before you start testing.
What You're Actually Measuring
It's worth separating two things that often get conflated:
Latency is the time from sending a request to receiving the first byte of the response. For proxy connections this includes DNS resolution (if the proxy doesn't do remote DNS), TCP handshake to the proxy, authentication, the proxy's own request to the target, and the target's response time. For scraping and automation, latency determines how many requests per minute you can push per concurrent connection.
Throughput is how many bytes actually move through the tunnel per second once the connection is established. For bandwidth-billed proxies, this is what determines your cost per operation. A provider that rounds up to the nearest MB per request, counts TLS handshake bytes as metered traffic, or charges for failed requests will show higher consumption in your dashboard than what you actually received.
Both numbers matter, but they fail in different ways. A proxy with great throughput but high latency is expensive for high-frequency request patterns. A proxy with great latency but padded bandwidth billing will quietly cost you more than expected at scale.
CLI Testing: curl and wget
The fastest way to get a proxy speed reading without writing any code is curl. It supports HTTP and SOCKS5 proxies natively and can output precise timing breakdowns.
Basic throughput test via HTTP proxy:
curl -x http://user:pass@host:port \
-o /dev/null \
-w "time_connect: %{time_connect}s\ntime_starttransfer: %{time_starttransfer}s\ntime_total: %{time_total}s\nspeed_download: %{speed_download} B/s\nsize_download: %{size_download} B\n" \
https://httpbin.org/bytes/10485760

The -w format string extracts the timing breakdown you actually need:
time_connect — time to establish the TCP connection to the proxy
time_starttransfer — time to first byte (TTFB), includes proxy overhead
time_total — total transfer time
speed_download — average throughput in bytes/second
size_download — bytes actually received (compare to expected payload size)
For SOCKS5 proxies:
curl -x socks5h://user:pass@host:port \
-o /dev/null \
-w "time_total: %{time_total}s\nspeed_download: %{speed_download} B/s\n" \
https://httpbin.org/bytes/10485760

The socks5h scheme tells curl to do DNS resolution through the proxy rather than locally — important for accurate latency measurement and for preventing DNS leaks.
Batch testing a proxy list with a shell loop:

!/bin/bash

PROXIES=(
"http://user:pass@host1:port"
"http://user:pass@host2:port"
"http://user:pass@host3:port"
)

PAYLOAD_MB=10
PAYLOAD_BYTES=$((PAYLOAD_MB * 1024 * 1024))
URL="https://httpbin.org/bytes/${PAYLOAD_BYTES}"

echo "proxy,time_total_s,speed_bps,bytes_received"

for PROXY in "${PROXIES[@]}"; do
RESULT=$(curl -x "$PROXY" -o /dev/null --max-time 30 \
-w "%{time_total},%{speed_download},%{size_download}" \
-s "$URL" 2>/dev/null)
echo "$PROXY,$RESULT"
done

This produces a CSV you can pipe into any analysis tool. Add -s to suppress progress output and --max-time 30 to timeout slow proxies cleanly.
Python Testing: requests and aiohttp
For integration into existing workflows, Python gives you more control over what you measure and how you aggregate it.
Single proxy benchmark with requests:
import requests
import time

def benchmark_proxy(proxy_url: str, payload_mb: int = 10) -> dict:
payload_bytes = payload_mb * 1024 * 1024
proxies = {"http": proxy_url, "https": proxy_url}
url = f"https://httpbin.org/bytes/{payload_bytes}"

start = time.perf_counter()
try:
    resp = requests.get(url, proxies=proxies, stream=True, timeout=30)
    ttfb = time.perf_counter() - start  # time to first byte (approx)

    bytes_received = 0
    for chunk in resp.iter_content(chunk_size=65536):
        bytes_received += len(chunk)

    elapsed = time.perf_counter() - start
    throughput_mbps = (bytes_received * 8) / (elapsed * 1_000_000)

    return {
        "proxy": proxy_url,
        "status": resp.status_code,
        "ttfb_s": round(ttfb, 3),
        "elapsed_s": round(elapsed, 3),
        "bytes_received": bytes_received,
        "expected_bytes": payload_bytes,
        "throughput_mbps": round(throughput_mbps, 2),
        "billing_delta_pct": round(
            (payload_bytes - bytes_received) / payload_bytes * 100, 2
        ),
    }
except Exception as e:
    return {"proxy": proxy_url, "error": str(e)}

result = benchmark_proxy("http://user:pass@host:port", payload_mb=50)
print(result)

The billing_delta_pct field is the key metric for billing verification: if you're pulling a 50 MB payload and receiving 49.2 MB, your provider's dashboard should not show 52 MB consumed.
Concurrent benchmark across a proxy list with asyncio + aiohttp:
import asyncio
import aiohttp
import time
from typing import List

async def benchmark_single(
session: aiohttp.ClientSession,
proxy: str,
payload_bytes: int,
url: str
) -> dict:
start = time.perf_counter()
try:
async with session.get(url, proxy=proxy, timeout=aiohttp.ClientTimeout(total=30)) as resp:
ttfb = time.perf_counter() - start
data = await resp.read()
elapsed = time.perf_counter() - start

        throughput_mbps = (len(data) * 8) / (elapsed * 1_000_000)
        return {
            "proxy": proxy,
            "status": resp.status,
            "ttfb_s": round(ttfb, 3),
            "elapsed_s": round(elapsed, 3),
            "bytes_received": len(data),
            "expected_bytes": payload_bytes,
            "throughput_mbps": round(throughput_mbps, 2),
        }
except Exception as e:
    return {"proxy": proxy, "error": str(e)}

async def benchmark_batch(proxies: List[str], payload_mb: int = 10):
payload_bytes = payload_mb * 1024 * 1024
url = f"https://httpbin.org/bytes/{payload_bytes}"

async with aiohttp.ClientSession() as session:
    tasks = [
        benchmark_single(session, proxy, payload_bytes, url)
        for proxy in proxies
    ]
    results = await asyncio.gather(*tasks)

return results

proxies = [
"http://user:pass@host1:port",
"http://user:pass@host2:port",
"http://user:pass@host3:port",
]

results = asyncio.run(benchmark_batch(proxies, payload_mb=20))
for r in results:
print(r)

Running benchmarks concurrently is important for residential and mobile proxies, where individual IPs vary significantly. A single test on a single IP is not representative — you want to sample 5–10 IPs from a rotating pool and average the results.
Benchmark Reference Table
The numbers below are representative of what you should expect from different proxy types in 2026 on a mid-tier scraping target (a static file endpoint with no bot detection). Your results will vary based on your origin location, the target region, and network conditions.
Proxy Type
Avg Latency (TTFB)
Avg Throughput
Success Rate
Notes
Residential rotating
0.4–0.9s
3–8 Mbps
95–98%
Varies by IP; some slow outliers
Mobile (4G/LTE)
0.5–1.2s
4–12 Mbps
97–99%
Higher trust, slightly higher latency
ISP (static residential)
0.2–0.5s
8–25 Mbps
99%+
Fastest and most consistent
Datacenter
0.05–0.2s
50–200 Mbps
60–85%*
Fast, but high block rate on guarded targets

*Success rate for datacenter proxies depends heavily on target. On unprotected endpoints they work fine; on platforms with IP reputation checks, block rates are high.
For bandwidth-billed residential proxies, the more meaningful number is success rate combined with bytes-received accuracy. A provider whose IPs fail 10% of requests but still bill you for those attempts costs more than the per-GB rate suggests.
Integrating Speed Tests into Your Proxy Workflow
The practical use of these benchmarks isn't running them once and filing the results. It's making speed testing a routine step in your proxy workflow so you can catch degradation early.
A minimal pre-flight check before any production scraping run:
import requests
import time

def proxy_health_check(proxy_url: str, threshold_ttfb: float = 2.0) -> bool:
"""Returns True if proxy meets latency threshold."""
proxies = {"http": proxy_url, "https": proxy_url}
start = time.perf_counter()
try:
resp = requests.get(
"https://httpbin.org/status/200",
proxies=proxies,
timeout=threshold_ttfb + 1
)
ttfb = time.perf_counter() - start
return resp.status_code == 200 and ttfb <= threshold_ttfb
except Exception:
return False

For bandwidth billing verification at the end of a session, compare your bytes_received total from the script against what your provider's dashboard shows for the same session window. Any consistent gap of more than a few percent is worth raising with support.
Using the NodeMaven Proxy Bandwidth Checker
For a no-code version of the same test, the NodeMaven Proxy Bandwidth Checker runs a payload transfer of your choice (10 MB to 500 MB) through your proxy tunnel and reports HTTP status, elapsed time, bytes received, and expected bandwidth side by side. Credentials are used only for the duration of the test and never stored.
The tool works with any HTTP or SOCKS5 proxy, not just NodeMaven proxies — which makes it useful as a standalone verification step in any proxy workflow. If your provider reports 15% more bandwidth consumed than the checker measures on the same payload size, that's concrete evidence of billing inflation worth investigating.
Run it after initial setup to baseline your proxy's performance, and again any time your pipeline's success rate or throughput degrades unexpectedly. Having a reference measurement from a known-good state makes it much easier to diagnose whether a slowdown is coming from the proxy, the target, or your own infrastructure.
What Good Numbers Look Like
For scraping and automation workflows, here's a practical reference:
A residential proxy with TTFB under 1 second and throughput above 3 Mbps is healthy for most tasks. Anything consistently above 2 seconds TTFB suggests the IP is either geographically far from your target, congested, or of lower quality. Throughput below 1 Mbps on a residential proxy usually means you're hitting an IP that's throttled or being rate-limited by the target.
For mobile proxies on high-trust platforms like Instagram or TikTok, the TTFB metric matters less than the success rate. An IP that takes 1.1 seconds to respond but succeeds 99% of the time is more valuable than one that responds in 0.4 seconds but triggers a checkpoint every third request.
ISP proxies should consistently hit TTFB under 500ms. If they're performing like residential rotating proxies, something is wrong with the IP assignment or the routing.
Run these tests from the same origin server or VPS that your actual scraping jobs run from. Testing from your laptop in one country against proxies routed to another will give you numbers that don't reflect production performance.

Setting Up Unique Browser Fingerprints: Developer Deep Dive

Mathew — Wed, 17 Jun 2026 04:38:48 +0000

Every time your browser loads a page, it hands over a detailed report about itself — GPU model, installed fonts, how it renders a triangle wave through an audio processor, the exact floating-point output of a WebGL shader. None of this requires cookies. None of it requires login. The site doesn't even need to ask permission. It just reads.
This is browser fingerprinting. And if you're building multi-profile automation, running scraping pipelines, or doing any kind of work where account isolation matters, understanding how each of these signals is collected — and how to override it at the JavaScript level — is non-negotiable.
This article goes deep on four fingerprinting vectors that matter most in practice: Canvas, WebGL, AudioContext, and font enumeration. For each one, we'll cover how the collection works, what makes the output unique, and how to spoof it correctly. "Correctly" being the operative word — naive spoofing is often worse than no spoofing at all.
Why Fingerprinting Is Harder to Escape Than It Looks
A quick framing before getting into the code.
A browser fingerprint is stateless. Unlike a cookie, nothing is stored on your machine. The site runs JavaScript, reads a set of browser and hardware properties through standard Web APIs, hashes the combined output, and that hash becomes your identifier. Delete cookies, clear storage, rotate your IP — the fingerprint hash stays the same, because the underlying hardware and software stack hasn't changed.
The individual signals are largely mundane: screen resolution, timezone, language preferences, the list of fonts your OS has installed. None of these is unique on its own. The uniqueness comes from their combination. Research consistently shows that 80–90% of browser fingerprints are unique across the web, which makes fingerprinting more reliably identifying than IP-based tracking for most purposes.
For developers building automation or multi-account tooling, the practical implication is this: every browser profile running on the same machine will produce the same fingerprint unless you actively intercept and override the relevant APIs. Even across different browsers. Even across incognito windows. The fingerprint is a property of the hardware and OS, not the browser session.
The Four Core Fingerprinting Vectors

Canvas Fingerprinting Canvas fingerprinting exploits the fact that different hardware and OS configurations render the same drawing instructions slightly differently. The GPU, the graphics driver, the OS text rendering pipeline, and font hinting settings all introduce microscopic variations in pixel output. When you hash that pixel output, you get a stable per-device identifier. Here's the basic collection pattern a fingerprinting script uses: const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d');

// Draw a combination of text and shapes to maximize rendering variation
ctx.font = '14px Arial';
ctx.fillStyle = '#f60';
ctx.fillRect(125, 1, 62, 20);
ctx.fillStyle = '#069';
ctx.fillText('Browser fingerprint test 🖥️', 2, 15);
ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
ctx.fillText('Browser fingerprint test 🖥️', 4, 17);

const fingerprint = canvas.toDataURL(); // base64-encoded pixel data

The hash of that toDataURL() output is your Canvas fingerprint. Two identical-spec machines running identical OS versions will often still produce slightly different hashes due to driver-level differences.
Spoofing approach: deterministic noise injection
The naive approach — blocking toDataURL() entirely or returning a blank canvas — is immediately detectable. Any fingerprint checker will flag the absence of canvas data as suspicious, and platforms with serious anti-fraud systems will treat it as a bot signal.
The correct approach is noise injection at the prototype level. You intercept the canvas read methods and introduce a tiny, invisible perturbation to the pixel data — enough to change the hash, not enough to alter the visual rendering.
// Inject before any page scripts run (e.g., via evaluateOnNewDocument in Puppeteer)
(function() {
const PROFILE_SEED = 'your-profile-specific-seed-value';

// Simple seeded pseudo-random for deterministic noise
function seededRandom(seed) {
let s = seed.split('').reduce((a, c) => a + c.charCodeAt(0), 0);
return function() {
s = (s * 9301 + 49297) % 233280;
return s / 233280;
};
}

const rng = seededRandom(PROFILE_SEED);

const origGetImageData = CanvasRenderingContext2D.prototype.getImageData;
CanvasRenderingContext2D.prototype.getImageData = function(...args) {
const imageData = origGetImageData.apply(this, args);
for (let i = 0; i < imageData.data.length; i += 4) {
imageData.data[i] = Math.min(255, imageData.data[i] + Math.floor(rng() * 2));
}
return imageData;
};
})();

Two things are critical here. First, the noise must be deterministic per profile — seeded from a profile-specific value so the same hash is produced on every visit. If the Canvas fingerprint changes between sessions for the same profile, platforms will detect the instability. Second, the noise magnitude must be imperceptible — 1–2 pixel value units per channel is enough to change the hash without producing any visible artifact.

WebGL Fingerprinting WebGL goes deeper than Canvas because it queries the GPU directly. A fingerprinting script can pull the exact GPU vendor and renderer string, the full list of supported WebGL extensions (typically 30–50), shader precision formats, maximum texture sizes, and viewport dimensions. Each of these varies by hardware model and driver version. The most sensitive parameters are accessed through the WEBGL_debug_renderer_info extension: const canvas = document.createElement('canvas'); const gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');

// These two reveal the exact GPU model
const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');
const vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
const renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);

// Output example: "Google Inc. (NVIDIA)" / "ANGLE (NVIDIA GeForce RTX 3080...)"
console.log(vendor, renderer);

// Full extension list also forms part of the fingerprint
const extensions = gl.getSupportedExtensions();

If you're running Puppeteer or Playwright in headless mode without spoofing, the renderer will typically report something like "Google SwiftShader" — which is an immediate bot signal, since no real user's browser reports that GPU.
Spoofing approach: getParameter override
Spoofing WebGL requires overriding getParameter on both WebGLRenderingContext and WebGL2RenderingContext prototypes. The override must happen before any WebGL context is created on the page.
(function() {
// Use a fingerprint from a real device in your target demographic
const SPOOF_VENDOR = 'Google Inc. (Intel)';
const SPOOF_RENDERER = 'ANGLE (Intel, Intel(R) UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0, D3D11)';

const getParameterOrig = WebGLRenderingContext.prototype.getParameter;
WebGLRenderingContext.prototype.getParameter = function(parameter) {
// UNMASKED_VENDOR_WEBGL = 0x9245, UNMASKED_RENDERER_WEBGL = 0x9246
if (parameter === 0x9245) return SPOOF_VENDOR;
if (parameter === 0x9246) return SPOOF_RENDERER;
return getParameterOrig.call(this, parameter);
};

// Don't forget WebGL2
const getParameter2Orig = WebGL2RenderingContext.prototype.getParameter;
WebGL2RenderingContext.prototype.getParameter = function(parameter) {
if (parameter === 0x9245) return SPOOF_VENDOR;
if (parameter === 0x9246) return SPOOF_RENDERER;
return getParameter2Orig.call(this, parameter);
};
})();

One critical consistency requirement: the GPU string you spoof must be plausible relative to the rest of the profile. Claiming to be an Intel UHD 620 while your Canvas rendering output looks like NVIDIA, or claiming a Windows GPU while your User-Agent says macOS, creates exactly the kind of cross-signal inconsistency that detection systems look for. The renderer string, User-Agent, and platform all need to tell the same story.
This is also where the IP layer matters. A profile claiming to be a Windows laptop with a US timezone, an Intel GPU, and an English-US locale, running on a data-center IP in Singapore, is incoherent. The network layer has to match the fingerprint layer. Tools like NodeMaven provide residential and mobile IPs with city and ISP-level targeting specifically so the network signals align with the browser identity you're constructing.

AudioContext Fingerprinting
AudioContext fingerprinting is the subtlest of the four vectors because it exploits hardware-level variation in how a device's audio stack processes a signal — and it does this entirely silently, with no audio actually played.
The standard collection technique uses OfflineAudioContext to generate and process an audio signal in memory:
function getAudioFingerprint() {
return new Promise((resolve) => {
const AudioCtx = window.OfflineAudioContext || window.webkitOfflineAudioContext;
// 1 channel, 5000 samples, 44100 Hz sample rate
const context = new AudioCtx(1, 5000, 44100);

// Generate a triangle wave oscillator at 1000 Hz
const oscillator = context.createOscillator();
oscillator.type = 'triangle';
oscillator.frequency.value = 1000;

// Route through a compressor to amplify hardware-level variation
const compressor = context.createDynamicsCompressor();
compressor.threshold.value = -50;
compressor.knee.value = 40;
compressor.ratio.value = 12;
compressor.attack.value = 0;
compressor.release.value = 0.25;

oscillator.connect(compressor);
compressor.connect(context.destination);
oscillator.start(0);

context.oncomplete = (event) => {
// The channel data contains floating-point audio samples
// Their exact values vary by hardware audio stack
const channelData = event.renderedBuffer.getChannelData(0);
const hash = channelData.slice(4500).reduce((acc, val) => acc + Math.abs(val), 0);
resolve(hash.toString());
};

context.startRendering();
});
}

The floating-point output differs across devices because audio processing involves hardware-level DSP operations and floating-point math whose precision varies by audio driver, OS audio subsystem, and hardware. The hash of the summed channel data is a stable per-device identifier.
Spoofing approach: getChannelData override
You can't easily prevent the OfflineAudioContext from rendering — blocking it entirely is detectable. The correct approach is to intercept the buffer read and add deterministic noise to the channel data output.
(function() {
const PROFILE_SEED = 'your-profile-specific-seed-value';

function seededNoise(seed) {
let n = seed.split('').reduce((a, c) => a + c.charCodeAt(0), 0);
return function() {
n = (n * 1664525 + 1013904223) & 0xffffffff;
return (n >>> 0) / 0xffffffff * 0.0001 - 0.00005;
};
}

const noise = seededNoise(PROFILE_SEED);

const origGetChannelData = AudioBuffer.prototype.getChannelData;
AudioBuffer.prototype.getChannelData = function(channel) {
const data = origGetChannelData.call(this, channel);
const result = new Float32Array(data.length);
for (let i = 0; i < data.length; i++) {
result[i] = data[i] + noise();
}
return result;
};
})();

The noise magnitude here matters. Audio fingerprinting scripts sum floating-point values, so even sub-milliunit perturbations change the final hash. The key is that the noise must be seeded — not random — so the same hash is produced every time the profile runs.

Font Enumeration Browsers don't expose a direct API to list installed fonts. Fingerprinting scripts work around this by attempting to render text in specific fonts and measuring the dimensions of the output. If the text renders at the same dimensions as a known fallback font (usually monospace, sans-serif, or serif), the font isn't installed. If the dimensions differ, the font is present. function detectFont(fontName) { const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); const testString = 'mmmmmmmmmmlli'; const baseFonts = ['monospace', 'sans-serif', 'serif'];

function getTextWidth(font) {
ctx.font = 72px ${font};
return ctx.measureText(testString).width;
}

const baseWidths = baseFonts.map(getTextWidth);

ctx.font = 72px '${fontName}', ${baseFonts[0]};
const testWidth = ctx.measureText(testString).width;

// If the width matches none of the base font widths, the target font is installed
return !baseWidths.includes(testWidth);
}

// Test for platform-specific fonts
const fonts = [
'Arial', 'Calibri', 'Cambria', 'Segoe UI', // Windows
'Helvetica', 'San Francisco', 'Menlo', // macOS
'Ubuntu', 'Noto Sans', 'DejaVu Sans', // Linux
'Roboto', 'Droid Sans' // Android/Chrome OS
];

const installedFonts = fonts.filter(detectFont);

The list of installed fonts is platform-specific in a meaningful way. A machine running Windows 11 will have Calibri, Cambria, Segoe UI, and Consolas. A macOS machine will have Helvetica Neue, San Francisco, and Menlo. A Linux machine running Ubuntu will have DejaVu Sans and Ubuntu. This gives platforms a reliable signal for identifying both the OS and potentially the user's locale (language-specific fonts like Noto CJK or Arabic Typesetting).
Spoofing approach: measureText interception
The cleanest approach is to override CanvasRenderingContext2D.prototype.measureText to return the base font width for any font that shouldn't appear in your profile.
(function() {
// Define only the fonts appropriate for your profile's claimed OS/locale
const ALLOWED_FONTS = new Set([
'Arial', 'Calibri', 'Cambria', 'Comic Sans MS',
'Courier New', 'Georgia', 'Impact', 'Segoe UI',
'Times New Roman', 'Tahoma', 'Trebuchet MS', 'Verdana'
// Standard Windows 11 fonts — match to your UA's claimed OS
]);

const origMeasureText = CanvasRenderingContext2D.prototype.measureText;
CanvasRenderingContext2D.prototype.measureText = function(text) {
const fontFamily = this.font.match(/(?:^|\s)([\w\s]+)(?:,|$)/)?.[1]?.trim();
if (fontFamily && !ALLOWED_FONTS.has(fontFamily)) {
// Return the width of the fallback font for unlisted fonts
const ctx = this;
const originalFont = ctx.font;
ctx.font = ctx.font.replace(fontFamily, 'monospace');
const result = origMeasureText.call(ctx, text);
ctx.font = originalFont;
return result;
}
return origMeasureText.call(this, text);
};
})();

The font list in your override needs to match the OS claimed in your User-Agent. A Windows profile with macOS-exclusive fonts installed is a contradiction detection systems will catch.
Putting It Together: Consistency Is the Hard Part
Each of these spoofing techniques works in isolation. The difficult engineering problem is making them consistent with each other and with the rest of the profile.
Detection systems don't just look at each signal independently. They look for coherence across the whole profile:
Canvas rendering output should be consistent with the claimed GPU (WebGL renderer string)
Fonts should match the platform claimed in the User-Agent
AudioContext processing characteristics should be stable across sessions
The User-Agent should be internally consistent: OS version, browser version, platform, and Client Hints headers should all tell the same story
Timezone and language should match the proxy's geographic location
The last point is where network-layer configuration ties into the fingerprint layer. A browser profile claiming to be in New York — with a US locale, en-US language, and an EST timezone — but connecting through a Thai data-center IP has an obvious inconsistency. Using residential or mobile proxies geo-matched to the profile's claimed location is what closes that gap at the IP and network level.
Testing Your Profile
Before deploying any profile at scale, run it against the standard fingerprint testing tools:
BrowserLeaks (browserleaks.com) — tests Canvas, WebGL, fonts, WebRTC, and JS environment. Gives you direct visibility into what each API is exposing.
CreepJS (abrahamjuliot.github.io/creepjs) — the most aggressive public fingerprint analyzer. Specifically tests for spoofing inconsistencies, not just individual signal values. If your profile has cross-signal contradictions, CreepJS will find them.
Pixelscan (pixelscan.net) — commonly used as a reference in anti-detect browser communities. Useful for a quick pass/fail check on basic consistency.
The workflow is: build your profile, run it against all three, fix every inconsistency. Pay particular attention to CreepJS — it's designed specifically to catch the kind of partial spoofing that passes simpler checkers.
What the IP Layer Still Has to Do
Everything covered here operates at the JavaScript/browser API layer. It changes what fingerprinting scripts see when they query the browser. It doesn't change anything at the network layer.
Platforms that are serious about account integrity check both layers independently. A perfect browser fingerprint on a flagged data-center IP still triggers risk signals. Consistency between the fingerprint layer (what the browser reports) and the network layer (what the IP and TLS fingerprint say) is what makes a profile actually hold up under scrutiny.
The fingerprint setup covered here handles the browser side. The network side is a separate problem, and it requires its own clean infrastructure — residential or mobile IPs matched to the profile's claimed geography, with stable session behavior over time. These two layers together are what serious fingerprint isolation actually looks like in practice.

Web Scraping for E-commerce Price Monitoring in 2026

Mathew — Fri, 29 May 2026 06:44:11 +0000

Dynamic pricing algorithms dominate modern retail markets. Leading e-commerce giants like Amazon, eBay, and Walmart shift prices millions of times per day based on stock availability, competitor metrics, localized demand patterns, and user browsing history. For brands, retailers, and market analysts, capturing this real-time pricing intelligence is no longer optional—it is a vital operational necessity.
Building an enterprise-grade price monitoring framework requires more than writing basic HTML parsing routines. Large retail platforms implement sophisticated anti-scraping firewalls, behavioral pattern analyzers, and rate-limiting scripts. If you run a high-volume data harvesting script from a single server or an unstable proxy network, your scripts will quickly face HTTP 429 (Too Many Requests) failures, unsolvable Captcha walls, or outright IP blocks.
This technical guide covers how to build a production-ready e-commerce price scraper using Python. We will cover the layout of modern retail pages, implement robust parsing strategies, and deploy an automated proxy routing layer capable of bypassing enterprise firewalls at scale.
The Technical Hurdles of Enterprise E-Commerce Scraping
Before writing any Python script, data engineers must understand the specific technical countermeasures deployed by enterprise retail properties.
Structural Variations and A/B Testing
E-commerce giants do not serve uniform HTML layouts across their catalog properties. They regularly run concurrent A/B tests on their product pages, subtly changing class names, element hierarchies, and DOM structures. If your parsing script relies entirely on strict, deep CSS selectors (e.g., div.page > div.content > span.price), your data pipeline will break the moment a design variation goes live. Robust scrapers look for more resilient target identifiers or parse background JSON blobs embedded directly within the page source.
Behavioral Analysis and Rate Limiting
Modern Web Application Firewalls (WAFs) log the entry speed and request patterns of every incoming IP address. Human shoppers require several seconds to browse a page, read reviews, and navigate a storefront. An automated Python script using standard libraries can fire hundreds of concurrent requests per second. When a firewall observes an identical network identity executing rapid-fire requests against deep catalog links, it flags the traffic profile as non-human and throttles or blocks the connection.
Autonomous System Filtering
To scale price monitoring across thousands of products daily, developers often deploy scrapers inside cloud server instances (such as AWS, DigitalOcean, or Google Cloud). However, retail firewalls flag these hosting networks by checking incoming connections against global Autonomous System Number (ASN) registries. Because everyday retail shoppers do not browse consumer marketplaces from inside cloud computing centers, traffic originating from datacenter IP blocks faces near-instant blocks on high-security storefronts.
To counter these network-level filters, production-ready web scrapers route their traffic pools away from datacenter subnets. Utilizing NodeMaven residential proxies provides your data pipeline with authentic consumer IP identities assigned by retail ISPs to genuine households. This infrastructural layer keeps your request signatures clean and ensures your automated scrapers pass advanced reputation checks undetected.
Designing the Price Scraper Ecosystem
To construct a resilient price harvesting script, we use a modular Python stack designed to handle varying data formats and heavy data traffic safely:
Requests: A robust HTTP client library utilized to handle connection parameters, session persistence, custom headers, and proxy transport layers.
BeautifulSoup (bs4): An HTML parsing engine used to navigate the document object model, extract text content, and locate key data attributes.
Json: Used to process hidden metadata structures or data objects buried inside the server response.
Below is the complete, self-contained implementation blueprint for parsing data from major e-commerce platforms using integrated proxy rotation.
Python
import requests
from bs4 import BeautifulSoup
import json
import time
import random

=====================================================================

PROXY CONFIGURATION ZONE

=====================================================================

For high-volume e-commerce scraping, we leverage NodeMaven residential proxies.

Their backend handles the physical rotation across clean consumer nodes automatically.

PROXY_HOST = "gate.nodemaven.com"
PROXY_PORT = "8080"
PROXY_USER = "your_nodemaven_username-country-us-session-length-random"
PROXY_PASS = "your_nodemaven_secure_password"

Construct uniform proxy transport dictionary for the requests client

PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
PROXIES_CONFIG = {
"http": PROXY_URL,
"https": PROXY_URL
}

=====================================================================

HARDWARE PROFILE & HEADER SIMULATION

=====================================================================

Firewalls flag default Python-requests user agents instantly.

We maintain a collection of modern browser signatures to blend into organic retail traffic pools.

USER_AGENTS_POOL = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0",
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
]

def generate_organic_headers():
"""Generates consistent HTTP headers to pass initial browser handshake checks."""
return {
"User-Agent": random.choice(USER_AGENTS_POOL),
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"Accept-Encoding": "gzip, deflate, br",
"Connection": "keep-alive",
"Upgrade-Insecure-Requests": "1",
"Sec-Fetch-Dest": "document",
"Sec-Fetch-Mode": "navigate",
"Sec-Fetch-Site": "none",
"Sec-Fetch-User": "?1"
}

=====================================================================

EXTRACTION CORE LOGIC

=====================================================================

def extract_ecommerce_metrics(target_url):
"""
Executes connection routing via NodeMaven residential proxies, fetches HTML payload,
and implements resilient fallbacks to parse product title and pricing metrics.
"""
headers = generate_organic_headers()

try:
    print(f"[+] Fetching product metadata from target URL...")
    # Execute the HTTP GET request using our residential routing array
    response = requests.get(
        target_url, 
        headers=headers, 
        proxies=PROXIES_CONFIG, 
        timeout=15
    )

    # Guard against explicit HTTP error codes
    if response.status_code != 200:
        print(f"[-] Network Warning: Server returned response status code {response.status_code}")
        return None

    soup = BeautifulSoup(response.text, "html.parser")

    product_data = {
        "title": "N/A",
        "price": "N/A",
        "status": "Incomplete",
        "url": target_url
    }

    # Parse Platform Type based on Domain Name
    domain = target_url.lower()

    # 1. PARSING TARGET: AMAZON SPECIFIC SELECTORS
    if "amazon" in domain:
        # Resilient Title Fallbacks
        title_el = soup.find("span", {"id": "productTitle"})
        if title_el:
            product_data["title"] = title_el.get_text().strip()

        # Resilient Price Fallbacks (Checking whole price blocks and sub-components)
        price_whole = soup.find("span", {"class": "a-price-whole"})
        price_fraction = soup.find("span", {"class": "a-price-fraction"})

        if price_whole and price_fraction:
            product_data["price"] = f"${price_whole.get_text().strip()}{price_fraction.get_text().strip()}"
        else:
            price_alt = soup.find("span", {"class": "a-offscreen"})
            if price_alt:
                product_data["price"] = price_alt.get_text().strip()

    # 2. PARSING TARGET: EBAY SPECIFIC SELECTORS
    elif "ebay" in domain:
        title_el = soup.find("h1", {"class": "x-item-title__main-title"})
        if title_el:
            product_data["title"] = title_el.find("span", {"class": "ux-textspans"}).get_text().strip()

        price_el = soup.find("div", {"class": "x-price-primary"})
        if price_el:
            product_data["price"] = price_el.find("span", {"class": "ux-textspans"}).get_text().strip()

    # 3. PARSING TARGET: WALMART SPECIFIC SELECTORS
    elif "walmart" in domain:
        title_el = soup.find("h1", {"id": "main-title"})
        if title_el:
            product_data["title"] = title_el.get_text().strip()

        price_el = soup.find("span", {"itemprop": "price"})
        if price_el:
            product_data["price"] = price_el.get_text().strip()
        else:
            # Fallback to internal embedded JSON-LD schema payload if DOM elements are scrambled
            json_schema = soup.find("script", {"type": "application/ld+json"})
            if json_schema:
                try:
                    data_blob = json.loads(json_schema.get_text())
                    if isinstance(data_blob, list):
                        data_blob = data_blob[0]
                    product_data["price"] = data_blob.get("offers", {}).get("price", "N/A")
                except Exception:
                    pass

    # Data Validation and Formatting
    if product_data["title"] != "N/A" and product_data["price"] != "N/A":
        product_data["status"] = "Success"

    return product_data

except requests.exceptions.ProxyError:
    print("[-] Technical Failure: Proxy routing authentication or connection error.")
except requests.exceptions.Timeout:
    print("[-] Technical Failure: The connection timed out. Target server took too long to respond.")
except Exception as err:
    print(f"[-] Execution Error Encountered: {str(err)}")
    return None

=====================================================================

EXECUTION LAYER RUNNER

=====================================================================

if name == "main":
# Test items list covering various enterprise retail environments
target_catalog = [
"https://www.amazon.com/dp/B09G96TFFG",
"https://www.ebay.com/itm/123456789012",
"https://www.walmart.com/ip/543210987"
]

scraped_results = []

print("[*] Launching Price Monitoring Automated Scraper...")
for idx, product_url in enumerate(target_catalog):
    result = extract_ecommerce_metrics(product_url)
    if result:
        scraped_results.append(result)
        print(f"[Success] Item {idx+1}: {result['title']} -> {result['price']}")

    # Humanize request speed by executing a variable cooldown between items
    # NodeMaven proxies automatically handle backend rotation to keep network signatures safe,
    # but adding brief pauses simulates realistic human browsing behavior.
    cooldown_period = random.uniform(3.0, 7.0)
    print(f"[*] Enforcing network cooldown for {cooldown_period:.2f} seconds...")
    time.sleep(cooldown_period)

print("\n[*] Summary of Final Collected E-Commerce Data Metrics:")
print(json.dumps(scraped_results, indent=4))

Advanced Data Extraction Practices for Enterprise Scrapers
To transition this basic scraping framework into a high-capacity production monitoring engine, you must plan for complex data scenarios beyond standard DOM parsing.
Utilizing Hidden JSON-LD Metadata Structures
Many modern e-commerce platforms dynamically inject their pricing data via asynchronous JavaScript calls after the raw HTML page transfers. If your scraper relies solely on standard HTML elements, it may pull old or incomplete pricing blocks.
To bypass this hurdle, look for embedded application metadata blocks inside the raw HTML (). These structured objects contain absolute, non-scrambled data models for the product title, SKU, brand, and active pricing structures. Parsing this payload directly bypasses complex frontend layout shifts and A/B test variations entirely. Managing Session Context vs. Infinite Rotation When harvesting price data across global platforms, you must match your rotation settings to your target data target: Per-Request Rotation: This is optimal for broad scraping operations covering massive lists of product URLs. Each request routes through a fresh consumer node. If an individual node faces a sudden block or speed penalty, your next connection request moves to a completely different IP range, preventing cascading data failures. Sticky Session Management: This setup is required when your scraper must add a product to a digital cart, enter regional zip codes to calculate localized shipping rates, or step through continuous navigation loops. Keeping your session alive ensures you maintain consistent state data throughout the transaction sequence. Structuring Robust Data Normalization E-commerce pricing models use varying currency symbols, decimal dividers, and text flags (e.g., "Sale Price", "Bundle Options", or "List Price"). Your extraction pipeline must scrub raw string text down to clean floating-point numerical values before pushing data to a production database. Use Python text parsing logic to isolate the numeric data from regional currency markers safely. Deploying Your Scraping Operations Safely To build a long-term, reliable market intelligence platform, combine clean coding practices with high-performance networking tools. If you are setting up your first scraping environment, reviewing a dedicated Python web scraping tutorial helps structure your script files, build virtual environment containers, and implement robust error-handling pipelines correctly. By pairing a modular Python script layout with <a href="https://nodemaven.com/blog/python-web-scraping/">NodeMaven residential proxies</a>, you remove network-level vulnerabilities from your scraping operations. This technical setup ensures your automated data tools pass strict firewall reputation checks undetected, allowing you to harvest high-fidelity market data and maintain an active edge in competitive e-commerce markets.

How to Detect and Fix WebRTC Leaks in 2026 — Complete Developer Guide

Mathew — Wed, 27 May 2026 06:11:00 +0000

If you use proxies, VPNs, anti-detect browsers, or privacy-focused setups, WebRTC leaks are still one of the easiest ways for websites to expose your real IP address.
A lot of developers assume that once traffic is routed through a proxy, the browser becomes fully anonymous. Unfortunately, that’s not how modern browsers work.
Even with a residential proxy enabled, WebRTC can silently reveal:
your local IP
your ISP-assigned public IP
network interfaces
IPv6 addresses
VPN mismatches
This is one of the main reasons websites detect automation, multi-account setups, and fake browsing environments.
In this guide, we’ll break down:
how WebRTC leaks happen
how browsers expose ICE candidates
how to test for leaks
how to fix WebRTC leaks in Chrome and Firefox
how anti-detect browsers handle WebRTC
why proxy quality still matters
What Is a WebRTC Leak?
WebRTC stands for Web Real-Time Communication.
It’s a browser technology designed for:
voice calls
video conferencing
peer-to-peer communication
real-time data streaming
Applications like Google Meet, Discord, Zoom Web SDK, and browser-based chat systems all rely on WebRTC.
The problem is that WebRTC can bypass your proxy or VPN during the connection discovery process.
When a browser creates a peer connection, it gathers ICE candidates to determine the fastest network route between devices.
These ICE candidates may include:
local IP addresses
private LAN addresses
public ISP IPs
IPv6 addresses
That means a website can sometimes discover your real IP even while your traffic appears proxied.
How WebRTC Leaks Actually Work
The leak usually happens during STUN requests.
STUN stands for Session Traversal Utilities for NAT.
Browsers use STUN servers to determine public-facing IP addresses during peer communication.
Here’s a simplified example:
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

pc.createDataChannel("");

pc.onicecandidate = (event) => {
if (event.candidate) {
console.log(event.candidate.candidate);
}
};

pc.createOffer()
.then(offer => pc.setLocalDescription(offer));
This simple script can expose:
local network IPs
VPN mismatches
proxy inconsistencies
IPv6 addresses
Many fingerprinting systems run similar checks silently in the background.
Why WebRTC Leaks Matter for Proxies
If you’re using proxies for:
web scraping
multi-account management
ad verification
browser automation
social media workflows
then a WebRTC leak can completely destroy your setup consistency.
For example:
browser IP says Germany
WebRTC exposes US ISP IP
timezone says Singapore
That mismatch immediately increases fingerprint suspicion.
Modern anti-bot systems compare:
HTTP IP
DNS routing
WebRTC candidates
browser fingerprint
geolocation consistency
If even one layer looks suspicious, risk scores go up.
How to Test for a WebRTC Leak
The easiest method is using a browser-based leak detection tool.
You can quickly verify your setup using the NodeMaven WebRTC leak test before running automation sessions or account logins.
A proper WebRTC test should check:
public IP exposure
local IP exposure
IPv6 leaks
ICE candidates
STUN responses
If your real ISP IP appears anywhere in the results, your setup is leaking.
Common Types of WebRTC Leaks
Local IP Leaks
These expose internal addresses like:
192.168.x.x
10.x.x.x
172.16.x.x
These leaks are less dangerous but still contribute to browser fingerprint uniqueness.
Public IP Leaks
This is the serious one.
Your actual ISP-assigned IP becomes visible despite using a proxy or VPN.
This completely defeats anonymity.
IPv6 Leaks
Many users disable IPv4 leaks but forget IPv6.
Browsers may expose IPv6 interfaces independently of proxy routing.
How to Fix WebRTC Leaks in Chrome
Chrome still handles WebRTC aggressively by default.
There’s no perfect built-in disable switch anymore, but several methods reduce exposure significantly.
Method 1: Use Chrome Flags
Open:
chrome://flags/
Search for:
Anonymize local IPs exposed by WebRTC
Enable it.
This helps hide local network addresses from ICE gathering.
Method 2: Install a WebRTC Extension
Extensions like:
WebRTC Control
uBlock Origin advanced settings
WebRTC Leak Prevent
can restrict ICE candidate exposure.
Be careful though.
Some extensions break:
Google Meet
Discord
browser voice apps
Always test functionality afterward.
Method 3: Disable Non-Proxied UDP
Chrome policies allow limiting UDP behavior.
Launch Chrome with:
--force-webrtc-ip-handling-policy=disable_non_proxied_udp
This is one of the more effective fixes for proxy environments.
Fixing WebRTC Leaks in Firefox
Firefox gives much more control than Chromium browsers.
That’s one reason many privacy-focused developers still prefer it.
Open:
about:config
Search for:
media.peerconnection.enabled
Set it to:
false
This fully disables WebRTC.
You can also configure:
media.peerconnection.ice.no_host
and set it to:
true
That blocks local ICE candidate exposure while preserving some WebRTC functionality.
Brave Browser and WebRTC
Brave includes built-in fingerprint protections.
Open:
Settings → Privacy and Security → WebRTC IP Handling Policy
Recommended option:
Disable non-proxied UDP
This works well for most proxy setups.
Still, you should always test manually because browser updates sometimes change WebRTC behavior.
WebRTC Leaks in Anti-Detect Browsers
Anti-detect browsers usually patch WebRTC internally.
Popular tools often:
spoof ICE candidates
disable local IP exposure
align WebRTC with proxy IP
emulate consistent network fingerprints
But quality varies massively between browsers.
Some cheaper anti-detect tools simply hide visible candidates while background requests still leak.
Always validate externally.
Even experienced automation teams sometimes assume protection is active when it isn’t.
Why Residential Proxies Matter
Even with WebRTC patched, low-quality proxies create other detection problems.
Cheap datacenter proxies often produce:
mismatched ASN fingerprints
suspicious geolocation patterns
reused IP histories
spam-associated ranges
Residential proxies usually blend in much more naturally because the IPs belong to real ISP networks.
That consistency helps reduce overall fingerprint anomalies.
Detecting Leaks Programmatically
Developers often want automated leak testing during CI pipelines or browser automation.
Here’s a basic ICE candidate monitor:
async function detectWebRTCLeak() {
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

pc.createDataChannel("");

pc.onicecandidate = (event) => {
if (event.candidate) {
console.log("ICE Candidate:", event.candidate.candidate);
}
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
}

detectWebRTCLeak();
You can parse candidates for:
local IPs
public IPs
IPv6 exposure
TURN routing inconsistencies
This is useful in Puppeteer, Playwright, and Selenium workflows.
WebRTC and Browser Fingerprinting
Modern fingerprinting systems rarely rely on a single signal.
Instead they combine:
canvas fingerprinting
audio fingerprinting
font rendering
timezone
WebGL
WebRTC
IP consistency
That means fixing WebRTC alone is not enough for high-risk environments.
You still need:
consistent geolocation
proper timezone alignment
clean browser profiles
stable proxy routing
Testing Proxies Before Automation
A common mistake is testing only HTTP connectivity.
Good automation workflows should validate:
browser fingerprint
DNS routing
WebRTC
TLS fingerprints
timezone consistency
before launching production sessions.
This prevents wasting accounts on broken configurations.
Recommended Browser Configuration
A relatively stable privacy-oriented setup usually includes:
residential proxy
separate browser profile
disabled WebRTC leaks
matching timezone
isolated cookies
clean local storage
For Chromium browsers specifically:
--disable-features=WebRtcHideLocalIpsWithMdns
--force-webrtc-ip-handling-policy=disable_non_proxied_udp
can improve consistency significantly.
Common Mistakes Developers Make
Assuming VPNs Fully Block WebRTC
Many VPNs do not fully prevent ICE leaks.
Browser behavior still matters.
Ignoring IPv6
IPv6 leaks remain surprisingly common in 2026.
Using Shared Browser Profiles
Cross-session contamination creates fingerprint inconsistencies.
Trusting Extensions Blindly
Extensions help, but browser updates can silently break them.
Always retest after updates.
Final Thoughts
WebRTC leaks remain one of the most overlooked privacy and automation risks in modern browsers.
Even experienced developers often focus entirely on proxies while forgetting that browsers expose networking information through multiple layers.
The safest workflow is always:
configure proxy correctly
patch or restrict WebRTC
validate leaks manually
test browser fingerprint consistency
isolate sessions properly
And most importantly, never assume your setup is safe without testing it.
Before running any automation, account management, or scraping workflow, it’s worth checking your browser using the NodeMaven WebRTC leak test to make sure your real IP isn’t leaking through ICE candidates or STUN requests.