Configuración recomendada: qué activar y qué dejar como está

La mayoría de los bloqueos que hemos podido atribuir a una configuración se debían a falsear más, no menos. Esta página es la versión corta de lo que medimos: los ajustes que vale la pena usar, los que te cuestan más de lo que aportan y el puñado de problemas que ningún ajuste puede resolver.

Empieza aquí

Si no lees nada más de esta página, esta es la configuración desde la que conviene partir. Varía los ejes que es seguro variar y deja el renderizado, TLS y la versión del navegador tal como están.

javascript

import { launch } from "clearcote";

const browser = await launch({
  lightStealth: true,        // metadata identity only — rendering, TLS and version stay real
  fingerprint: "account-42", // picks this identity's metadata bundle; keep it stable per identity
  proxy: { server: "http://gateway:8080", username: "u", password: "p" },
  geoip: true,               // timezone + languages + the address WebRTC reports follow the proxy exit
  humanize: true,            // trusted native input; navigator.webdriver stays false
});

En Python es la misma API, en snake_case: light_stealth, fingerprint, geoip, humanize. Agrega ejes de forma deliberada, uno a la vez, y solo cuando puedas decir qué parte del host los va a corroborar. Varias filas de abajo (los controles específicos de r12, humanize con movimiento grabado, socks5Udp, los switches de cookies de terceros y de proxy) se aplican al build con licencia (Gratis con GitHub o Pro). El build abierto los ignora: humanize recurre a trayectorias generadas, y un proxy SOCKS5 protegido con contraseña rechaza la conexión.

El principio: un valor falseado es una afirmación que el host tiene que respaldar

La detección no es una búsqueda de valores inusuales. Es una búsqueda de contradicciones: dos señales que no pueden ser ciertas a la vez en una misma máquina. Un valor común que nadie falseó no contradice nada. Un valor falseado sin nada que lo respalde es una señal positiva, y es más fuerte que el valor que intentaba ocultar.

Por eso, la pregunta útil antes de activar cualquier opción no es “¿este valor es plausible?”, sino “¿a qué parte de esta máquina se le puede pedir que lo corrobore, y la respuesta va a coincidir?” Las dimensiones de la pantalla se contrastan con la superficie de renderizado. Una cadena de GPU se contrasta con los píxeles que produce la GPU. Un sistema operativo declarado se contrasta con las fuentes que resuelve la plataforma. Si el host no puede respaldar la afirmación, el valor real es la opción más segura. Consulta Cómo funciona la detección para ver la mecánica.

Haz esto

