Zona horaria del navegador, idioma y geolocalización: tres campos con los que los sitios detectan un proxy

Introducción: por qué tres campos modestos deciden el destino de una cuenta

Imaginen un control migratorio. Usted presenta un documento de un país, responde en el idioma de otro y el reloj en su muñeca marca la hora de un tercero. El agente fronterizo no necesita pericias complejas. Simplemente hará preguntas adicionales. Algo así funciona el antifraude de las plataformas modernas. No necesita descifrar huellas de red complicadas ni calcular hashes de subsistemas gráficos. Basta con comparar tres campos simples: la zona horaria del navegador, el idioma y la geolocalización, y luego contrastarlos con lo que revela la dirección IP.

Según nuestras observaciones en proyectos de multicuentas, entre las causas de pérdida de perfiles durante las primeras 24 horas, el desajuste del entorno ocupa con seguridad el primer lugar. Supera tanto a la calidad del propio proxy como a las huellas "pesadas". La razón es simple. Un buen proxy móvil les da una IP limpia de un operador de telefonía real, pero todo el entorno alrededor de esa IP lo configuran ustedes mismos. Y es precisamente aquí donde surge con más frecuencia la contradicción que la plataforma detecta en milisegundos.

En esta guía aprenderán:

• qué API y encabezados exactos usan los sitios para leer la zona horaria, el idioma y la geolocalización;
• por qué el desfase respecto a UTC y el nombre de la zona son entidades distintas, y cómo detectan la sustitución basándose en esa diferencia;
• en qué se diferencia Accept-Language de navigator.languages y por qué no pueden divergir;
• cómo comportarse ante la solicitud de geolocalización: denegar, permitir o coordinar las coordenadas;
• cómo construir un marco integral de coherencia del entorno adaptado a una IP móvil y un protocolo de autocomprobación;
• qué errores cometen incluso los equipos experimentados y qué hacer al respecto.

Deliberadamente no abordamos canvas, WebGL, huellas de audio ni firmas de red a nivel de transporte. A esos temas están dedicados materiales separados del blog. Aquí el enfoque es uno: la coherencia del contexto. Tres campos que se verifican primero, le cuestan menos al antifraude y generan la señal más alta por unidad de esfuerzo. Veamos cómo no regalarle esa señal a la plataforma.

Fundamentos: qué es la coherencia del entorno y por qué la IP siempre tiene razón

El concepto de coherencia del contexto

Por coherencia del entorno se entiende la situación en la que todas las señales sobre la ubicación y la hora del usuario que el navegador entrega al sitio cuentan una sola historia. El punto de referencia es la dirección IP. El usuario no puede reescribirla arbitrariamente, por eso el antifraude considera la IP como el testigo más honesto. Todos los demás campos se comparan precisamente con ella, y no entre sí.

De ahí se deriva la primera regla que conviene memorizar para siempre: no es la IP la que se adapta al navegador, sino el navegador a la IP. Si conectaron un proxy móvil cuya geografía las bases determinan como Novosibirsk, todo el perfil debe "respirar" Novosibirsk. La zona horaria del navegador, el idioma, las coordenadas, el formato de fechas y números: todo eso son consecuencias, y la IP es la causa.

Tres campos en primer plano

Zona horaria. El navegador sabe en qué zona vive el sistema operativo y se lo comunica gustosamente a cualquier script. Y lo hace de varias maneras: como nombre de zona en formato IANA (por ejemplo, Europe/Moscow o Asia/Yekaterinburg), como desfase numérico en minutos respecto a UTC y como etiqueta localizada dentro de la representación de cadena de una fecha. El antifraude compara estas representaciones entre sí y con la zona que se espera para la IP.

Idioma. Este es el campo más multicapa. El idioma se transmite incluso antes de ejecutar cualquier script, en el encabezado HTTP Accept-Language de cada solicitud. Luego se duplica en JavaScript mediante navigator.language y navigator.languages. Después el idioma se filtra en la configuración regional de formato: cómo se ven las fechas, los separadores de miles, la coma o el punto decimal, los nombres de los meses. Finalmente, influye en la distribución del teclado que el navegador ve a través de los eventos de entrada.

Geolocalización. Aquí hay dos capas. La pasiva: lo que las bases de geolocalización IP piensan de ustedes. La activa: la Geolocation API, que devuelve coordenadas solo con permiso del usuario. Es un error creer que, como no pulsaron "Permitir", el campo queda vacío. El propio estado del permiso, el comportamiento ante la solicitud y los indicios indirectos de ubicación también se leen.

Por qué se verifican precisamente estos tres campos

La respuesta está en la economía del antifraude. Estas señales:

• se leen gratis, sin cálculos pesados y sin permisos especiales (salvo las coordenadas exactas);
• son deterministas: en un usuario real casi no cambian de sesión en sesión;
• tienen una conexión lógica rígida con la IP, que se puede verificar con una regla simple, sin aprendizaje automático;
• se resisten mal a una sustitución "aleatoria": si se cambian de forma caótica, las contradicciones solo se multiplican.

En otras palabras, este es el primer filtro. No banea por sí solo, pero eleva la puntuación interna de riesgo. Y después ya se activan verificaciones más costosas, y el perfil con una mala puntuación inicial recibe muchas menos oportunidades de cometer errores.

Cómo se ve un usuario normal

Tomemos a un abonado real de Kazán que entra a un sitio desde el teléfono mediante internet móvil. Su IP pertenece a un operador de telefonía y la base de geolocalización asignará la dirección a la República de Tartaristán o, lo que no es infrecuente, a Moscú, donde está registrado el pool de direcciones. La zona horaria del navegador es Europe/Moscow, el desfase es menos 180 minutos. El idioma es ru-RU, seguido posiblemente de en-US en segunda posición. La geolocalización: o no se solicitó, o se permitió y apunta a Kazán con precisión de decenas de metros. El formato de fecha es día, mes, año separados por punto. Todo es lógico, todo encaja.

