Residential Proxy Detection: What a Site Can Tell About the Exit

Buying residential bandwidth does not automatically make a browser look residential. A destination can read registration records, routing data, reverse delegation, timing and a TLS handshake before it renders a page, and those observations disagree often enough that none of them is a verdict on its own. BotBrowser supports a declared browser profile and configurable proxy routing for an authorized task. It cannot change the exit IP's ASN, its routing or reverse delegation, and it does not make a datacenter address residential or guarantee a destination's classification.

TL;DR

• Registration, announced routing and reverse DNS are three different records. An address can carry a consumer ISP registration and still be announced from a hosting network.
• An ASN lookup answers "who is allocated this prefix", not "is this a home connection". RIR data is allocation data.
• Self-published geofeeds may be wrong, and the standard tells consumers to verify accuracy rather than trust it.
• Latency and jitter describe a path under current conditions. Congestion, a distant datacenter and a throttled uplink can produce the same shape.
• A JA3 or JA4 value describes a TLS handshake. When a proxy terminates TLS, the handshake a destination sees belongs to that proxy, not to the browser behind it.
• Record which component owns each observation. A profile change can move browser-side values; it cannot move an ASN, a route announcement or a delegated pointer.

Contents

• What the destination observes before the page loads
• Registration, routing, and reverse delegation are separate records
• Run a classifier over supplied records
• Latency shape and handshake are weaker evidence than they look
• What a browser profile changes and what it cannot
• Practical conclusion

What the destination observes before the page loads

The first thing a site learns is the source address of the connection. Everything else that follows is an inference attached to that address, and those inferences come from systems with narrower jobs. Regional internet registries allocate address space to organizations. Routing systems announce prefixes. Domain operators publish pointers and location files. Each system answers one question, and the answer is only as specific as that question.

That is why a "residential proxy" question usually turns into a disagreement about vocabulary. A team buys an address that appears in a consumer ISP block, then sees a block page anyway. A different team runs a datacenter address that passes for months, then fails after a routing change. Neither outcome is mysterious once the observations are separated: the address did not change, but the record the destination consulted did.

Observation	Typical source	What it establishes	What it cannot establish	Who can change it
Prefix registration	RIR RDAP or WHOIS record	Which organization was allocated the address block	Whether a customer uses that address from a home or an office	The registry, through a transfer or reassignment
Route announcement	Border gateway data	Which network currently announces the prefix	The physical location or access technology	The announcing network
Reverse delegation	PTR record	Which name the address owner published for that address	That the published name is current or truthful	The operator holding the reverse zone
Self-published location	Geofeed file	The locality the publisher claims for the prefix	That the claim is accurate for one address	The publisher
Path timing	Request measurements	How the path behaved during the sample	What kind of access network produced it	Nobody, for a single sample
TLS handshake	ClientHello and certificate exchange	Which client stack negotiated the connection	Which browser or device originated the request	Whoever terminates TLS

The practical consequence is that a residential label is a statement about records, not a property of the wire. An address that a destination classifies as residential today can be reclassified after an allocation transfer, and an address that passes every static check can still fail a behavioral rule applied to the session.

Registration, routing, and reverse delegation are separate records

Registration data is the most quoted and the most misread. A registry record describes an allocation to an organization. It can say that a block belongs to an internet service provider, and it can say which country the allocation was made in. It does not say that a specific customer has a specific connection type at a specific address; an RDAP record for 203.0.113.24 is an allocation object. Reading a consumer ISP registration and concluding "residential exit" skips the step where a provider assigns that address to a subscriber, and providers reassign addresses constantly.

Routing data answers a different question. An announced prefix is reachable through a network, and the announcing network is not necessarily the organization that holds the registration. A provider can announce customer space from a different autonomous system, and a hosting company can originate a prefix that a registry still associates with a regional ISP. Treating the announcing network as the owner, or the owner as the announcer, produces confident statements that the underlying data does not support.

Reverse DNS is the weakest of the three as an identity signal, because it is a delegated pointer that anyone controlling the reverse zone can publish. A pointer that reads like a consumer hostname can be stale, reassigned, or simply chosen by an operator who likes the naming convention. A missing pointer is equally uninformative: many legitimate networks never publish one. If a destination uses reverse names at all, it is using them as one input in a weighted decision, not as proof.

Location files deserve the same caution. RFC 8805 section 3.3 defines a format for self-published IP geolocation, and the specification is explicit that inaccuracies occur at many levels. It tells consumers to verify published locality to the extent practical and to decide their own discrepancy thresholds. A geofeed therefore supports a location claim made by its publisher; it does not certify that a given address is a home connection, and it does not bind a destination to accept that claim.

Registration and routing disagree often enough that a single-field classifier will mislabel real traffic. The useful question is not "does this address look residential", but "which records agree, which disagree, and what does each disagreement mean for the decision I am about to make". For the route-level mechanics behind a browser request, proxy configuration and geographic alignment covers how an endpoint is selected and how page-visible values are derived from the observed public address. That article configures the route; this one decides what the route's records can support.

Run a classifier over supplied records