Ajuste	Por qué
`lightStealth: true`	Aplica un conjunto coherente, derivado del seed, solo de los ejes de metadatos (`hardwareConcurrency`, `deviceMemory`, `colorDepth`, `devicePixelRatio`, `maxTouchPoints`) mediante switches nativos de un solo valor. La salida de canvas, WebGL y audio, TLS y la versión real del navegador se quedan como están. El seed solo elige cuál de un pequeño conjunto de paquetes recibe una identidad, y no hay ruido de renderizado, así que las cuentas de una misma máquina comparten su hash de canvas. En una pantalla escalada o poco común, compara en la auditoría el pixel ratio que elige el paquete con el de tu pantalla.
Un seed de `fingerprint` estable por identidad	Mismo seed ⇒ misma identidad. Reutilízalo durante toda la vida de la cuenta. Rotar el seed en cada solicitud hace que una misma cuenta con sesión iniciada llegue cada vez desde una máquina nueva, y esa es una señal mucho más llamativa que cualquiera de los valores que se rotan. Para varias cuentas en una misma máquina que no deben compartir canvas, usa la persona con seed (quita `lightStealth`) para que cada cuenta tenga su propio ruido de renderizado.
`geoip: true` en cada lanzamiento	La zona horaria, los idiomas y la dirección que reporta WebRTC siguen a la IP de salida, con o sin proxy (o define tú mismo `timezone` y `acceptLanguage`). Sin ninguna de las dos cosas, el SDK asume Nueva York y `en-US`. Una salida residencial de EE. UU. que reporta `Europe/Amsterdam` se detecta con una comprobación de una línea, y es un desajuste fácil de cometer sin querer. Si la región no se puede resolver, el lanzamiento se detiene con `GeoipError` en lugar de arrancar con el reloj de esta máquina: corrige el proxy o aumenta `CLEARCOTE_GEOIP_TIMEOUT_SECONDS`.
`humanize: true`	La entrada se genera como eventos nativos confiables sobre trayectorias de cursor con forma humana (movimiento humano grabado para los clics por coordenadas en Pro; trayectorias generadas en los demás casos). No le agregues encima tu propio easing por paso: define waypoints y deja que `humanize` interpole; el easing hecho a mano produce estadísticas de movimiento que la entrada estándar nunca produce.
`widevine: true` con la marca Chrome	La persona por defecto se presenta como Google Chrome, que responde a la consulta de DRM de Widevine. Sin el CDM, la consulta se rechaza, y eso lo puede leer cualquier página. Consulta Widevine & DRM.
`allowThirdPartyCookies: true` si falla un login o un desafío incrustado	La base sin servicios de Google bloquea las cookies de terceros, que Chrome estándar sí permite. Los frames incrustados de inicio de sesión, de pago y de desafío que dependen de ellas fallan entonces de una forma en que un navegador normal no fallaría (build con licencia, 152 r22+).
Un contexto persistente por identidad	Las cookies, el almacenamiento del sitio y la caché son parte de la identidad. Una máquina que nunca ha visto el sitio, en todas y cada una de sus visitas, es un patrón en sí mismo.
Modo con interfaz (headful) bajo Xvfb en contenedores	Chrome con interfaz evita de raíz las señales que delatan el modo headless. La imagen oficial funciona así por defecto.
Ejecuta en el sistema operativo que quieres declarar	Las palabras clave de fuentes del sistema de CSS2 las responde la plataforma que está debajo del navegador, no algo que controlen la página o el user agent, así que sobreviven a un cambio de user agent. Si no puedes, mantén intacto el conjunto de fuentes de Linux (ver más abajo).
`tlsProfile` dejado en `match-persona`	El ClientHello sigue la versión de Chrome que declara la persona, así que la capa de red y el UA coinciden. El valor por defecto ya es el correcto; la razón para saber que la opción existe es no fijarla en algo que no coincida con la versión de tu marca.

Evita esto

Cada uno de estos puntos es algo que medimos que salía mal, no una precaución genérica.