Ahora la misma imagen, pero con el error típico de un operador de multicuentas: la IP es la misma, pero el navegador muestra America/New_York, el idioma es en-US y las coordenadas son el centro de Berlín de una plantilla de perfil antigua. Cada campo por separado parece inocente. Juntos forman un usuario que no existe.

Una particularidad de las IP móviles que se suele olvidar

Aquí hay un matiz importante precisamente para la audiencia de proxies móviles. Las bases de geolocalización determinan no la posición física del abonado, sino la región a la que el operador vinculó el rango de direcciones. Por eso un usuario real de Tiumén puede recibir una IP que las bases asignan a Ekaterimburgo o incluso a Moscú. ¿Qué hacer al respecto? Orientarse por lo que ven las bases, no por dónde está físicamente el módem. La plataforma compara su perfil no con la realidad, sino con los registros de sus directorios. Por eso el primer paso de cualquier configuración es averiguar cómo clasifican exactamente su IP varias bases populares y, a partir de eso, construir el entorno.

Inmersión profunda: cómo leen realmente los sitios los tres campos

Zona horaria del navegador: tres fuentes de una misma verdad

La mayoría de los usuarios de herramientas antidetect conciben la zona horaria como un solo número. En la práctica, el navegador entrega al menos tres representaciones independientes, y el antifraude verifica su coherencia entre sí.

La primera es el nombre de la zona según el estándar IANA, que devuelve el método Intl.DateTimeFormat().resolvedOptions().timeZone. Es una cadena del tipo Europe/Moscow, Asia/Novosibirsk, Europe/Berlin. Contiene más información que el desfase, porque define sin ambigüedad las reglas de transición al horario de verano y el historial de cambios de la zona.

La segunda es el desfase numérico de new Date().getTimezoneOffset(). Devuelve la diferencia entre UTC y la hora local en minutos, y con signo inverso: para Moscú es menos 180. Un punto clave: el desfase se calcula para una fecha concreta. Para una zona con horario de verano, los resultados de enero y julio son distintos.

La tercera es la representación de cadena de la fecha mediante Date.prototype.toString(), donde entre paréntesis se indica el nombre localizado de la zona, por ejemplo "Москва, стандартное время" o "Central European Summer Time". Presten atención: la etiqueta se renderiza en el idioma de la interfaz del navegador. Este es uno de los pocos puntos donde la zona horaria del navegador y el idioma se cruzan directamente, y en ese cruce se ven bien las sustituciones artesanales.

¿Cómo lo usan en su contra? La técnica clásica consiste en calcular el desfase para el 1 de enero y el 1 de julio. Si la zona declarada es Europe/Berlin, los desfases deben diferir en 60 minutos. Si ambos valores son iguales, significa que alguien sustituyó la zona sin enseñarle al navegador las reglas del horario de verano. La situación inversa también es reveladora: la zona Europe/Moscow, donde no hay horario de verano desde 2014, de repente muestra desfases distintos. Otra técnica consiste en comparar la etiqueta localizada en toString con el idioma navigator.language. Una etiqueta en ruso con un idioma declarado en inglés es un marcador.

Además de la propia zona, los sitios se interesan por el desincronización del reloj del sistema. El script envía al servidor el valor Date.now() y lo compara con la hora de recepción de la solicitud. Una discrepancia de unos pocos segundos es normal. Una discrepancia de minutos, y más aún de horas, significa que la hora del sistema se configuró a mano y sin cuidado. Por sí solo no es una condena, pero sumado a otras señales el peso crece.

En 2026 se añade a este conjunto la Temporal API, que desplaza paulatinamente al antiguo objeto Date. Vincula el tiempo con la zona IANA de forma aún más estricta y hace prácticamente inútil la sustitución mediante un simple desfase. La tendencia es evidente: los navegadores avanzan hacia que la zona sea una entidad con nombre, no un número.

Idioma: del encabezado al formato de los números

El idioma es el único de los tres campos que el servidor ve antes de cargar la página. El encabezado Accept-Language se envía con la primera solicitud y se ve aproximadamente así: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7. Los valores q son pesos de preferencia y disminuyen del primer elemento al último. El formato de la cadena depende del navegador y del sistema: Chrome lo construye de una manera, Safari de otra, y el antifraude sabe distinguir los patrones.

Luego el idioma se duplica del lado del cliente. navigator.language devuelve el idioma principal, navigator.languages un array ordenado. En un navegador que funciona correctamente, este array y el encabezado Accept-Language coinciden en composición y orden. La divergencia entre ellos es uno de los indicios más frecuentes y más evidentes de que el entorno se armó con piezas distintas: el encabezado se sustituyó a nivel del cliente de proxy y el objeto JavaScript quedó con la configuración del sistema, o viceversa.

Después el idioma penetra más profundo. El método Intl.DateTimeFormat().resolvedOptions().locale devuelve la configuración regional de formato. La llamada a toLocaleDateString() sin parámetros dibuja la fecha en el formato de esa configuración regional: 05.03.2026 para la rusa, 3/5/2026 para la estadounidense. Intl.NumberFormat decide qué separa los miles: un espacio, una coma o un punto. Todo esto también se compara con el idioma declarado y, con especial atención, con la zona horaria. Un usuario con zona Asia/Tokyo y configuración regional de formato ru-RU es posible, pero raro, y su puntuación de riesgo será superior a la media.

También hay indicios indirectos. Los eventos de teclado entregan el código físico de la tecla y el carácter que produjo. Si con un idioma declarado en-US el usuario introduce cirílico sin cambiar la distribución, y la distribución del sistema se ve como la única, eso también es una contradicción. No vamos a profundizar en el análisis conductual, pero es importante entender que el idioma no es una cadena, sino toda una capa del comportamiento del navegador.