The example below classifies five synthetic records. It makes no network request, reads no live site, and does not claim that any real address has these properties. Its purpose is to show the shape of a defensible decision: each input becomes its own field, disagreements are counted, and no field is collapsed into a residential verdict.

import assert from 'node:assert/strict';

const records = [
  {
    id: 'registered-residential-isp',
    asn: 64500,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.example-isp.test',
    ptrOwner: 'example-isp.test',
  },
  {
    id: 'registered-host',
    asn: 64501,
    registeredUse: 'hosting',
    announced: true,
    ptrSuffix: 'cloud.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'isp-asn-announced-by-host',
    asn: 64502,
    registeredUse: 'isp',
    announced: false,
    ptrSuffix: 'static.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'stale-pointer',
    asn: 64503,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.old-name.test',
    ptrOwner: 'other-owner.test',
  },
  { id: 'no-pointer', asn: 64504, registeredUse: 'isp', announced: true, ptrSuffix: null, ptrOwner: null },
];

const registeredUseLabels = { isp: 'isp-registration', hosting: 'hosting-registration' };

function classify(record) {
  const registration = registeredUseLabels[record.registeredUse] ?? 'unknown-registration';
  const routing = record.announced ? 'announced' : 'not-announced-in-sample';
  const reverseDns = record.ptrSuffix
    ? record.ptrOwner && record.ptrSuffix.endsWith(`.${record.ptrOwner}`)
      ? 'delegated-to-registrant'
      : 'not-delegated-to-registrant'
    : 'absent';
  const disagreements = [
    registration === 'isp-registration' && reverseDns === 'not-delegated-to-registrant',
    registration === 'isp-registration' && routing === 'not-announced-in-sample',
  ].filter(Boolean).length;
  return { registration, routing, reverseDns, disagreements };
}

for (const record of records) {
  const result = classify(record);
  console.log(
    `${record.id} registration=${result.registration} routing=${result.routing} ptr=${result.reverseDns} disagreements=${result.disagreements}`
  );
}

Paste it into a local .mjs file and run it with node. The output is five lines, one per record, with the same field names the table uses. Read them as a small comparison rather than a verdict.

registered-residential-isp registration=isp-registration routing=announced ptr=delegated-to-registrant disagreements=0
registered-host registration=hosting-registration routing=announced ptr=delegated-to-registrant disagreements=0
isp-asn-announced-by-host registration=isp-registration routing=not-announced-in-sample ptr=delegated-to-registrant disagreements=1
stale-pointer registration=isp-registration routing=announced ptr=not-delegated-to-registrant disagreements=1
no-pointer registration=isp-registration routing=announced ptr=absent disagreements=0

Two of the five records disagree, and both disagreements are informative. The third record has a consumer ISP registration but is not announced in the sample, which is the pattern you would expect when a prefix is reassigned or when the observation was taken from an incomplete routing view. The fourth has a pointer that no longer belongs to the registrant, which is what a stale or reissued address looks like. Neither case produces "residential" or "datacenter" as an answer, because the inputs do not support that answer.

The fifth record is the one that catches teams out. A consumer registration with no reverse pointer scores zero disagreements under these rules, yet it tells a destination almost nothing. A destination that weights reverse names heavily would treat it differently from one that ignores them. That difference is a policy choice on the destination's side, not a fact about the address.

This classifier is deliberately small. It does not resolve real prefixes, validate the registry's records, weigh disagreements into a score, or model a vendor's decision. Any cut-off added to it is your own policy with its own error rate, and that cut-off belongs next to the decision it produced.

Latency shape and handshake are weaker evidence than they look

Timing feels like a direct measurement, which is why it gets over-trusted. A request from a consumer connection often shows higher and more variable latency than one from a datacenter, so teams read a tight distribution as a hosting signal. The inference runs in both directions, though. A congested home uplink can look slow and erratic, and a datacenter in the same city can look fast and stable; record p50 and p95 with the sample count instead of one number. A mobile network adds its own variability, and a proxy adds a hop whose behavior belongs to the provider rather than to the client.

That makes a single sample useless as a classifier. If timing is used at all, it belongs in a distribution with the sample size, the time window and the route recorded, and even then it supports only "this path behaved like this during the window". A destination comparing a session against a claimed device has a stronger question available: does the claimed device's typical behavior match what the session produced? A desktop profile claiming a fiber connection while every request arrives with the shape of a distant relay is a mismatch worth explaining, and the explanation may be the relay rather than the access network.

The handshake is the observation teams most often get wrong in the other direction. JA3 and JA4 are values derived from a TLS handshake, and vendor documentation is clear that they are computed during that handshake and can be absent when no handshake is calculated for a request. What the value describes is the client stack that negotiated the connection. Whether that stack is the browser on the reader's machine depends entirely on where TLS terminates.