Evita	Qué sale mal
Falsear `screen` / `avail*` en un host cuya pantalla no coincide	Un tamaño de pantalla falso que no se puede conciliar con la ventana real y la superficie de renderizado dispara bloqueos de forma confiable en los sistemas antibot más estrictos. Precisamente por eso las dimensiones de pantalla no forman parte de `lightStealth` y solo se aplican si las activas. Si las defines, define todo el conjunto coherente: `screenWidth`, `screenHeight`, `availWidth` y `availHeight`, y deja un hueco plausible para la barra de tareas en lugar de hacer `avail` igual a `screen`. En headless, el SDK ya elige una pantalla plausible por ti.
Declarar una GPU en un host que renderiza por software	En un contenedor, o en una VM en la nube que rasteriza con WARP, SwiftShader o llvmpipe, una persona que declara una GPU de escritorio está describiendo un silicio que no puede producir los píxeles que la página puede leer. A partir del build con licencia 150 r12 (el build abierto lo ignora), `gpuStringSpoof: false` reporta el vendor y el renderer reales de WebGL del host sin tocar nada más, y en ese hardware suele ser el mejor compromiso. Ten en cuenta la salvedad: WebGPU sigue a la opción más amplia, `disableGpuFingerprint`, así que solo con el switch específico, `navigator.gpu` sigue describiendo la persona mientras WebGL reporta el dispositivo real.
Recurrir a `disableGpuFingerprint` o a `fingerprintNoise: false` para cambiar una sola cosa	Las dos agrupan varios cambios. `disableGpuFingerprint` cambia las cadenas y la tabla de parámetros y el farbling de readPixels y la supresión de campos de la persona; `fingerprintNoise: false` desactiva a la vez el ruido de canvas 2D y el de WebGL. Desde el build con licencia 150 r12 existen los controles específicos: `gpuStringSpoof: false` solo para las cadenas y `canvasNoise: false` solo para canvas 2D. Los dos controles específicos tienen un costo que conviene conocer: `gpuStringSpoof: false` cambia las cadenas de WebGL pero no `navigator.gpu`, así que WebGL y WebGPU terminan nombrando fabricantes distintos en la misma página: puntúa bien y se lee mal. Y `canvasNoise: false` junto con un seed elimina por completo el canvas propio de cada cuenta. Es preferible la opción amplia, `disableGpuFingerprint`, que cambia WebGL y WebGPU juntos.
Rotar la identidad a mitad de sesión	Cambiar el seed, la salida del proxy o la zona horaria mientras una sesión está activa contradice la sesión que vino antes. Rota entre identidades, nunca dentro de una.
Una persona Windows en Linux sin el conjunto de fuentes incluido	La versión para Linux incluye clones métricamente compatibles (Segoe UI→Selawik, Arial→Arimo, Times New Roman→Tinos, …) y el SDK los conecta mediante `FONTCONFIG_FILE` al lanzar. Si los quitas, o creas una imagen propia que descarta `<binDir>/fonts/`, todas las familias de Windows que declara la persona colapsan en una sola fuente por defecto. Eso se ve sin ningún dato de referencia: dos tipografías que Windows trae como distintas miden exactamente igual.
Agregar encima un plugin stealth de JS	Los controles de Clearcote están compilados en el motor. Agregar sobre ellos un shim a nivel de script reintroduce justo la capa que se delata a sí misma y que el enfoque a nivel del motor existe para eliminar: un getter sobrescrito, al convertirse en cadena, muestra su propio código fuente, y basta un `toString()` para leerlo.
Una persona móvil en un motor de escritorio, sin más	`platform: "android"` cambia el UA, la entrada táctil, el tipo de puntero, la pantalla y el viewport, pero los píxeles siguen saliendo de la GPU de escritorio (con un nombre de GPU móvil) y la geometría fina de la página sigue siendo de escritorio. Es una persona best-effort; considera la superficie de renderizado como la parte que todavía tienes que resolver.

Proxies

El proxy suele influir en el resultado más que cualquier flag del navegador, y es lo que con más frecuencia se deja en su valor por defecto.

Salidas sticky. Una IP de salida por identidad, mantenida durante toda la sesión. Una sesión cuya IP cambia a mitad del flujo se contradice a sí misma, por buena que sea la huella digital.
Haz coincidir la geografía con la persona y luego deja que geoip: true derive la zona horaria y los idiomas, en lugar de definirlos a mano.
Las credenciales del proxy las maneja el motor. Las contraseñas de proxy HTTP(S) las responde el propio navegador (build con licencia 151 r19+, SDKs de Python & Node), así que la caché de páginas sigue activa y las solicitudes no quedan marcadas por la intercepción. SOCKS5 con contraseña funciona directamente en el build con licencia: pasa el usuario y la contraseña como campos separados. transparentProxy: true (152 r22+) oculta el proxy en los encabezados de las solicitudes y en los tiempos de conexión.
Entiende el compromiso de WebRTC. Chromium nunca envía medios a través de un proxy HTTP o SOCKS, así que, si no se hiciera nada, el tráfico entre pares saldría por tu conexión real, donde un relay puede leer tu dirección verdadera. Por eso el SDK bloquea el UDP de WebRTC que saldría sin pasar por el proxy. En el build abierto, geoip / webrtcIp levanta ese bloqueo; el build con licencia lo mantiene. Combínalo con geoip: true (o webrtcIp) para que la página siga viendo los candidatos que produce un Chrome real, con la dirección del proxy; sin eso, WebRTC no reúne ningún candidato, y eso se lee como bloqueado. Para que funcionen las conexiones entre pares a través de un proxy SOCKS5, define socks5Udp: true (build con licencia; tu proveedor debe permitir el relay de UDP), o usa un túnel completo (WireGuard/OpenVPN) sin proxy en el navegador y pasa tu propio --webrtc-ip-handling-policy en args. En los demás casos, mantén la política de bloqueo por defecto.