Geolocalización: capa pasiva y capa activa

La capa pasiva son las bases de geolocalización IP. Hay varias grandes y no siempre coinciden entre sí. Para los rangos móviles las discrepancias son especialmente notables: un directorio indicará la ciudad de un centro regional, otro la capital, un tercero simplemente el país sin ciudad. Por eso una comprobación en una sola base no garantiza nada. Las plataformas grandes usan varias fuentes y sus propios datos acumulados, donde la dirección se asocia a las coordenadas reales de millones de usuarios que en algún momento permitieron el acceso a la ubicación.

La capa activa es la Geolocation API. El método navigator.geolocation.getCurrentPosition devuelve latitud, longitud, precisión en metros y, si están disponibles, altitud, velocidad y dirección, además de una marca temporal. En un smartphone la fuente es la navegación satelital y las antenas de telefonía, con una precisión de 5 a 50 metros. En un ordenador de escritorio las coordenadas se calculan por las redes inalámbricas del entorno y por la IP, con una precisión de cientos de metros a kilómetros. Esta diferencia es crítica: si el perfil emula un navegador móvil y la precisión devuelta es de 5000 metros con altitud nula, la imagen resulta antinatural.

Una historia aparte es el estado del permiso. Mediante navigator.permissions.query el sitio puede averiguar si el acceso a la geolocalización está permitido, denegado o aún no se ha solicitado. Esto se hace en silencio, sin ventana emergente. Los usuarios reales se distribuyen por los tres estados, pero en un visitante nuevo típico el permiso está en estado "aún no solicitado". Si en cien cuentas recientes de una misma red la geolocalización está denegada de forma idéntica e instantánea, es un indicio de configuración automatizada.

Comprobaciones cruzadas: dónde confluyen los tres campos

Lo más interesante empieza cuando el antifraude deja de mirar los campos por separado. Algunas combinaciones que se encuentran en la práctica de los sistemas antifraude:

• Coordenadas y zona. A partir de la latitud y la longitud se calcula sin ambigüedad la zona horaria. Coordenadas de Krasnodar con zona Asia/Vladivostok: una contradicción que no necesita explicaciones.
• País de la IP e idioma. Cada país tiene una distribución esperada de idiomas. Una IP alemana con idioma ru-RU no está prohibida, pero se sale de la estadística, y eso añade puntos de riesgo.
• Zona y actividad. Una cuenta con zona Europe/Moscow que está activa de forma estable entre las tres y las seis de la mañana hora local parece una cuenta gestionada desde otra zona.
• Zona y fecha de registro. La plataforma recuerda en qué zona se creó la cuenta. Cambiar de zona es admisible en las mudanzas, pero los saltos frecuentes entre zonas incompatibles son una señal.
• Precisión de las coordenadas y tipo de dispositivo. Un User-Agent móvil con precisión de kilómetros o un navegador de escritorio con precisión de tres metros: ambas variantes son antinaturales.

Entender estas combinaciones es la mitad del éxito. La otra mitad es la disciplina de configuración, a la que pasamos.

Método 1. Zona horaria del navegador: configuración bajo una IP móvil sin contradicciones

Teoría: zona frente a desfase

El principal error conceptual es pensar en la zona horaria como un número. Lo correcto es pensarla como una zona IANA con nombre. El número (el desfase) es una derivada de la zona y la fecha. Cuando configuran en los ajustes del perfil precisamente el nombre de la zona, el navegador calcula por sí mismo el desfase correcto para cualquier fecha, procesa correctamente el horario de verano y dibuja la etiqueta localizada. Cuando configuran solo el desfase, asumen la obligación de mantener manualmente todo lo demás, y casi con seguridad se equivocarán en algún punto.

Para Rusia esto es especialmente cómodo: no hay horario de verano y en cada zona el desfase es estable todo el año. Pero si trabajan con proxies de países de Europa o Norteamérica, las reglas de transición al horario de verano se convierten en una fuente de fallos estacionales. Los equipos que configuraron perfiles en invierno mediante un desfase fijo, en primavera reciben de repente una ola de desajustes sin entender la causa.

Configuración paso a paso

1. Determinen la zona de la IP, no la del módem físico. Verifiquen la dirección del proxy móvil en al menos dos o tres bases de geolocalización. Registren la región y la ciudad que indican. Si las bases discrepan, oriéntense por la que coincida con más frecuencia con la opinión de sus plataformas objetivo (empíricamente se averigua en las primeras sesiones).
2. Asocien la región con la zona IANA. Para las regiones rusas rigen once zonas: Europe/Kaliningrad (UTC+2), Europe/Moscow (UTC+3), Europe/Samara (UTC+4), Asia/Yekaterinburg (UTC+5), Asia/Omsk (UTC+6), Asia/Krasnoyarsk (UTC+7), Asia/Irkutsk (UTC+8), Asia/Yakutsk (UTC+9), Asia/Vladivostok (UTC+10), Asia/Magadan (UTC+11), Asia/Kamchatka (UTC+12). Presten atención: algunas regiones tienen sus propias zonas IANA con el mismo desfase, por ejemplo Europe/Volgograd o Asia/Tomsk. Usar el nombre correcto para la región es preferible a usar el análogo "grande" más cercano.
3. Definan la zona por su nombre, no por el desfase. En los ajustes del perfil elijan la opción donde se indique una cadena del tipo Asia/Novosibirsk. Si la herramienta solo ofrece un desfase numérico, es motivo para dudar de su madurez.
4. Sincronicen el reloj del sistema. Asegúrense de que el sistema operativo recibe la hora mediante un protocolo de sincronización de red. La discrepancia con la hora real debe mantenerse dentro de segundos. Esto también aplica a las máquinas virtuales: sus relojes no rara vez se "desplazan" tras una suspensión.
5. Verifiquen las tres representaciones. Abran la consola y comparen el resultado de Intl.DateTimeFormat().resolvedOptions().timeZone, el valor de getTimezoneOffset() y la etiqueta en new Date().toString(). Las tres deben describir una misma zona, y la etiqueta debe estar en el idioma del perfil.
6. Verifiquen el desfase de invierno y de verano. Calculen getTimezoneOffset para las fechas del 15 de enero y el 15 de julio del año en curso. Para las zonas rusas los valores son iguales. Para las zonas con horario de verano la diferencia es de 60 minutos. Cualquier otro comportamiento significa una emulación rota.
7. Vinculen la zona a la rotación. Si su proxy móvil, al cambiar de IP, puede mudarse a otra región, la zona debe cambiar con él. Es mejor configurar el proxy para que la rotación ocurra dentro de una misma región y fijarlo en la ficha del perfil.

