Detección de proxies residenciales: qué revela la salida

Comprar ancho de banda residencial no convierte automáticamente un navegador en residencial. Un destino puede leer registros de asignación, datos de encaminamiento, delegación inversa, tiempos y un handshake TLS antes de renderizar una página, y esas observaciones discrepan con suficiente frecuencia como para que ninguna sea un veredicto por sí sola. BotBrowser proporciona un perfil de navegador declarado y un encaminamiento por proxy configurable para una tarea autorizada. No puede cambiar el ASN de la IP de salida, su encaminamiento ni su delegación inversa, y no convierte una dirección de centro de datos en residencial ni garantiza la clasificación o aceptación por parte de un destino.

TL;DR

• Registro, ruta anunciada y DNS inverso son tres registros distintos. Una dirección puede tener un registro de ISP de consumo y anunciarse desde una red de hosting.
• Una consulta de ASN responde «a quién se le asignó este prefijo», no «si es una conexión doméstica». Los datos del RIR son datos de asignación.
• Los geofeeds autopublicados pueden ser erróneos, y el estándar indica a los consumidores que verifiquen su exactitud en lugar de confiar en ella.
• Latencia y jitter describen una ruta en las condiciones actuales. Congestión, un centro de datos lejano y un enlace limitado pueden producir la misma forma.
• Un valor JA3 o JA4 describe un handshake TLS. Cuando un proxy termina TLS, el handshake que ve el destino pertenece a ese proxy, no al navegador que está detrás.
• Registra qué componente posee cada observación. Un cambio de perfil puede mover valores del navegador; no puede mover un ASN, un anuncio de ruta ni un puntero delegado.

Contenido

• Qué observa el destino antes de cargar la página
• Registro, encaminamiento y delegación inversa son registros separados
• Ejecutar un clasificador sobre registros aportados
• Los tiempos y el handshake son pruebas más débiles de lo que parecen
• Qué cambia un perfil de navegador y qué no
• Conclusión práctica

Qué observa el destino antes de cargar la página

Lo primero que aprende un sitio es la dirección de origen de la conexión. Todo lo que sigue es una inferencia asociada a esa dirección, y esas inferencias proceden de sistemas con tareas más estrechas. Los registros regionales de internet asignan espacio de direcciones a organizaciones. Los sistemas de encaminamiento anuncian prefijos. Los operadores de dominios publican punteros y archivos de ubicación. Cada sistema responde una pregunta, y la respuesta solo es tan específica como esa pregunta.

Por eso una pregunta sobre «proxies residenciales» suele convertirse en una discusión sobre vocabulario. Un equipo compra una dirección que aparece en un bloque de ISP de consumo y aun así recibe una página de bloqueo. Otro equipo usa una dirección de centro de datos que pasa durante meses y falla tras un cambio de encaminamiento. Ninguno de los dos resultados es misterioso cuando se separan las observaciones: la dirección no cambió, pero sí cambió el registro que consultó el destino.

Observación	Fuente típica	Qué demuestra	Qué no puede demostrar	Quién puede cambiarla
Registro del prefijo	RDAP o WHOIS del RIR	Qué organización recibió el bloque de direcciones	Si un cliente usa esa dirección desde una casa o una oficina	El registro, mediante transferencia o reasignación
Anuncio de ruta	Datos de encaminamiento entre redes	Qué red anuncia actualmente el prefijo	La ubicación física o la tecnología de acceso	La red que lo anuncia
Delegación inversa	Registro PTR	Qué nombre publicó el titular para esa dirección	Que el nombre sea actual o veraz	El operador de la zona inversa
Ubicación autopublicada	Archivo geofeed	La localidad que declara el publicador para el prefijo	Que la declaración sea exacta para una dirección	El publicador
Tiempos de ruta	Mediciones de solicitudes	Cómo se comportó la ruta durante la muestra	Qué tipo de red de acceso la produjo	Nadie, para una sola muestra
Handshake TLS	ClientHello e intercambio de certificados	Qué pila de cliente negoció la conexión	Qué navegador o dispositivo originó la solicitud	Quien termina TLS

La consecuencia práctica es que la etiqueta residencial es una afirmación sobre registros, no una propiedad del cable. Una dirección que un destino clasifica como residencial hoy puede reclasificarse tras una transferencia de asignación, y una dirección que supera todas las comprobaciones estáticas puede fallar una regla de comportamiento aplicada a la sesión.

Registro, encaminamiento y delegación inversa son registros separados