Lo que ningún ajuste puede arreglar

Algunas de las superficies que más se leen las decide la máquina que alquilas, no el navegador que ejecutas en ella.

Superficie	Lo que decide el host
Renderizado	Un host sin GPU rasteriza por software. Todos los productos de esta categoría quedan reducidos a una de dos opciones: declarar un hardware que no puede renderizar o admitir el rasterizador por software. Si los píxeles renderizados importan para tu objetivo, la solución es un host con GPU, o el canvas bridge, que reenvía el trabajo a uno.
Fuentes	La lista de fuentes está limitada por lo que el host realmente puede dibujar: desde el build con licencia 150 r12, la lista canónica se deriva de tres mil máquinas reales y se sigue intersecando con el host, así que a una página nunca se le informa de una fuente que no se puede renderizar. En Linux, el SDK usa el conjunto de fuentes que viene con el navegador e ignora las fuentes instaladas en el host, así que instalar paquetes en tu imagen no cambia lo que ven las páginas. El conjunto del build abierto no tiene fuentes CJK, así que ahí el texto en chino, japonés y coreano se muestra con glifos faltantes; el conjunto del build con licencia sí las incluye. En Windows se usan las fuentes del propio host. Las fuentes parecidas a las de Windows que trae el conjunto hacen que los anchos sean plausibles, pero una página también puede cargar una fuente por nombre con `local()`, y una fuente parecida no lleva el nombre real: al medir con una persona Windows en Linux, Segoe UI y Georgia aparecían como instaladas y no se pudieron cargar.
Escalado de texto	Cada glifo lo dimensiona el escalador de fuentes del sistema operativo: DirectWrite en Windows, FreeType en Linux. Ningún ajuste llega hasta ahí. Al variar el tamaño de una fuente en pasos de 0.01 px, el ancho del texto cambia en el 99% de los pasos en Windows y en el 66% en Linux, y un host Linux que se presenta como Windows sigue dando 66%. Si una página lee tu texto con detalle, ejecuta en el sistema operativo que declaras. Consulta la pila de fuentes debajo del user agent.

Compruébalo en lugar de suponerlo

Todas las afirmaciones de esta página se pueden medir desde dentro del navegador. Apunta tu sesión ya configurada a la auditoría y lee las filas en las que no está de acuerdo: es la misma herramienta que usamos para encontrar los problemas descritos arriba, y te dirá cuáles de estas recomendaciones está incumpliendo tu configuración actual.

Lecturas relacionadas

DocumentaciónFlags y perfiles de huella digitalCada switch de huella de Clearcote: personas por seed, perfiles importados de Chrome real, WebGPU/WebGL, locale, almacenamiento y ruido de canvas.DocumentaciónDetección de bots: por qué fallan los spoofs JS3 capas de detección de bots, por qué los spoofs JS se delatan (toString, descriptores, realms) y cómo el C++ de Clearcote mantiene JS y TLS coherentes.DocumentaciónDespliegue: Docker y endpoint CDPClearcote como endpoint CDP stealth: la imagen oficial de Docker, serve() y cómo conectar Playwright, Puppeteer o browser-use por CDP sin cambiar código.DocumentaciónBrowser fingerprint test — coherence checksFree browser fingerprint test. Self-referential coherence checks reveal which of your browser's signals contradict each other, and how to fix them.