Ejemplo de la práctica

Un equipo gestionaba cuentas en una plataforma de anuncios con proxies móviles de la región de los Urales. Las bases identificaban las direcciones como Ekaterimburgo. En la plantilla del perfil había quedado la zona Europe/Moscow de un proyecto anterior. Los primeros días no pasó nada, pero al quinto día todas las cuentas cayeron bajo verificación ampliada. Al analizar, resultó que en la plataforma funcionaba exactamente la combinación "zona contra coordenadas de la IP" que describimos arriba: la diferencia de dos horas entre la zona esperada y la real superó el umbral interno. Tras cambiar la zona a Asia/Yekaterinburg y recrear los perfiles, las verificaciones repetidas cesaron.

Lista de verificación de la zona horaria

• La zona está definida por su nombre IANA, correspondiente a la región de la IP según las bases.
• La hora del sistema está sincronizada, con una discrepancia respecto al servidor inferior a 5 segundos.
• Las tres representaciones de la zona son coherentes entre sí.
• Los desfases de invierno y de verano se comportan correctamente para esa zona.
• La etiqueta localizada de la zona se muestra en el idioma del perfil.
• La rotación de IP no saca la dirección fuera de la zona, o la zona se actualiza junto con ella.
• En la ficha del perfil está registrado qué zona es y por qué.

Método 2. Idioma: coherencia de encabezados, objetos y formatos

Teoría: el idioma como un pastel multicapa

Ya vimos que el idioma vive al menos en cuatro niveles: el encabezado HTTP, los objetos JavaScript, la configuración regional de formato y los indicios del sistema, como la distribución del teclado. Cada nivel lo forma un componente distinto. El encabezado lo arma la pila de red del navegador a partir de su configuración de idiomas. Los objetos navigator se toman de ahí mismo, pero la sustitución en un nivel no siempre penetra automáticamente en el otro. La configuración regional de formato a menudo se hereda del sistema operativo, no del navegador. De ahí los desajustes.

Una segunda idea importante: el idioma debe corresponder no solo al país de la IP, sino también a una biografía plausible del usuario. Los perfiles totalmente monolingües se encuentran menos de lo que parece. En una persona real, la lista de idiomas suele tener dos o tres puntos: el idioma nativo con código regional, el mismo idioma sin región y el inglés como reserva. Precisamente esa lista es la que forma un navegador típico por defecto.

Configuración paso a paso

1. Elijan la configuración regional principal según el país de la IP. Para una IP móvil rusa es ru-RU. Para una kazaja, ru-RU o kk-KZ según la leyenda del perfil, y en este caso el segundo idioma es casi obligatorio. Para países con varios idiomas oficiales, estudien cuál domina en la región de la IP.
2. Construyan la lista de idiomas. Un array realista para un perfil rusoparlante: ru-RU, ru, en-US, en. El orden importa. No empiecen por el inglés si la configuración regional principal es rusa.
3. Verifiquen el encabezado Accept-Language. Debe reproducir la misma lista con pesos q decrecientes. Asegúrense de que el formato corresponde al tipo de navegador que emula el perfil.
4. Comparen navigator.language y navigator.languages. El primer valor es igual al primer elemento del array. El array coincide con el encabezado en composición y orden.
5. Verifiquen la configuración regional de formato. Llamen a Intl.DateTimeFormat().resolvedOptions().locale, luego a new Date().toLocaleDateString() y a (1234567.89).toLocaleString(). El formato debe corresponder al idioma principal: punto como separador de fecha y espacio como separador de miles para ru-RU.
6. Coordinen el idioma de la interfaz del sistema. Si el perfil es rusoparlante y la configuración regional del sistema de la máquina virtual es inglesa, parte de las cadenas (incluida la etiqueta de la zona horaria) aparecerá en inglés. Pongan orden en el sistema o asegúrense de que la herramienta cubre correctamente esos valores.
7. Piensen en la distribución del teclado. Si el operador introduce texto en ruso, el sistema debe tener distribución rusa y el perfil, idioma ruso. Un perfil en inglés con entrada cirílica activa resulta sospechoso.

Ejemplo de la práctica

Un equipo de arbitraje trabajaba con una plataforma social usando proxies móviles rusos, pero las plantillas de perfil se habían heredado de un proyecto para audiencia angloparlante. El encabezado Accept-Language se cambiaba a ru-RU por obra de la herramienta antidetect, pero el objeto navigator.languages seguía siendo en-US, en. Las sesiones vivían en promedio menos de 24 horas. Tras alinear el array de idiomas y la configuración regional de formato con el encabezado, la vida media del perfil creció varias veces, aunque los proxies y los demás ajustes no cambiaron. El costo de la corrección fue una tarde de trabajo con la plantilla.

Lista de verificación del idioma

