¿Cómo comprobar la coherencia del UserAgent? Las 4 grietas que delata un UA incoherente

En los sitios de detección, la casilla del UA se muestra normal, pero a los pocos días de iniciar sesión vuelve a saltar la verificación. El primer reflejo suele ser cambiar de UA o instalar una extensión más que lo modifique. El resultado: las anomalías aparecen todavía con más frecuencia.

La causa de estos casos suele estar en la coherencia. El UA es un solo campo, pero la plataforma no lo lee en un único punto. Si solo cambias uno, los demás conservan el valor original, y al cotejarlos salta la contradicción.

El primer paso de una comprobación del UA es verificar que este campo dice lo mismo en todas las superficies expuestas; después toca contrastarlo con el dispositivo, la región y el resto de parámetros. Este artículo desglosa primero los tres canales por los que la plataforma lee el UA y enumera luego las cuatro clases de señales que delata una incoherencia. Al final encontrarás una lista de cinco puntos de control y el método de configuración dentro de un navegador de huella.

Los tres canales por los que la plataforma lee el UA

Un mismo valor de UA, la plataforma lo lee en realidad en tres sitios: las cabeceras HTTP, las cabeceras Client Hints y el script de la página. Los tres canales son independientes y cada uno se puede verificar por separado.

Al emitir la petición, la cadena de UA de las cabeceras es el canal más temprano: el sitio la lee antes incluso de servir la página. Desde Chrome 89, la información del dispositivo se separa en las cabeceras de la serie Sec-CH-UA. Marca del navegador, plataforma y versión de la plataforma tienen cada una su propia cabecera, que el sitio consulta según convenga. La documentación de Client Hints de MDN describe con claridad la estructura de estas cabeceras.

El tercer canal está en el script de la página. navigator.userAgent y navigator.userAgentData vuelven a informar, desde dentro de la página, de los datos del navegador y de la plataforma. En teoría, las tres lecturas coinciden al carácter. Si se modifica uno de los puntos por separado, los otros dos no cambian.

Aquí es justo donde tropiezan las extensiones que cambian el UA. La mayoría solo sustituye la cadena de UA de las cabeceras; cuando lee el script de la página, aparece todavía el valor original, y los dos canales chocan en el acto. Detectar este tipo de contradicción no exige ninguna técnica avanzada: basta con que un script de control de riesgos compare dos lecturas.

Un contexto que conviene conocer: Chrome está congelando poco a poco la información de las cadenas de UA antiguas, la parte final del número de versión ya está fijada y más detalles se trasladan a Client Hints. El margen para jugar solo con la cadena de UA se estrecha; lo que cada vez pesa más es que los canales encajen entre sí.

Qué delata una incoherencia del UA: cuatro tipos de señales

Visto solo, un UA no es verdadero ni falso; dentro de la combinación de señales es donde se distinguen las grietas. La mayoría de las incoherencias que aparecen cuando el entorno falla caen en alguna de estas cuatro categorías.

Primera categoría: canales que se contradicen. Las cabeceras informan de Chrome 126 mientras la lectura del script de la página sigue en Chrome 118; o la marca declarada en Sec-CH-UA no coincide con lo que devuelve navigator.userAgentData. Una lectura así apenas admite una explicación: el UA se modificó por separado y el cambio no cubrió todos los canales.

Segunda categoría: la declaración choca con el hardware. El UA dice iPhone, pero la pantalla muestra una resolución de escritorio de 1920×1080 con cero puntos táctiles; el UA declara Windows, pero el renderizador de la GPU informa de un chip de Apple. Los parámetros de hardware son medidas tomadas del entorno real; el UA es un valor declarado que se puede rellenar a gusto. Al cotejar ambos lados, la grieta resalta mucho más que el propio UA. Las causas de estas contradicciones se revisan parámetro por parámetro en por qué la aleatorización de huellas no es segura.

Tercera categoría: contradicción con la combinación del entorno. La IP de salida está en Estados Unidos, pero el UA es el de un navegador en chino, y la lista de idiomas y la zona horaria apuntan a otra región. UA, sistema, idioma, zona horaria e IP deberían componer el mismo perfil regional; en cuanto uno se desvía, todo el perfil resulta sospechoso. Cambiar el UA no resuelve este tipo de contradicción: lo que hay que tocar es la configuración del entorno.

Cuarta categoría: discrepancia con la capa de transporte. Las características que deja la negociación TLS parecen las de una herramienta automatizada o de un navegador muy antiguo, mientras las cabeceras anuncian un Chrome reciente. Las características de la capa de transporte son más difíciles de disfrazar que el UA, y a la plataforma le cuesta poco comprobar si ambos lados se corresponden.

De las cuatro categorías, las tres primeras se evitan ya en la fase de configuración del entorno; la cuarta depende del propio modo de conexión. En el día a día, vigila las tres primeras: si detectas lecturas contradictorias, vuelve a revisar la configuración.

Cómo se hace la comprobación de coherencia: cinco puntos de control

No depends de ningún sitio de detección: pasa cinco controles en orden.

1. Contraste de canales: abre una página de detección desde el entorno y revisa en el panel Network de las herramientas de desarrollador el UA y el Sec-CH-UA de las cabeceras; después compáralos con la lectura de navigator.userAgent en la consola: los tres deben coincidir.