Los datos de registro son los más citados y los más malinterpretados. Un registro describe una asignación a una organización. Puede indicar que un bloque pertenece a un proveedor de servicios de internet y en qué país se asignó. No dice que un cliente concreto tenga un tipo de conexión concreto en una dirección concreta; un registro RDAP de 203.0.113.24 es un objeto de asignación. Leer un registro de ISP de consumo y concluir «salida residencial» omite el paso en el que un proveedor asigna esa dirección a un abonado, y los proveedores reasignan direcciones constantemente.

Los datos de encaminamiento responden a otra pregunta: una ruta vista en 203.0.113.24 no identifica al titular del prefijo. Un prefijo anunciado es alcanzable a través de una red, y la red que lo anuncia no es necesariamente la organización titular del registro. Un proveedor puede anunciar espacio de clientes desde un sistema autónomo distinto, y una empresa de hosting puede originar un prefijo que un registro sigue asociando a un ISP regional. Tratar a la red que anuncia como titular, o al titular como anunciante, produce afirmaciones seguras que los datos subyacentes no sostienen.

El DNS inverso, consultado con un PTR sobre 203.0.113.24, es el más débil de los tres como señal de identidad, porque es un puntero delegado que cualquiera que controle la zona inversa puede publicar. Un puntero con aspecto de nombre de consumidor puede estar obsoleto, reasignado o simplemente elegido por un operador al que le gusta esa convención. Un puntero ausente es igual de poco informativo: muchas redes legítimas nunca publican uno. Si un destino usa nombres inversos, los usa como una entrada en una decisión ponderada, no como prueba.

Los archivos de ubicación merecen la misma cautela. RFC 8805 define un formato para geolocalización IP autopublicada, y la especificación es explícita: las inexactitudes ocurren en muchos niveles. Indica a los consumidores que verifiquen la localidad publicada en la medida de lo posible y que decidan sus propios umbrales de discrepancia. Un geofeed respalda una afirmación de ubicación hecha por su publicador; no certifica que una dirección dada sea una conexión doméstica ni obliga a un destino a aceptar esa afirmación.

El registro y el encaminamiento discrepan con la suficiente frecuencia como para que un clasificador de un solo campo etiquete mal tráfico real. La pregunta útil no es «¿parece residencial esta dirección?», sino «¿qué registros coinciden, cuáles discrepan y qué significa cada discrepancia para la decisión que voy a tomar?». Para la mecánica de ruta que hay detrás de una solicitud del navegador, configuración de proxy y alineación geográfica cubre cómo se elige un extremo y cómo se derivan los valores visibles en página a partir de la dirección pública observada. Ese artículo configura la ruta; este decide qué pueden sostener los registros de esa ruta.

Ejecutar un clasificador sobre registros aportados