• La configuración regional principal corresponde al país y la región de la IP.
• La lista de idiomas contiene de dos a cuatro elementos en un orden plausible.
• Accept-Language y navigator.languages coinciden en composición y orden.
• navigator.language es igual al primer elemento del array.
• La configuración regional de formato, la fecha y los números se renderizan en el formato del idioma principal.
• La configuración regional del sistema no se filtra en cadenas en inglés cuando el perfil es ruso.
• La distribución del teclado y la entrada real concuerdan con el idioma declarado.

Método 3. Geolocalización: tres estrategias y reglas de coordenadas

Teoría: el permiso importa más que las coordenadas

Muchos se concentran en qué coordenadas entregar al sitio y pasan por alto que la mayoría de las plataformas ni siquiera solicitan la geolocalización precisa a un usuario común. Importa mucho más cómo se comporta el perfil ante la propia solicitud y en qué estado se encuentra el permiso. De ahí tres estrategias.

Estrategia "no solicitado". El permiso permanece en su estado inicial, no se entregan coordenadas. Este es el estado más natural para un usuario nuevo en la mayoría de los sitios. Es adecuada para escenarios en los que la plataforma no exige la ubicación precisa: cuentas publicitarias, la mayoría de las plataformas sociales, marketplaces con selección manual de región.

Estrategia "permitido y coordinado". El perfil entrega coordenadas que se encuentran en una proximidad razonable a la ciudad de la IP, con una precisión realista y una pequeña deriva entre sesiones. Es adecuada para servicios donde la ubicación es parte de la funcionalidad: mapas, reparto, anuncios vinculados al barrio, algunas aplicaciones móviles en envoltorio web.

Estrategia "denegado". La más arriesgada cuando se aplica de forma masiva. Una denegación individual es normal, pero una denegación idéntica e instantánea en cientos de perfiles de una misma red forma un patrón reconocible. Úsenla solo donde sea una decisión consciente para una leyenda concreta.

Configuración paso a paso para la estrategia "permitido y coordinado"

1. Averigüen qué ciudad asignan las bases a la IP. Igual que con la zona horaria, oriéntense por los directorios, no por la posición física del módem.
2. No tomen las coordenadas de la propia base. Los directorios entregan el centroide de la ciudad: un solo punto para todos. Miles de usuarios de herramientas de sustitución usan ese mismo punto. Elijan un barrio residencial o de negocios real a una distancia de entre uno y quince kilómetros del centro.
3. Definan una precisión realista. Para un perfil móvil, de 10 a 80 metros; para uno de escritorio, de 500 a 5000 metros. Una precisión de 1 metro o de exactamente 100 metros parece sintética.
4. Añadan deriva. Entre sesiones, las coordenadas de una persona real cambian: casa, trabajo, camino. Un desplazamiento de varios cientos de metros o la alternancia entre dos o tres puntos "hogareños" parece más natural que una coordenada inmóvil durante meses.
5. Coordinen los campos adicionales. En un perfil de escritorio, la altitud, la velocidad y la dirección deben estar ausentes. En uno móvil la altitud puede estar presente, pero debe ser plausible para el terreno.
6. Asegúrense de que la zona se deriva de las coordenadas. Verifiquen que la zona horaria del navegador corresponde a la zona del punto elegido. Para las regiones fronterizas esto no siempre es evidente.
7. Verifiquen el estado del permiso. Consulten navigator.permissions.query para la geolocalización y asegúrense de que corresponde a la estrategia elegida.

Ejemplo de la práctica

Un servicio de reparto exigía confirmar el barrio mediante geolocalización. El equipo, que gestionaba varias cuentas de socios, usaba proxies móviles de una misma región y entregaba a todos los perfiles un mismo punto: el centro de la ciudad según la base de IP. A las dos semanas las cuentas cayeron en revisión manual: decenas de cuentas con coordenadas idénticas hasta el sexto decimal eran una anomalía evidente. La sustitución por puntos individuales en barrios distintos con deriva resolvió el problema para las cuentas nuevas.

Lista de verificación de la geolocalización

• Se eligió una estrategia consciente: no solicitado, permitido, denegado.
• El estado del permiso corresponde a la estrategia y no es idéntico e instantáneo en una masa de perfiles.
• Las coordenadas se encuentran a entre 1 y 30 km de la ciudad de la IP según las bases.
• Las coordenadas no coinciden con el centroide de la ciudad y son únicas para cada perfil.
• La precisión corresponde al tipo de dispositivo del perfil.
• Hay deriva entre sesiones.
• La zona horaria coincide con la zona de las coordenadas elegidas.

Método 4. Marco integral "Pasaporte del perfil" y protocolo de autocomprobación

La idea: una ficha, una historia

Las listas de verificación dispersas funcionan mientras hay una decena de perfiles. Cuando son cientos, se necesita un sistema. Nosotros lo llamamos "Pasaporte del perfil": un documento o un registro en una tabla donde para cada perfil se fija la fuente de verdad y todos los campos derivados de ella. El principio: cualquier campo debe derivarse del anterior, y ninguno debe contradecir la IP.

Estructura del pasaporte

• IP y operador. Rango del proxy móvil, operador, región según dos o tres bases, fecha de verificación.
• Zona IANA. Derivada de la región de la IP. Se indican el desfase y el indicador de presencia de horario de verano.
• Idiomas. Configuración regional principal, lista completa, cadena Accept-Language.
• Configuración regional de formato. Formato de fecha y números, salida esperada de toLocaleDateString.
• Estrategia de geolocalización. Una de las tres estrategias; si es "permitido": coordenadas base, precisión, reglas de deriva.
• Contexto del sistema. Idioma del sistema operativo, estado de la sincronización horaria, distribuciones de teclado.
• Tipo de dispositivo. Perfil móvil o de escritorio, porque de eso dependen las expectativas sobre la precisión de la geolocalización y el formato de los encabezados.
• Historial de cambios. Cuándo y por qué cambiaron la zona o los idiomas, para no dar saltos bruscos.