2. Contraste de hardware: coteja el tipo de dispositivo declarado por el UA, punto por punto, con la resolución de pantalla, la capacidad táctil, el renderizador de la GPU, el número de núcleos y la memoria; si declara un tipo de dispositivo, las medidas deben parecerse a las de ese dispositivo.

3. Contraste regional: el idioma del UA, la lista de idiomas del navegador, la zona horaria y la IP de salida deben pertenecer al mismo perfil regional; en móvil, la declaración debe además corresponderse con las características de la red móvil.

4. Contraste de versiones: la versión del navegador del UA debe situarse en el rango dominante del mercado objetivo; una versión más nueva que la última, o detenida hace varios años, es una señal anómala, y además debe encajar con el comportamiento del motor.

5. Registro de verificación: tras cada ajuste de configuración, vuelve a pasar la página de detección y archiva las lecturas de cada ronda; cuando el entorno presente una anomalía, esos registros serán el punto de partida del diagnóstico.

En cuanto a las herramientas, CreepJS recoge justamente las contradicciones entre lo que leen los scripts de la página y lo que el navegador dice ser: probado en un entorno con el UA cambiado, señala directamente los canales en conflicto. Los sitios de detección generalistas como Browserscan sirven para tomar la lectura global de los cinco parámetros. Usa los dos en combinación. El UA es solo una señal dentro de la coherencia del entorno; para el orden de revisión de todo el entorno, el artículo sobre la comprobación de coherencia anti-vinculación incluye una lista de seis puntos que puedes combinar con estos cinco.

Emparejar el UA en un navegador de huella

Para corregir guiándote por los cinco puntos de control, lo más eficaz es generar el UA junto con sus parámetros correspondientes en lugar de rellenar cada uno a mano. MostMate es un navegador de huella con IA, pensado para quienes empiezan: prepara un entorno de navegador independiente para cada cuenta, y la coherencia del UA encaja de lleno en su flujo de configuración. Antes de poner manos a la obra, puedes recorrer la página de presentación de MostMate para ver el proceso completo de creación.

Al crear un entorno, eliges primero el sistema operativo y la versión del navegador, y el User-Agent se genera a partir de ahí, editable cuando haga falta. Idioma, zona horaria y geolocalización tienen por defecto el modo «configuración basada en la IP»: en cuanto eliges el proxy de salida, su combinación regional con el UA cuadra automáticamente. El panel de vista previa de la huella muestra en tiempo real el User-Agent y los valores actuales del resto de parámetros; desde la fase de creación ya se ve si toda la configuración se sostiene, sin esperar a que el entorno esté en marcha para corregir.

El nivel de detalle también se puede definir a mano: en los ajustes de huella manual, once parámetros como el UA, la pantalla, la zona horaria y el idioma se eligen uno a uno, mientras que la configuración recomendada de la página principal genera directamente un entorno coherente según la lógica del dispositivo. Cada camino tiene sus escenarios.

Conviene señalar el límite: la coherencia entre el UA y la configuración del entorno reduce una categoría de señales expuestas. Que una cuenta acabe vinculada o no por la plataforma depende además de las reglas de la plataforma, de las relaciones entre cuentas y del comportamiento de uso; la configuración del entorno solo resuelve la capa del entorno.

Preguntas frecuentes

Con una extensión que cambia el UA, ¿por qué resultas más reconocible?

La extensión normalmente solo cambia el canal de las cabeceras; el script de la página y Client Hints siguen leyendo el valor original. En cuanto aparece una contradicción entre canales, es como si «UA modificado» quedara escrito en las lecturas. La contradicción es en sí misma una señal anómala, mucho más llamativa que no cambiar nada.

¿Es mejor un número de versión del UA más reciente?

Con situarse en el rango de versiones dominantes del mercado objetivo basta. Más nuevo que la última versión o parado en una antigua de hace varios años: ambas cosas son señales anómalas. La versión además debe corresponderse con el comportamiento del motor; perseguir la novedad por sí sola no tiene sentido.

¿Se puede usar un UA móvil en un entorno de escritorio?

Sí, pero la resolución de pantalla, la capacidad táctil, la memoria del dispositivo y demás parámetros deben configurarse a la vez como los de un móvil. Para ver cómo se enlazan estos parámetros, el artículo sobre la huella de resolución de pantalla y tamaño de ventana incluye las correspondencias detalladas.

Si el sitio de detección muestra un UA coherente, ¿ya no hay problema?

Las lecturas de los sitios de detección cubren sobre todo los parámetros accesibles a los scripts de la página; las características de la capa de transporte y parte de los detalles de Client Hints no siempre figuran en la lectura. Conviene sacar conclusiones después de pasar los cinco puntos de control.

Conclusión

La meta de la comprobación del UA es que los tres canales y todo el entorno se cuenten la misma historia: canales sin choques, declaraciones que cuadran con las medidas de hardware, una combinación regional con sentido y versiones dentro de un rango razonable. Recorriendo los cinco puntos de control en orden, la mayoría de las grietas a nivel de UA se descartan antes de poner el entorno en marcha. Comprobar antes de lanzar es lo más barato.

Al crear un entorno nuevo, pasa esta comprobación antes de meter la cuenta: da mucho menos trabajo que andar cambiando el UA después de que salte la verificación. Si quieres gestionar tus entornos con este flujo, puedes descargar MostMate: desde elegir el sistema y configurar el proxy hasta revisar la vista previa de la huella, deja el UA y todo el entorno listo de una sola vez.