Client signals

Fingerprinting and proxies: the IP can change while the client still looks wrong

TLS hello shape, HTTP/2 settings, and header order are not proxy settings. Changing the exit IP does not change them.

TLS and headers Usage Logs Updated 2026-06-12

By

Route and client are two separate signals

The first bad read on proxy failures is blaming the exit IP. Sometimes that is right: bad subnet, loud ASN, exhausted pool, target hates datacenter ranges. A common counterexample involves the same test run twice — once with Playwright and once with a Python worker — both going through the same residential route, with different results. One gets content. One gets a challenge page.

The proxy IP is the outside address the target sees. The client fingerprint is the shape of the software making the request. Same IP class, different client, different result. Same client, different proxies, often the same block.

Run one route first. If the result is bad, scaling only hides which part failed and makes the provider meter harder to explain.

One test log from that kind of split looks like this. Status alone is not enough — a 200 can be a block page.

# pasted rows, not the full run
2024-11-04 10:14 datacenter-route   requests   openssl h2=no  403 body=7211  meter=19804 rows=0   hard block
2024-11-04 10:15 volume-route       requests   openssl h2=no  200 body=6127  meter=18429 rows=0   title: Access verification
2024-11-04 10:17 premium-route      requests   openssl h2=no  200 body=6127  meter=18602 rows=0   same body, selector miss
2024-11-04 10:20 premium-route      playwright  chrome  h2=yes 200 body=49188 meter=74031 rows=214 content ok
notes: route changed twice; client shape changed once; browser run wrote rows

The proxy carried traffic each time. The app dashboard showed 200s and almost no saved rows on the first three runs. The raw body said the target was classifying the client, not just the IP.

TLS fingerprints are not proxy settings

JA3 and JA4 are hashes of the TLS ClientHello shape: cipher order, extensions, and supported groups. Browsers, Python libraries, Go clients, curl builds, mobile apps, and custom HTTP stacks each produce a distinct hash. The server sees it before any HTTP exchange happens.

If the target expects a browser-like handshake and the worker sends a library-like handshake, a residential proxy does not change that. The target sees the same client fingerprint arriving from a different IP.

HTTP/2 settings and header order have the same problem. A browser sends headers in a pattern that belongs to its network stack. A fake User-Agent string on a client that still negotiates like a script is straightforward to classify.

bad mix seen in failed run:
user-agent: chrome-looking
accept-language: missing
sec-fetch-site: missing
accept-encoding: gzip only
http_version: 1.1
tls_shape: library
result: soft block, status 200

JavaScript execution is a separate split. Some pages expect cookies, storage, redirects, timing, and browser APIs before useful content appears. A proxy carries that traffic. It does not make a raw HTTP client execute JavaScript the way Playwright or Puppeteer does.

socks5h resolves DNS through the proxy instead of locally, which keeps routing cleaner. It does not rewrite TLS behavior, fix header order, add HTTP/2 settings, or execute JavaScript.

Meter gaps during fingerprint failures are normal

The proxy meters every transferred byte: redirects, retries, failed challenge pages, browser assets, preflight requests, and pages thrown away by parsers. The app dashboard usually counts only accepted payloads. Those numbers are not supposed to match.

provider_metered=1.84 GB
app_dashboard=312 MB
saved_items=118
blocked_200_pages=924
retry_policy=3x
reason_for_gap=app only counted accepted payloads

That gap is expected when most responses are block pages the parser discards. The proxy did carry traffic. The application did not count most of it because most of it was useless.

The Proxynade dashboard network logs show host, outcome, latency, and byte totals per request. Usage logs export as CSV. Those are the numbers that match the bill, not the app-level counters.

Plan selection follows diagnosis, not the reverse

Datacenter, Volume Residential ($0.89/GB), and Premium Residential ($5.00/GB) are route choices. Compare them when IP reputation or ASN policy is the suspected cause of a block. They are not a substitute for a client that looks like the wrong software.

The Proxynade pool gateway is http://proxynade.net:2555 with username/password auth. The expanded username carries routing options: base user plus a plan token (volume, premium, or datacenter), an optional country-<cc> flag, and an optional lifetime-<minutes> rotation window. Datacenter lines skip the lifetime token.

Switching from datacenter to premium residential changes the exit ASN and IP reputation. It does not change the TLS fingerprint, header order, or HTTP/2 settings the client sends. If those are the signals causing the block, plan changes will not fix it.

Fingerprinting FAQ

Does changing the proxy IP fix a fingerprint block? No. The exit IP and the client fingerprint are separate signals. A target classifying the client shape returns the same block regardless of which IP the request arrives from.

What is JA3 or JA4? A hash of the TLS ClientHello shape — cipher order, extensions, and supported groups. Browsers, Python libraries, Go clients, and curl each produce a distinct hash that is visible to the server before any HTTP exchange.

Can a residential proxy fix a TLS fingerprint mismatch? No. The proxy carries traffic between the client and the target. It does not rewrite the TLS handshake. The client's library or browser produces the fingerprint, not the proxy.

Why does the proxy meter show more bytes than my app dashboard? The proxy counts every transferred byte including redirects, retries, failed challenge pages, and browser assets. The app dashboard usually counts only accepted payloads.

What does socks5h do that socks5 does not? socks5h resolves DNS through the proxy rather than locally. It keeps routing cleaner but does not change TLS behavior, header order, or HTTP/2 settings.

Debug order

  • Confirm the proxy carried traffic via dashboard network logs before blaming the route.
  • Check raw response body, not just status code — a 200 can be a block page.
  • Compare body size between a browser run and a script run on the same route.
  • If browser gets content and script does not, the issue is client shape, not the proxy.
  • Switch plan only after confirming IP reputation or ASN is the suspect.