Protocolo de autocomprobación antes del lanzamiento

1. Verifiquen la IP en varias bases. Registren país, región y ciudad. Si al menos una base da otra región, márquenlo como riesgo y, de ser posible, soliciten al proveedor del proxy una dirección con una geografía más inequívoca.
2. Abran una página de verificación del entorno. Comparen la zona horaria, el idioma y la geolocalización mostrados con el pasaporte. Háganlo en dos servicios distintos: usan bases y métodos diferentes.
3. Ejecuten su propio script. Debe recopilar los mismos campos que el antifraude y resaltar de inmediato los desajustes. Abajo hay un ejemplo mínimo que se puede pegar en la consola.
4. Verifiquen las combinaciones cruzadas. La zona derivada de las coordenadas es igual a la zona del navegador. El idioma corresponde al país. La etiqueta de la zona está en el idioma del perfil.
5. Simulen la rotación. Cambien la IP del proxy y repitan los pasos 1 a 4. Asegúrense de que la región no cambió o de que el perfil se reconstruyó.
6. Registren el resultado. Anoten la fecha de la verificación en el pasaporte. Repitan el procedimiento tras actualizar el navegador, la herramienta o el sistema operativo.

Script de autocomprobación

Este fragmento recopila los campos principales y los imprime en una sola línea. No sustituye nada, solo lee, exactamente lo mismo que hace el antifraude en los primeros milisegundos.

(function(){ var tz = Intl.DateTimeFormat().resolvedOptions().timeZone; var loc = Intl.DateTimeFormat().resolvedOptions().locale; var jan = new Date(new Date().getFullYear(), 0, 15).getTimezoneOffset(); var jul = new Date(new Date().getFullYear(), 6, 15).getTimezoneOffset(); var out = { zone: tz, offsetNow: new Date().getTimezoneOffset(), offsetJan: jan, offsetJul: jul, dst: jan !== jul, dateString: new Date().toString(), language: navigator.language, languages: navigator.languages.join(','), locale: loc, dateFormat: new Date().toLocaleDateString(), numberFormat: (1234567.89).toLocaleString() }; if (navigator.permissions) { navigator.permissions.query({ name: 'geolocation' }).then(function(p){ out.geoPermission = p.state; console.table(out); }); } else { console.table(out); } })();

¿Qué buscar en la salida? La zona debe coincidir con el pasaporte. El indicador dst debe corresponder a las reglas de la zona. La cadena dateString debe contener la etiqueta en el idioma del perfil. El array languages debe coincidir con el encabezado. El formato de fecha y números debe corresponder a la configuración regional. El estado de geolocalización debe corresponder a la estrategia. Cinco minutos de verificación ahorran días de recuperación de cuentas.

Cómo integrar el marco en el equipo

Nombren a un responsable de las plantillas de perfil. Cualquier cambio en la plantilla pasa por el protocolo de autocomprobación. Cada trimestre revisen las regiones de los proxies: los operadores redistribuyen rangos y la base puede "mudarse". Establezcan un reglamento breve para cuando el proveedor de proxies añade nuevas regiones: primero el pasaporte, después el lanzamiento. Es aburrido, pero precisamente los procesos aburridos distinguen a los equipos que escalan de los que cada mes empiezan desde cero.

Errores típicos: lo que comete incluso un equipo experimentado

Error 1. Configurar el entorno según el lugar físico del módem

El módem está en una ciudad, las bases asignan la IP a otra y el perfil está configurado para la primera. La plataforma ve la segunda. Oriéntense siempre por los directorios, no por la geografía del hardware.

Error 2. Definir el desfase en lugar de la zona

Un número fijo rompe el horario de verano y la etiqueta localizada. Para las zonas rusas es menos notorio; para las europeas y norteamericanas provoca olas estacionales de desajustes.

Error 3. Sustituir solo el encabezado o solo el objeto

Accept-Language dice una cosa y navigator.languages otra. Este es el error más frecuente y el más fácilmente detectable. Verifiquen ambos niveles después de cada cambio.

Error 4. Olvidar la configuración regional de formato

El idioma es ruso, pero la fecha se renderiza como 3/5/2026 porque la configuración regional de formato se heredó de un sistema inglés. Es un detalle, pero cae en el mismo análisis cruzado.

Error 5. Un solo punto de geolocalización para todos los perfiles

El centroide de la ciudad según la base de IP es un punto común para miles de usuarios de herramientas de sustitución. Las coordenadas únicas con deriva resuelven el problema.

Error 6. Denegación masiva e instantánea de la geolocalización

La denegación en sí es normal. La denegación idéntica en todas las cuentas de la red, no. Diversifiquen las estrategias o dejen el estado "no solicitado".

Error 7. Ignorar el reloj del sistema

Las máquinas virtuales y los dispositivos antiguos pierden la hora. Una desincronización de minutos se ve en el servidor desde la primera solicitud. Activen la sincronización de red y verifíquenla.

Error 8. No vigilar la rotación de regiones

La rotación de IP llevó la dirección a una región vecina con otra zona, y el perfil quedó como estaba. Limiten la rotación a una región o actualicen el pasaporte con cada cambio.

Error 9. Cambiar bruscamente la zona de una cuenta activa

La cuenta se registró en Europe/Moscow y al día siguiente opera desde Asia/Vladivostok. Si el cambio de región es necesario, háganlo de forma gradual y con una explicación lógica a través del comportamiento: pausas, regiones intermedias, un horario de actividad correspondiente.

Error 10. Verificar una vez y olvidar

Actualizar el navegador, la herramienta o el sistema operativo puede restablecer la configuración regional y la zona. Repitan el protocolo de autocomprobación después de cualquier actualización.