When a proxy forwards with CONNECT, the specification describes the proxy as blind-forwarding data in both directions once the tunnel is open. In that mode the destination's TLS handshake is with the browser, and the destination's TCP peer is the proxy. When a proxy instead terminates TLS on port 443 and re-originates it, the destination's handshake belongs to the proxy, and the browser's handshake is a separate connection the destination never sees. Both arrangements are common, and they produce opposite conclusions from the same "JA3 changed" observation. The TLS and HTTP/2 fingerprint article explains how the values are assembled and why an unsorted hash measures ordering the client does not fix; this article's point is narrower: identify the terminator before attributing a handshake to a browser.

There is also an ordering trap. A destination can compare the handshake against a claimed browser version, then compare the claimed version against the User-Agent and Client Hints, then compare the address's registration against the claimed country. Those comparisons are separate rules with separate error rates. A session that fails one of them has not necessarily failed the others, and a report that merges them into "fingerprint mismatch" cannot tell a team which rule fired.

Reputation data sits alongside these observations rather than above them. A destination can hold lists that mark address ranges or autonomous systems, and it can apply them before any page loads. That is a policy input about prior behavior attributed to a range, not a measurement of the current session, and it changes when the list changes rather than when the client changes. A team that responds to a reputation block by adjusting a browser profile is treating a list decision as a browser problem.

What a browser profile changes and what it cannot

A declared profile controls values the browser generates and exposes, including the value returned by navigator.userAgentData. User-Agent and Client Hints, timezone and locale, screen metrics, canvas and WebGL output, font enumeration, audio processing characteristics and the consistency between those surfaces are all inside that boundary. A profile can keep them aligned with each other and with a declared device, which is what makes a session internally coherent.

The exit address is outside that boundary; --proxy-server chooses that address, and the profile does not change it. A profile cannot change which autonomous system announces the address, cannot change the registration of the prefix, cannot publish a reverse pointer, and cannot make a hosting address belong to a consumer ISP. It also cannot change the route the packets take or the reputation lists a destination consults. When the problem is one of those, profile work produces a session that is internally consistent and still classified the way the address is classified.

That distinction is what makes the residential question tractable. Ask which layer the failing observation belongs to. If the destination rejected the session because the claimed device and the observed browser values disagreed, the profile layer is the relevant one. If it rejected the session because the address sits in a hosting range, or because a reverse pointer names a cloud provider, no profile change moves that outcome. If the destination refused the request before rendering, the failure may not be about identity at all.

For teams running several contexts through one provider, IPv4 and IPv6 proxy consistency covers the route-level failures that look like identity problems: a family that silently falls back, a resolver that answers from a different path, a route that changes mid-session. Those failures produce inconsistent observations from the same browser, and they are diagnosed at the route layer rather than by adjusting a profile.

The same discipline applies to the account. A destination's history with an account, its prior sessions, and the data it already holds are outside every browser and network layer discussed here. A clean exit does not reset account history, and a residential address does not make an established account behave like a new one. Treat account state as its own input with its own owner.

Practical conclusion

Record the exit classification inputs with the job: the address, the registration record and its date, the announcing network, the reverse delegation if any, the sample window for timing, and the TLS terminator. Then name the component that owns each one and the decision it supports. That record answers the question a residential proxy purchase is supposed to answer, and it shows when the answer depends on a record rather than on the browser.

FAQ

Does a residential ASN guarantee that a site treats the session as residential?

No. An ASN identifies the network allocated to an organization. A destination can weigh registration, routing, reverse delegation, timing, reputation lists and session behavior in any combination, and it can change that weighting without notice. A residential registration removes one possible signal; it does not control the decision.

Why does a proxy show a different JA3 or JA4 than the browser behind it?

Because the value describes whichever stack completed the TLS handshake with the destination. If the proxy terminates TLS and opens a new connection upstream, the destination sees the proxy's handshake, and the observed JA3 belongs to the terminator. If the proxy forwards a CONNECT tunnel, the destination sees the browser's. Capture where the handshake ends before drawing a conclusion about the client.

Can a geofeed or WHOIS record prove an address is a home connection?

Neither record is designed for that. A geofeed publishes the location its operator claims, and the standard tells consumers to verify accuracy. A registry record describes an allocation to an organization. Both can be accurate and still say nothing about how a specific subscriber line is used at a specific moment.

Is a slow, jittery connection evidence of a residential exit?

It is evidence about the path during the sample. Congestion, distance, a mobile uplink, a relay hop and a throttled link all produce variation. Without a distribution, a sample window and the route, timing supports a description of the path rather than a classification of the access network.

What should a team do when a destination blocks a session with a residential address?

Start with the observation the destination actually used, if it is available, and map it to the layer that owns it. A pre-render refusal may be a reputation or access rule; a page-level challenge may be behavioral; a mismatch report may name the compared fields. Changing the profile addresses only the browser-side layer, so confirm the failing layer before spending on more exit bandwidth.

Sources

• RFC 8805: A Format for Self-Published IP Geolocation Feeds
• RFC 9110: HTTP Semantics, CONNECT and tunnels
• RFC 1035: Domain names, PTR records
• ARIN: Registration Data Access Protocol
• Cloudflare: JA3 and JA4 fingerprints
• Cloudflare: IP Access rules by address, ASN or country
• BotBrowser proxy configuration
• BotBrowser automation consistency