El ejemplo siguiente clasifica cinco registros sintéticos. No realiza solicitudes de red, no lee ningún sitio real y no afirma que ninguna dirección real tenga estas propiedades. Su propósito es mostrar la forma de una decisión defendible: cada entrada se convierte en su propio campo, las discrepancias se cuentan y ningún campo se colapsa en un veredicto residencial.

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}`
  );
}

Pégalo en un archivo .mjs local y ejecútalo con node. La salida son cinco líneas, una por registro, con los mismos nombres de campo que usa la tabla. Léelas como una pequeña comparación, no como un veredicto.

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

Dos de los cinco registros discrepan, y ambas discrepancias son informativas. El tercer registro tiene un registro de ISP de consumo pero no se anuncia en la muestra, que es el patrón esperable cuando un prefijo se reasigna o cuando la observación se tomó desde una vista de encaminamiento incompleta. El cuarto tiene un puntero que ya no pertenece al titular, que es el aspecto de una dirección obsoleta o reemitida. Ninguno de los dos casos produce «residencial» o «centro de datos» como respuesta, porque las entradas no sostienen esa respuesta.

El quinto registro es el que sorprende a los equipos. Un registro de consumo sin puntero inverso suma cero discrepancias con estas reglas y, aun así, casi no dice nada a un destino. Un destino que pondera mucho los nombres inversos lo trataría de forma distinta a uno que los ignora. Esa diferencia es una elección de política del destino, no un hecho sobre la dirección.

Este clasificador es deliberadamente pequeño. No resuelve prefijos reales, no valida los registros del registro regional, no pondera discrepancias en una puntuación ni modela la decisión de un proveedor. Cualquier corte que se le añada es política propia con su propia tasa de error, y ese corte pertenece junto a la decisión que produjo.

Los tiempos y el handshake son pruebas más débiles de lo que parecen

Los tiempos parecen una medición directa, y por eso se confían demasiado. Una solicitud desde una conexión de consumo suele mostrar una latencia más alta y más variable que una desde un centro de datos, así que los equipos leen una distribución estrecha como señal de hosting. La inferencia funciona en ambos sentidos. Un enlace doméstico congestionado puede parecer lento y errático, y un centro de datos en la misma ciudad puede parecer rápido y estable; registra p50 y p95 con el tamaño de muestra en lugar de un solo número. Una red móvil añade su propia variabilidad, y un proxy añade un salto cuyo comportamiento pertenece al proveedor y no al cliente.

Eso hace que una sola muestra sea inútil como clasificador. Si se usan tiempos, pertenecen a una distribución con el tamaño de muestra, la ventana temporal y la ruta registrados, y aun así solo sostienen «esta ruta se comportó así durante la ventana». Un destino que compara una sesión con un dispositivo declarado tiene una pregunta más fuerte: ¿el comportamiento típico del dispositivo declarado coincide con lo que produjo la sesión? Un perfil de escritorio que declara fibra mientras cada solicitud llega con la forma de un relé lejano es una discrepancia que merece explicación, y la explicación puede ser el relé y no la red de acceso.

El handshake es la observación que los equipos suelen equivocar en la dirección opuesta. JA3 y JA4 son valores derivados de un handshake TLS, y la documentación del proveedor aclara que se calculan durante ese handshake y pueden faltar cuando no se calcula ninguno para una solicitud. Lo que describe el valor es la pila de cliente que negoció la conexión. Que esa pila sea el navegador del equipo del lector depende por completo de dónde termina TLS.

Cuando un proxy reenvía con CONNECT, la especificación describe al proxy como reenvío ciego de datos en ambos sentidos una vez abierto el túnel. En ese modo, el handshake TLS del destino es con el navegador y el par TCP del destino es el proxy. Cuando un proxy termina TLS y lo reorigina en el puerto 443, el handshake del destino pertenece al proxy, y el handshake del navegador es una conexión separada que el destino nunca ve; el JA3 observado pertenece al terminador. Ambas disposiciones son habituales y producen conclusiones opuestas a partir de la misma observación «cambió JA3». El artículo sobre TLS y HTTP/2 explica cómo se ensamblan los valores y por qué un hash sin ordenar mide un orden que el cliente no fija; la cuestión decisiva es más estrecha: identifica al terminador antes de atribuir un handshake a un navegador.

También hay una trampa de orden. Un destino puede comparar el handshake con una versión de navegador declarada, luego la versión declarada con User-Agent y Client Hints, y luego el registro de la dirección con el país declarado. Esas comparaciones son reglas separadas con tasas de error separadas. Una sesión que falla una no ha fallado necesariamente las otras, y un informe que las fusiona en «discrepancia de huella» no puede decirle a un equipo qué regla se activó.

Los datos de reputación se sitúan junto a estas observaciones, no por encima. Un destino puede mantener listas que marcan rangos de direcciones o sistemas autónomos y aplicarlas antes de cargar cualquier página. Es una entrada de política sobre comportamiento previo atribuido a un rango, no una medición de la sesión actual, y cambia cuando cambia la lista, no cuando cambia el cliente. Un equipo que responde a un bloqueo por reputación ajustando un perfil de navegador trata una decisión de lista como un problema del navegador.

Qué cambia un perfil de navegador y qué no

Un perfil declarado controla valores que el navegador genera y expone, incluido el valor devuelto por navigator.userAgentData. User-Agent y Client Hints, zona horaria e idioma, métricas de pantalla, salida de canvas y WebGL, enumeración de fuentes, características del procesamiento de audio y la coherencia entre esas superficies están dentro de ese límite. Un perfil puede mantenerlas alineadas entre sí y con un dispositivo declarado, que es lo que hace coherente una sesión.

La dirección de salida queda fuera de ese límite; --proxy-server elige esa dirección y el perfil no la cambia. Un perfil no puede cambiar qué sistema autónomo anuncia la dirección, no puede cambiar el registro del prefijo, no puede publicar un puntero inverso y no puede hacer que una dirección de hosting pertenezca a un ISP de consumo. Tampoco puede cambiar la ruta que toman los paquetes ni las listas de reputación que consulta un destino. Cuando el problema es uno de esos, el trabajo de perfil produce una sesión internamente coherente y aun así clasificada como se clasifica la dirección.

Esa distinción es lo que hace tratable la pregunta residencial. Pregunta a qué capa pertenece la observación que falló. Si el destino rechazó la sesión porque el dispositivo declarado y los valores observados del navegador no coincidían, la capa de perfil es la relevante. Si la rechazó porque la dirección está en un rango de hosting, o porque un puntero inverso nombra a un proveedor de nube, ningún cambio de perfil mueve ese resultado. Si el destino rechazó la solicitud antes de renderizar, el fallo puede no ser de identidad.

Para equipos que ejecutan varios contextos a través de un proveedor, consistencia de proxy IPv4 e IPv6 cubre los fallos de ruta que parecen problemas de identidad: una familia que retrocede en silencio, un resolutor que responde desde otra ruta, una ruta que cambia a mitad de sesión. Esos fallos producen observaciones incoherentes del mismo navegador y se diagnostican en la capa de ruta, no ajustando un perfil.

La misma disciplina se aplica a la cuenta. El historial de un destino con una cuenta, sus sesiones previas y los datos que ya posee quedan fuera de toda capa de navegador y red tratada aquí. Una salida limpia no reinicia el historial de la cuenta, y una dirección residencial no hace que una cuenta establecida se comporte como una nueva. Trata el estado de la cuenta como una entrada propia con su propio propietario.

Conclusión práctica

Registra las entradas de clasificación de salida junto con el trabajo: la dirección, el registro de asignación y su fecha, la red que anuncia, la delegación inversa si existe, la ventana de muestra para los tiempos y el terminador TLS. Después nombra el componente que posee cada una y la decisión que sostiene. Ese registro responde la pregunta que se supone que responde una compra de proxy residencial, y muestra cuándo la respuesta depende de un registro y no del navegador.

Preguntas frecuentes

¿Un ASN residencial garantiza que un sitio trate la sesión como residencial?

No. Un ASN identifica la red asignada a una organización. Un destino puede ponderar registro, encaminamiento, delegación inversa, tiempos, listas de reputación y comportamiento de sesión en cualquier combinación, y puede cambiar esa ponderación sin avisar. Un registro residencial elimina una señal posible; no controla la decisión.

¿Por qué un proxy muestra un JA3 o JA4 distinto al del navegador que está detrás?

Porque el valor describe la pila que completó el handshake TLS con el destino. Si el proxy termina TLS y abre una conexión nueva hacia arriba, el destino ve el handshake del proxy. Si el proxy reenvía un túnel CONNECT, el destino ve el del navegador. Captura dónde termina el handshake antes de sacar una conclusión sobre el cliente.

¿Puede un geofeed o un registro WHOIS probar que una dirección es una conexión doméstica?

Ninguno de los dos registros está diseñado para eso. Un geofeed publica la ubicación que declara su operador, y el estándar indica a los consumidores que verifiquen la exactitud. Un registro describe una asignación a una organización. Ambos pueden ser exactos y aun así no decir nada sobre cómo se usa una línea de abonado concreta en un momento concreto.

¿Una conexión lenta y con jitter es prueba de una salida residencial?

Es prueba sobre la ruta durante la muestra. Congestión, distancia, un enlace móvil, un salto de relé y un enlace limitado producen variación. Sin una distribución, una ventana de muestra y la ruta, los tiempos sostienen una descripción de la ruta y no una clasificación de la red de acceso.

¿Qué debe hacer un equipo cuando un destino bloquea una sesión con una dirección residencial?

Empieza por la observación que usó realmente el destino, si está disponible, y mapéala a la capa que la posee. Un rechazo previo al renderizado puede ser una regla de reputación o de acceso; un desafío en la página puede ser de comportamiento; un informe de discrepancia puede nombrar los campos comparados. Cambiar el perfil solo aborda la capa del navegador, así que confirma la capa que falla antes de gastar en más ancho de banda de salida.

Fuentes

• RFC 8805: formato para geolocalización IP autopublicada
• RFC 9110: semántica HTTP, CONNECT y túneles
• RFC 1035: nombres de dominio, registros PTR
• ARIN: Protocolo de acceso a datos de registro
• Cloudflare: huellas JA3 y JA4
• Cloudflare: reglas de acceso IP por dirección, ASN o país
• Configuración de proxy de BotBrowser
• Consistencia de automatización de BotBrowser