Herramientas y recursos

Bases de geolocalización IP

Usen al menos dos o tres bases independientes: directorios comerciales de grandes proveedores de geodatos, así como servicios que agregan varias fuentes y muestran las discrepancias. Para los rangos móviles es especialmente valiosa la posibilidad de ver no solo la ciudad, sino también el operador y el tipo de conexión. Los proveedores de proxies móviles que se preocupan por la calidad suelen indicar la región según las bases directamente en la interfaz de entrega de la dirección: usen esa información y verifíquenla ustedes mismos.

Páginas de verificación del entorno del navegador

Los servicios públicos de verificación muestran la zona horaria del navegador, los idiomas, la configuración regional, el estado de la geolocalización y los comparan con la IP. Su valor está en la claridad y en que usan bases distintas. Su limitación está en que no conocen su leyenda y no verifican las combinaciones cruzadas como lo hace una plataforma concreta. Por eso, complementen con su propio script.

Herramientas antidetect y sus ajustes

Las soluciones maduras permiten definir la zona IANA por su nombre, derivarla automáticamente de la IP, sincronizar la lista de idiomas con el encabezado y configurar la geolocalización con precisión y deriva. Al elegir una herramienta, hagan cuatro preguntas: ¿se define la zona por su nombre?, ¿coinciden el encabezado y el objeto de idiomas tras la sustitución?, ¿se pueden definir coordenadas únicas por perfil?, ¿se actualiza el entorno al cambiar la IP? Una respuesta negativa a cualquiera de ellas es motivo para buscar una alternativa o compensar la carencia con control manual.

Scripts propios y automatización

El fragmento de arriba es un punto de partida. Los desarrolladores del equipo pueden llevarlo hasta una verificación automática: el script se ejecuta al iniciar el perfil, compara la salida con el pasaporte y bloquea el trabajo ante una discrepancia. Para escenarios de API, conviene implementar la misma lógica del lado del servicio de gestión: antes de entregar el perfil al operador, el entorno se verifica automáticamente.

Directorios de zonas y utilidades

La base de zonas IANA es pública y se actualiza con regularidad. Tengan a mano una tabla de correspondencia entre regiones y zonas, sobre todo para países con varios husos. Para derivar la zona a partir de las coordenadas existen bibliotecas listas que se integran en la automatización. Para sincronizar la hora usen los medios del sistema operativo o un cliente de hora de red dedicado.

Documentación interna

La tabla "Pasaporte del perfil", el reglamento de cambios de plantillas y el registro de verificaciones son herramientas no menos importantes que cualquier servicio. Sin ellas, el conocimiento vive en la cabeza de una sola persona y se va con ella.

Casos y resultados

Caso 1. Cuentas publicitarias y una plantilla heredada

Un equipo de seis operadores gestionaba cuentas publicitarias en una gran plataforma social con proxies móviles rusos. La plantilla del perfil se creó para un proyecto angloparlante y contenía la zona America/New_York y los idiomas en-US, en. La proporción de cuentas que llegaban hasta la primera recarga se mantenía en torno a un tercio. Tras implementar el pasaporte del perfil con zona Europe/Moscow, idiomas ru-RU, ru, en-US, en y estrategia de geolocalización "no solicitado", la proporción creció hasta aproximadamente cuatro quintos en el transcurso de un mes. Los proxies, los dispositivos y los demás ajustes no cambiaron. La única variable fue la coherencia de los tres campos.

Caso 2. Fallo estacional en un equipo con proxies europeos

El equipo trabajaba con proxies de varios países europeos y definía la zona horaria mediante un desfase numérico fijado en invierno. A finales de marzo comenzó una ola de verificaciones adicionales en tres plataformas simultáneamente. El análisis mostró que la zona declarada implicaba la transición al horario de verano, pero el desfase había quedado en el de invierno. El cambio a zonas IANA con nombre resolvió el problema en un día, y en otoño el fallo no se repitió. Lección: el desfase no es la zona.

Caso 3. Marketplace y coordenadas idénticas

Un vendedor con varias cuentas en un marketplace usaba proxies móviles de una misma región y permitía la geolocalización, entregando a todas las cuentas las coordenadas del centro de la ciudad. A las dos semanas las cuentas cayeron en revisión manual con solicitud de documentos. Las cuentas nuevas se configuraron con coordenadas únicas en barrios distintos, precisión de 20 a 60 metros y deriva entre sesiones. Durante el trimestre siguiente ninguna de las cuentas nuevas recibió una solicitud de verificación adicional. Las antiguas hubo que recuperarlas a través de soporte.

Caso 4. Scraping de contenido regional

Un desarrollador recopilaba precios regionales de un sitio que muestra ofertas según la geolocalización y el idioma. Con proxies móviles de Siberia, pero con zona e idioma por defecto del contenedor (UTC y en-US), el sitio devolvía periódicamente precios promediados y, a veces, una página de confirmación de región. Tras vincular la zona Asia/Novosibirsk, el idioma ru-RU y el encabezado Accept-Language correcto a cada pool regional, la proporción de respuestas correctas creció de aproximadamente dos tercios a casi la totalidad, y el número de páginas de confirmación cayó a unidades por día. Aquí no se trata de bloqueos, sino de calidad de los datos: un entorno incoherente simplemente echaba a perder la muestra.

Caso 5. Una rotación que lleva al huso vecino

Una agencia trabajaba con proxies cuya rotación de IP a veces trasladaba la dirección de la provincia de Samara a Tartaristán. La primera región pertenece a la zona Europe/Samara, la segunda a Europe/Moscow. Los perfiles con zona fija quedaban cada pocos días "a una hora de distancia" de la IP. Después de que el proveedor limitó la rotación a una sola región y el pasaporte del perfil empezó a verificarse en cada inicio, las desviaciones desaparecieron. Es revelador que el problema se detectó solo por el registro de autocomprobación: visualmente todo parecía normal.

Preguntas frecuentes: cuestiones complejas sobre zona horaria, idioma y geolocalización

¿Basta con que la zona horaria del navegador coincida en el desfase si el nombre de la zona es otro?

No. La zona Europe/Moscow y la zona Europe/Istanbul tienen el mismo desfase, pero historias de cambios distintas y etiquetas localizadas distintas. Además, el antifraude compara el nombre de la zona con la ciudad de la IP directamente, no a través del desfase. Definan siempre la zona por su nombre, correspondiente a la región.

La IP móvil las bases la identifican como Moscú, aunque el módem está en otra región. ¿Para qué configurar el perfil?

Para lo que ven las bases. La plataforma compara su perfil con sus directorios, no con la realidad. Si dos o tres bases coinciden en Moscú, usen Europe/Moscow y una leyenda moscovita. Si las bases discrepan, pidan al proveedor una dirección con una geografía inequívoca o elijan la variante que coincida con la opinión de sus plataformas objetivo en las primeras sesiones.

¿Es obligatorio incluir el inglés en la lista de idiomas de un perfil rusoparlante?

No es obligatorio, pero es deseable. La mayoría de los navegadores añaden el inglés por defecto como idioma de reserva, y una lista de ru-RU, ru, en-US, en parece más natural que un único ru-RU. Lo principal es que el inglés no esté primero y que la lista coincida en el encabezado y en el objeto navigator.languages.

¿Qué es más seguro: denegar la geolocalización o permitirla con coordenadas coordinadas?

Para la mayoría de las plataformas lo más seguro es la tercera variante: dejar el permiso en estado "no solicitado". Permitir con coordenadas coordinadas vale la pena donde la ubicación es parte de la funcionalidad. La denegación masiva e idéntica es la opción menos acertada, porque forma un patrón reconocible.

¿Con qué frecuencia hay que reverificar el entorno de perfiles que ya funcionan?

Como mínimo después de cada actualización del navegador, de la herramienta antidetect o del sistema operativo, y también ante cualquier cambio de región del proxy. Una verificación planificada es razonable hacerla una vez al mes. La verificación automatizada en cada inicio de perfil elimina la cuestión por completo.

¿Puede una desincronización del reloj del sistema por sí sola causar problemas?

Por sí sola, rara vez. Pero añade puntos de riesgo y rompe parte de la lógica de las plataformas ligada a las marcas temporales. Una desincronización de horas casi siempre significa que la hora se configuró a mano, y eso combina mal con la leyenda de un usuario común. Mantengan la desviación dentro de segundos.

¿Hay que cambiar la zona horaria del navegador si la cuenta "se muda" a otra región junto con el proxy?

Sí, pero de forma gradual y con lógica. Un salto brusco de una zona a otra incompatible genera preguntas. Si la mudanza es necesaria, hagan una pausa en la actividad, cambien la zona junto con la IP y adapten el horario de actividad a la nueva zona. Los saltos frecuentes de ida y vuelta son el peor escenario.

¿Cómo influye el idioma en la visualización de la zona horaria en el navegador?

Directamente. La etiqueta localizada de la zona en la representación de cadena de la fecha se muestra en el idioma de la interfaz del navegador. Si el idioma del perfil es ruso y la etiqueta está en inglés, es un indicio de que la configuración regional del sistema difiere del idioma declarado. Verifiquen new Date().toString() como indicador de esa filtración.

¿Basta con un solo servicio público de verificación para asegurarse de la coherencia?

No. Distintos servicios usan distintas bases de IP y interpretan los campos de forma diferente. Usen dos o tres servicios más su propio script, que verifica las combinaciones cruzadas para su leyenda concreta.

Conclusión: una historia en lugar de tres contradicciones

La zona horaria del navegador, el idioma y la geolocalización son los campos más baratos de verificar y los más elocuentes de todos los que el navegador entrega al sitio. No exigen de la plataforma ni cálculos pesados ni aprendizaje automático. Basta con una regla simple: todo debe concordar con la IP. Precisamente por eso un entorno desajustado les cuesta tan caro a quienes trabajan con proxies móviles: una IP limpia de un operador real se devalúa si alrededor de ella se arma un usuario que no existe.

Resumamos lo esencial:

• La IP es la fuente de verdad. Oriéntense por lo que las bases dicen de ella, no por la posición física del módem.
• Definan la zona horaria por el nombre de la zona IANA, no por el desfase, y verifiquen sus tres representaciones y su comportamiento en invierno y en verano.
• Coordinen el idioma en todos los niveles: encabezado, objetos navigator, configuración regional de formato, configuración regional del sistema y distribución del teclado.
• Elijan la geolocalización como estrategia, no como coordenadas. Si permiten el acceso: puntos únicos, precisión realista, deriva.
• Lleven un pasaporte del perfil y ejecuten el protocolo de autocomprobación en cada inicio y después de cada actualización.

¿Qué hacer ahora? Hoy: ejecuten el script de autocomprobación en uno de sus perfiles activos y comparen la salida con lo que las bases dicen de su IP. Lo más probable es que encuentren al menos una discrepancia. Esta semana: creen una tabla de pasaportes para todos los perfiles activos. Este mes: integren la verificación en el proceso de lanzamiento y nombren a un responsable de las plantillas. Esto no requiere nuevos presupuestos, pero devuelve la inversión en proxies móviles de calidad, que hasta ahora podían estar trabajando a media máquina por culpa de tres campos desajustados.

Un entorno coherente no garantiza la inmortalidad de las cuentas: eso no lo garantiza nada. Pero elimina la señal más ruidosa y más evidente con la que empieza cualquier verificación. Y, por lo tanto, le da a todo lo demás que hacen bien una oportunidad de funcionar.