--- title: "Cómo Evadir Kasada en 2026" slug: how-to-bypass-kasada date: 2026-10-07T06:12:02+00:00 modified: 2026-10-07T06:12:04+00:00 permalink: https://brightdata.es/blog/procedimientos/how-to-bypass-kasada type: blog --- [ Blog ](https://brightdata.es/blog "Blog") / [Procedimientos](https://brightdata.es/blog/procedimientos) [Procedimientos](https://brightdata.es/blog/procedimientos) # Cómo Evadir Kasada en 2026 Por qué el token x-kpsdk-ct de Kasada bloquea scrapers, qué verifica su VM ips.js, y cuándo crear un solucionador o usar el Web Unlocker de Bright Data. 25 min de lectura [ ![Satyam Tripathi](https://media.brightdata.es/2024/09/Satyam-Tripathi-50x50.png) ](https://brightdata.com/blog/authors/satyam-tripathi) [Satyam Tripathi Technical Writer ](https://brightdata.com/blog/authors/satyam-tripathi) ![How to Bypass Kasada](https://media.brightdata.es/2026/10/How-to-Bypass-Kasada-in-2026.png) Si tu scraper recibe un HTTP 429 o 403 con encabezados `x-kpsdk-*`, Kasada lo está bloqueando, y la respuesta no explica por qué. Kasada es una plataforma anti-bot que protege sitios web, APIs y aplicaciones móviles del tráfico automatizado. Ejecuta un desafío JavaScript ofuscado en el navegador, evalúa al cliente y emite un token de corta duración que toda solicitud posterior debe incluir. Para evadir Kasada, primero necesitas saber qué verifica ese script de desafío. Analicé uno real, y lo que encontré decide si debes crear un solucionador o comprar uno. ## Resumen - Kasada necesita un token válido: `x-kpsdk-ct` solo proviene de completar su desafío JavaScript, así que la suplantación TLS por sí sola no puede superarlo. - El desafío cambia en cada solicitud: es una máquina virtual personalizada, así que un solucionador copiado deja de funcionar en cuestión de horas. - Los navegadores automatizados dejan señales: una configuración predeterminada expone `navigator.webdriver`, un user agent `HeadlessChrome`, y nombres de frameworks de automatización que Kasada puede detectar. - Puedes crear o comprar: mantener un solucionador es trabajo continuo, mientras que el Web Unlocker de Bright Data ejecuta el desafío por ti y cobra por solicitud exitosa. ## Cómo confirmar que un sitio usa Kasada Un 403 o 429 te indica que algo bloqueó la solicitud. No te dice qué sistema lo hizo, y esa respuesta decide todo lo que haces después. Cloudflare, DataDome, Akamai y Kasada devuelven los mismos códigos de estado, así que el código por sí solo no puede identificar el sistema. Los encabezados y cookies de cada proveedor lo identifican, y puedes leerlos con 1 solicitud: ```none curl -sI https://target.example/ | grep -i \ -e '^x-kpsdk' -e '^set-cookie: kp_uidz' \ -e '^cf-ray:' -e '^set-cookie: __cf_bm' -e '^server: cloudflare' \ -e '^x-datadome' -e '^set-cookie: datadome' \ -e '^server: akamaighost' -e '^set-cookie: _abck' ``` Haz coincidir desde el inicio de la línea del encabezado (eso es lo que hace el `^`), no en cualquier parte de la línea. Un `grep -i akamai` amplio también coincide con encabezados no relacionados que contienen un nombre de host de CDN, como el Content-Security-Policy de la página, y devuelve falsos positivos. Cada sistema tiene una firma diferente. La fila de Kasada proviene de mi propia captura, y las demás filas provienen de la documentación pública de cada proveedor: Lo que contiene la respuestaEl sistema esEncabezados `x-kpsdk-*` y una cookie `KP_UIDz`, más un script `ips.js` que establece `window.KPSDK`KasadaEncabezado `cf-ray`, cookie `__cf_bm`, `server: cloudflare`CloudflareEncabezado `x-datadome` y una cookie `datadome`DataDome`server: AkamaiGHost` en una respuesta bloqueada, o una cookie `_abck` en una respuesta permitidaAkamaiSi ves algún encabezado `x-kpsdk-*`, el sistema es Kasada. Si ves uno de los otros, los pasos específicos de Kasada que siguen no aplican, y las guías de Bright Data para [evadir Cloudflare](/blog/web-data/bypass-cloudflare) y [detección de bots de Akamai](/blog/web-data/bypass-akamai-bot-detection) cubren esos sistemas. ## Qué verifica Kasada antes de otorgar acceso a un cliente Kasada no depende de una sola señal. Usa varias capas, y una solicitud debe pasarlas todas para recibir un token. Entender las capas explica por qué una solución que funciona contra un sistema más simple no tiene efecto aquí. La primera capa es la reputación de IP. Kasada verifica la reputación de la dirección IP y su Número de Sistema Autónomo (la red a la que pertenece la dirección). Un rango de IP de centro de datos que muchos scrapers ya usaron tiene mala reputación antes de que envíes un solo encabezado. Las direcciones IP residenciales de ISPs de consumo reales tienen mejor reputación, porque los usuarios reales se conectan desde esas mismas redes. La segunda capa es el fingerprinting TLS. Kasada lee el handshake TLS y la configuración HTTP/2, luego los compara con lo que envía un navegador real. Un cliente Python predeterminado ofrece conjuntos de cifrado y extensiones en un orden que ningún navegador usa, así que la huella no coincide con el user agent que dice tener. [Cómo funciona el fingerprinting TLS](/blog/web-data/tls-fingerprinting) cubre esto con más detalle. La tercera capa es el desafío JavaScript. Kasada envía un script ofuscado a tu cliente y verifica qué devuelve. El script construye una huella digital del entorno de ejecución, ejecuta un cálculo de prueba de trabajo (un acertijo que el cliente debe resolver) y combina ambos en un paquete cifrado. La cuarta capa es el ciclo de vida del token, que inferí de cómo funciona el protocolo y no capturé directamente, y la quinta es el análisis de comportamiento, que no probé. Una buena IP y un handshake TLS coincidente solo satisfacen las capas 1 y 2, así que las secciones siguientes se centran en las capas 3 y 4. En el orden en que una solicitud las atraviesa, las capas se ven así: ![Diagrama de las capas de detección de Kasada que una solicitud debe pasar para recibir un token, desde la reputación de IP hasta el análisis de comportamiento.](https://media.brightdata.com/2026/10/Hyceka1sMx.png)## Cómo funciona el desafío ips.js de Kasada El desafío ips.js es una máquina virtual personalizada, así que leer el script no muestra qué verifica. Para verlo directamente, solicité una página protegida por Kasada y leí la respuesta. El objetivo era un sitio web público de bienes raíces, y la respuesta fue un 429 en lugar de la página. ### La respuesta 429 y el script ips.js La respuesta incluía los encabezados de Kasada y un pequeño cuerpo HTML que inicia el desafío: ```none HTTP/2 429 x-kpsdk-r: 1-AA x-kpsdk-ct: content-type: text/html; charset=utf-8 access-control-expose-headers: x-kpsdk-ct,x-kpsdk-r,x-kpsdk-c,x-kpsdk-h,x-kpsdk-fc set-cookie: KP_UIDz-ssn= ``` Puedes ver los mismos encabezados tú mismo en Chrome DevTools, en la primera solicitud en la pestaña de Red (la entrada roja en la parte superior de la lista): ![Panel de Encabezados de DevTools para la respuesta 429, mostrando x-kpsdk-ct, x-kpsdk-r y cookies KP_UIDz con valores ocultos.](https://media.brightdata.com/2026/10/Hyef1a1jfx.png)El 429 es el desafío en sí, no un límite de velocidad, e incluye un token inicial y una etiqueta de script. El cuerpo establece un objeto `window.KPSDK` y carga el script de desafío desde una ruta única para cada sitio protegido: ```none ``` En DevTools, todo el intercambio aparece como el documento 429 seguido del script que carga, y la columna Initiator vincula el script con ese documento: ![Lista de Red de DevTools con un documento que devuelve estado 429, luego el script ips.js que devuelve 200, iniciado por ese documento.](https://media.brightdata.com/2026/10/rkkXJaJoze.png)El script, `ips.js`, es un archivo de 641 KB con casi todo su código en 1 línea. Abierto en un editor de texto, es ilegible: ![El script de desafío ips.js en un editor de texto, mostrando código minificado sin nombres legibles de funciones o variables.](https://media.brightdata.com/2026/10/ryNEy6yjfe.png)No hay nombres legibles para las verificaciones, ni cadena `navigator.webdriver`, ni función llamada `detectHeadless`. Todo el programa es una máquina virtual (VM) personalizada con su lógica compilada en bytecode, así que el código fuente que puedes leer es el intérprete, y las verificaciones permanecen ocultas en el bytecode. ### Decodificando el bytecode y la tabla de cadenas Para mirar dentro del intérprete, ejecuté su etapa de decodificación en un proceso Node.js aislado e imprimí lo que produjo. El resultado muestra el tamaño real del programa: ```none BYTECODE len: 268444 STRING POOL len: 38459 ``` Así que la carga útil es un programa de bytecode más una tabla de cadenas (la línea `STRING POOL`), ambos decodificados en tiempo de ejecución a partir de una cadena grande al inicio del script. Como el programa se decodifica a sí mismo en tiempo de ejecución, las cadenas que buscarías no existen hasta que la VM las construye mientras se ejecuta. Obtén el mismo script de nuevo y los tamaños cambian. En 3 solicitudes consecutivas más a la misma URL, el programa decodificado tenía 266,322, 275,713 y 266,322 entradas de bytecode. Diferentes partes cambian según diferentes horarios. Una ventana de 5 horas controla la clave que decodifica cualquier contenido que recibe una solicitud. El contenido en sí, es decir, el relleno y los valores almacenados dentro del script, cambia aleatoriamente en cada respuesta, independientemente de esa clave. Así que una copia guardada falla por dos razones: su clave expira, y cada nueva obtención tiene contenido diferente. ### Por qué una copia guardada del script deja de funcionar Algunas propiedades del decodificador importan si planeas construir un solucionador a partir de una copia guardada del script. Primero, la clave depende de la hora actual. El decodificador la deriva de `Math.round(Date.now() / 18000081)`, y `18000081` milisegundos son casi exactamente 5 horas. Cuando adelanté el reloj del sistema más allá de esa ventana y ejecuté la decodificación de nuevo, devolvió un programa vacío: ```none 0h -> bytecode len 268444, pool len 38459 6h -> bytecode len 0, pool len undefined ``` El decodificador acepta una clave de aproximadamente 1 ventana de tiempo antes o después de la actual, así que cuánto tiempo sigue funcionando un script guardado depende de en qué punto de su ventana lo capturaste. En mi nueva ejecución 6 horas después, ya no devolvía nada, así que un script guardado sigue siendo útil por unas horas, no un día. Segundo, la carga útil verifica su propia integridad. Cuando intercambié 2 caracteres en el alfabeto de 72 caracteres que usa el decodificador, todo el programa falló al decodificar en lugar de producir una salida incorrecta. Un verificador en el bucle de decodificación mantiene una suma de verificación continua y se detiene si se cambió algún byte. Nada de esto te da código que valga la pena copiar. El desafío es polimórfico (cambia en cada obtención), así que la lógica que copias de 1 captura no seguirá funcionando por mucho tiempo. Un solucionador que obtiene el script de forma fresca evita la copia obsoleta, pero luego tiene que decodificar contenido diferente bajo una nueva clave en cada ejecución, que es el trabajo de mantenimiento descrito en la sección de crear versus comprar. Los números anteriores provienen de 1 sitio protegido y 1 ejecución, y Kasada puede cambiar cualquiera de ellos en una versión posterior. Lo que aplica a otros sitios es el diseño. El script se verifica a sí mismo, la clave depende de la hora, y la prueba de trabajo está vinculada a la huella digital. ## Por qué el token, no la prueba de trabajo, bloquea a los scrapers La prueba de trabajo es ligera para un navegador real y económica de verificar para el servidor, así que no es lo suficientemente costosa como para bloquear la automatización solo por costo. El token es lo que bloquea a un scraper, porque Kasada emite uno válido solo para un resultado de una ejecución completa de la VM, y la prueba de trabajo es una parte de ese resultado. La prueba de trabajo requiere que el cliente ejecute la VM. La VM calcula la prueba y recopila la huella digital, luego combina ambos en 1 paquete cifrado. El script verifica su propia integridad mientras decodifica, así que un cliente tiene que ejecutar la VM y dejar que el fingerprinting funcione normalmente para devolver un resultado válido. Calcular la prueba en un servidor y adjuntar una huella digital separada no ayuda, porque Kasada solo acepta un token de 1 ejecución completa de la VM. Ese flujo termina con un token. No capturé este intercambio directamente, así que lo que sigue se infiere de cómo funciona el protocolo. El cliente envía el paquete cifrado de vuelta con una solicitud POST, y si pasa, Kasada reemplaza el valor inicial de `x-kpsdk-ct` con uno válido que otorga acceso. Cada solicitud posterior tiene que incluir ese token en su encabezado y cookie, y el token expira. Debido a que el token expira, un scraper tiene que repetir el intercambio para obtener uno nuevo. Desde el primer 429 hasta un token válido, el intercambio entre cliente y servidor se ve así: ![Diagrama de secuencia del intercambio de tokens de Kasada, desde el 429 inicial a través de la prueba de trabajo de la VM hasta un token de acceso válido.](https://media.brightdata.com/2026/10/H1SH1pkjGe.png)El token también difiere entre respuestas. A través de 3 solicitudes consecutivas, el mismo 429 de Kasada devolvió 3 valores diferentes de `x-kpsdk-ct`, así que el token no es un valor fijo que puedas capturar una vez y enviar de nuevo. ## Cómo Kasada detecta navegadores headless Si la VM necesita un entorno de ejecución que se comporte como un navegador real, el movimiento obvio es automatizar un navegador real. Eso funciona mejor que un cliente HTTP, pero un navegador automatizado predeterminado todavía envía señales, y la tabla de cadenas decodificada contiene los nombres que Kasada verifica. ### Señales en un navegador headless predeterminado Un Chromium headless sin modificar muestra que está automatizado. Lancé uno con Playwright y leí las propiedades del navegador que verifica la carga útil: ```none # pip install playwright, si aún no lo tienes from playwright.sync_api import sync_playwright with sync_playwright() as p: page = p.chromium.launch().new_page() print(page.evaluate("[navigator.webdriver, navigator.userAgent, navigator.plugins.length, window.chrome]")) ``` Los valores que imprime, mostrados aquí uno por línea: ```none navigator.webdriver true userAgent ...HeadlessChrome/ Safari/537.36 navigator.plugins 0 (un navegador real con interfaz lista varios) window.chrome null (presente en un Chrome de escritorio normal) ``` Cada línea es una señal. `navigator.webdriver` es `true` bajo automatización y `false` en un navegador normal. La cadena de user agent contiene `HeadlessChrome`. La lista de plugins está vacía, y el objeto `window.chrome` que expone un Chrome de escritorio falta. Puedes ocultar estas señales, pero cómo las ocultas importa cuando el objetivo es Kasada. Un Playwright parchado con técnicas sigilosas cambia estas propiedades con JavaScript después de que el navegador inicia, así que una verificación diseñada para encontrar tales sobrescrituras todavía puede detectarlo. Una compilación a nivel de código fuente, como el fork de Firefox [Camoufox](/blog/web-data/web-scraping-with-camoufox) o un Chromium parchado como BotBrowser, cambia los valores en el propio código C++ del navegador antes de que se ejecute ningún script. Eso no deja ninguna sobrescritura de JavaScript para que la verificación encuentre. Una compilación de Chrome desactualizada también es una señal, porque su versión no coincide con lo que usan los usuarios reales. Pero actualizar el navegador no elimina las propias señales del framework de automatización. ### Señales de los frameworks de automatización Playwright deja nombres en la página que un navegador normal no tiene. Cuando agregué un único binding a una página de Playwright, creó estas variables globales: ```none from playwright.sync_api import sync_playwright with sync_playwright() as p: page = p.chromium.launch().new_page() page.expose_binding("demo", lambda source: None) print([k for k in page.evaluate("Object.keys(window)") if "playwright" in k.lower()]) ``` Imprime estos nombres: ```none ['__playwright__binding__', '__playwright__binding__controller__'] ``` Los nombres anteriores son solo lo que crea un único binding. Por separado, busqué en la tabla de cadenas decodificada los nombres internos de binding de Playwright. Cerca de la mitad de los nombres en la versión de Playwright que probé aparecieron allí como cadenas simples, junto a `webdriver`, `HeadlessChrome` y `electron`. Los nombres que aparecieron son sus bindings de grabador y devtools. Un nombre en la tabla de cadenas decodificada no prueba que la VM actúe sobre él. Aun así, encontrarlos allí muestra que Kasada conoce estas herramientas por nombre, así que no tiene que adivinar qué biblioteca de automatización está detectando. ### Detección de CDP y las herramientas que la evitan Incluso sin un binding, el Chrome DevTools Protocol (CDP) que los frameworks de automatización usan para controlar el navegador los expone. Un [artículo sobre fingerprinting de CDP](https://svebaa.github.io/personal/blog/cdp-fingerprinting/) mostró que llamar a `Runtime.enable`, que Playwright y Puppeteer hacen por defecto, hace que el navegador serialice inmediatamente (convierta a texto) los objetos pasados a los métodos de `console`. Un script corto puede detectar esto sin mediciones de tiempo, pasando un objeto `Proxy` a una llamada de `console`: ```none let detected = false; const trap = new Proxy({}, { ownKeys() { detected = true; return []; } }); console.groupEnd(Object.create(trap)); // detected es true en Chromium más antiguo cuando un cliente CDP ha llamado a Runtime.enable ``` El autor reportó que la técnica funcionaba cuando la publicó, y lo confirmé independientemente en compilaciones de Chromium más antiguas, donde el fragmento devuelve `true` en una página de Playwright predeterminada porque Playwright llama a `Runtime.enable` por defecto. En las compilaciones de Chromium más nuevas que probé, el mismo fragmento devuelve `false`, incluso después de llamar a `Runtime.enable` yo mismo, así que Chrome ha cambiado cómo maneja los argumentos de console. Ejecútalo en tu propia versión de navegador antes de confiar en él. Una verificación como esta no necesita permisos ni extensiones, así que es económica para que un sistema anti-bot la ejecute y difícil de notar para ti. Una respuesta es controlar Chrome sin el código de framework que llama a `Runtime.enable`. Herramientas como [nodriver](/blog/web-data/nodriver-web-scraping), su fork zendriver, y el Modo CDP de SeleniumBase se comunican con Chrome directamente a través de CDP y nunca llaman a `Runtime.enable`. Forks parchados de Playwright como patchright solucionan el mismo problema dentro de Playwright. En la compilación más antigua donde el fragmento devolvió `true` para Playwright, devolvió `false` contra la página predeterminada de zendriver, porque nunca se hace una llamada a `Runtime.enable`. Cada una de estas herramientas ayuda, pero ninguna es permanente, porque la señal, la solución y la verificación de Kasada cambian todos en sus propios horarios, y el cambio de navegador anterior es un ejemplo. ## Scraping con un cliente HTTP y sus límites Muchos equipos intentan evitar el navegador por completo, y por una buena razón. Un navegador es lento y consume muchos recursos, y un cliente HTTP que presenta la huella digital correcta es mucho menos costoso por solicitud. La pregunta es qué tan bien funciona ese enfoque contra Kasada. Puedes pasar la verificación de huella digital TLS con bibliotecas como `curl_cffi` en Python o `surf` en Go, que cambian el handshake TLS para que coincida con un navegador real. Para verificar esto, usa un servicio que reporte el handshake TLS que recibe. Reporta JA4, una huella digital calculada solo a partir del handshake, y lista la configuración HTTP/2 (que Kasada también lee) como una huella digital separada: ```none # pip install curl_cffi, si aún no lo tienes from curl_cffi import requests as cf r = cf.get("https://tls.peet.ws/api/all", impersonate="chrome") print(r.json()["tls"]["ja4"]) # elimina impersonate= para ver el JA4 del cliente predeterminado en su lugar ``` Ejecútalo de ambas formas y compara. Estos son los valores que obtuve, y los tuyos diferirán a medida que los navegadores y bibliotecas se actualicen, así que verifícalos contra Chrome real en el mismo servicio: ```none curl_cffi impersonate="chrome" JA4=t13d1516h2_8daaf6152771_806a8c22fdea curl_cffi (sin impersonate) JA4=t13d2712h2_b4f9224df7c1_9ced094328c9 ``` El cliente suplantado envía un JA4 que coincide con un navegador real, mientras que el cliente predeterminado envía un JA4 que ningún navegador usa. Si fijas una versión específica de navegador, el User-Agent sigue declarando esa versión después de que Chrome real se haya actualizado, lo que hace que tu cliente parezca desactualizado. Usar `impersonate="chrome"` en su lugar deja que la biblioteca elija la versión de Chrome, así que no tienes que actualizar un número de versión. La [guía de curl\_cffi](/blog/web-data/web-scraping-with-curl-cffi) muestra la configuración completa. Volví a ejecutar el fragmento a través de un segundo servicio, `https://tls.browserleaks.com/json`, y el JA4 suplantado fue idéntico. Reporta el valor como `r.json()["ja4"]`, así que funciona como respaldo si `tls.peet.ws` no está disponible, lo cual sucedió desde mi red una vez. El problema es que el handshake TLS no es donde Kasada toma su decisión. Un cliente HTTP que pasa la verificación TLS todavía recibe el desafío, y no puede ejecutar la VM. Para obtener un token con un enfoque solo HTTP, tendrías que portar el intérprete, la recopilación de huella digital y la prueba de trabajo a tu propio código, y luego actualizar ese código cada vez que cambie la carga útil. Los servicios de solucionadores especializados venden exactamente esto como una API, generando el token y la prueba de trabajo a través de HTTP. De cualquier forma pagas un costo continuo, ya sea tu propio mantenimiento o una tarifa por solución, y el solucionador tiene que adaptarse a cada cambio de carga útil. El enfoque HTTP maneja la verificación TLS de forma rápida y correcta, pero no puede producir el token que Kasada requiere. Un punto más afecta cómo decides si una solicitud tuvo éxito. El propio [CTO de campo de Kasada ha descrito](https://www.itnews.com.au/news/rea-group-mutates-site-scraping-credential-stuffing-defences-537873) el enfoque que prefieren. En lugar de bloquear con un error, sirven una página que parece correcta pero es incorrecta, así el operador sigue creyendo que el bot funciona. Una respuesta con contenido no siempre es una respuesta correcta, así que cualquier prueba contra Kasada tiene que comparar el contenido con lo que muestra un navegador, no solo verificar que se devolvió algo. ## Crear versus comprar para Kasada En conjunto, el análisis muestra que un solucionador que creas tú mismo no es un único problema difícil. Es trabajo de mantenimiento continuo. Tendrías que mantener todo esto: - Un intérprete de VM que se adapte a una carga útil que se verifica a sí misma y una clave que rota con frecuencia - Un perfil de huella digital que coincida con las verificaciones cambiantes de Kasada - Manejo de tokens que funcione cuando un token expira durante una sesión - Un grupo de proxies con una reputación suficientemente buena para pasar la verificación de reputación de IP Crear puede tener sentido cuando apuntas a un único sitio y tienes ingenieros que pueden mantener actualizado el solucionador. Cuando apuntas a varios sitios o no puedes dedicar tiempo de ingeniería, un servicio gestionado traslada ese trabajo fuera de tu equipo. ### Web Unlocker para solicitudes individuales Un servicio gestionado es la alternativa a contratar ingenieros para ese trabajo continuo. [El Web Unlocker de Bright Data](/products/web-unlocker) toma una URL objetivo y maneja el desafío, la sesión y la elección de la IP de salida (la dirección que ve el objetivo) por ti, así que tu código envía 1 solicitud y lee el resultado: ```none curl -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{"zone":"YOUR_ZONE_NAME","url":"https://target.example/listing","format":"raw"}' \ https://api.brightdata.com/request ``` Reemplaza ambos marcadores de posición con tu propio nombre de zona y clave de API, y establece `url` con tu propio objetivo, antes de ejecutarlo. Ambos valores están en la pestaña Overview de tu zona de Web Unlocker. El panel de acceso directo a la API lista tu clave y una solicitud lista para ejecutar que ya incluye el nombre de tu zona: ![Pestaña Overview de zona Web Unlocker con el panel de acceso directo a la API, campo de clave API y una solicitud curl lista para ejecutar.](https://media.brightdata.com/2026/10/ryYL16kjMx.png)Para ver una llamada exitosa antes de usarla en un objetivo real, la pestaña Playground de la zona ejecuta la misma solicitud contra la URL de prueba de Bright Data y muestra la respuesta: ![Pestaña Playground de Web Unlocker mostrando una respuesta 200 con un cuerpo JSON corto para una URL de prueba.](https://media.brightdata.com/2026/10/H1XvJpkiMl.png)Una llamada exitosa devuelve el cuerpo de la página desbloqueada. Web Unlocker cobra por solicitud exitosa, y su nivel gratuito incluye 5,000 solicitudes al mes sin necesidad de tarjeta de crédito, así que puedes probarlo contra tu propio objetivo. La resolución de Kasada está integrada, como se describe en la [página de solucionador de Kasada de Bright Data](/products/web-unlocker/captcha-solver/kasada). Los planes y tarifas actuales están en la [página de precios de Web Unlocker](/pricing/web-unlocker). Los campos opcionales de solicitud te permiten elegir el país de salida con `country` y cargar páginas que necesitan JavaScript con `render`, ambos listados en la [referencia de la API](https://docs.brightdata.com/api-reference/rest-api/unlocker/unlock-website). Para sitios más desafiantes, habilita la opción de dominios Premium en la pestaña Configuration de la zona para agregar los recursos adicionales que esos sitios necesitan: ![La pestaña Configuration de una zona Web Unlocker de Bright Data, con el interruptor de dominios Premium habilitado.](https://media.brightdata.com/2026/10/BkkdkaJsGx.png)### Browser API para páginas interactivas Cuando el objetivo necesita interacción completa con la página, como un flujo de inicio de sesión o una búsqueda de varios pasos, la [Browser API](/products/scraping-browser) ejecuta un navegador gestionado al que te conectas. Playwright y Puppeteer lo controlan a través de CDP. La URL de conexión contiene tu ID de cliente, el nombre de zona y la contraseña de zona, y la pestaña Overview de la zona los lista todos bajo Detalles de acceso: ![Pestaña Overview de zona Browser API con el panel de Detalles de acceso, contraseña enmascarada, y la URL de conexión wss.](https://media.brightdata.com/2026/10/Hy8FyTkszg.png)Después de ingresar esos valores, se conecta como cualquier navegador remoto: ```none # pip install playwright, si aún no lo tienes from playwright.sync_api import sync_playwright CDP = "wss://brd-customer-CUSTOMER_ID-zone-ZONE_NAME:[email protected]:9222" with sync_playwright() as p: browser = p.chromium.connect_over_cdp(CDP) page = browser.new_page() page.goto("https://target.example/search") page.wait_for_selector("YOUR_CONTENT_SELECTOR") # reemplaza con un selector para el contenido que necesitas print(page.title()) browser.close() ``` Cuando te conectas de esta forma, el desbloqueo integrado de la Browser API maneja el desafío de Kasada, así que tu script funciona con una página ordinaria. Espera el contenido que necesitas con un selector, y usa ese contenido, no un código de estado, para confirmar el éxito. La Browser API también admite Selenium, y para un objetivo de Kasada, comienza con la conexión CDP mostrada arriba. La pestaña Overview de la zona también enlaza a un playground en vivo y un depurador de Chrome DevTools, así que puedes observar una sesión mientras construyes. Las tarifas actuales de la Browser API están en su [página de precios](/pricing/scraping-browser). Para páginas más simples, una única solicitud de Web Unlocker es la opción más rápida, y las [técnicas estándar anti-bloqueo](/blog/web-data/web-scraping-without-getting-blocked) manejan los casos restantes. ## Agentes de IA y bots verificados Kasada todavía está evolucionando, y el tráfico de agentes de IA cambia lo que tiene que detectar. Lanzó [AI Agent Trust](https://www.kasada.io/blog/kasada-launches-ai-agent-trust-to-secure-agentic-commerce), un producto que gestiona el tráfico de agentes de IA. Clasifica a los agentes según qué tan bien puedan probar su identidad, y permite a un sitio permitir algunos agentes y bloquear otros. Identificar agentes depende de un estándar llamado Web Bot Auth. Permite que un bot pruebe su identidad con cada solicitud, usando Firmas de Mensajes HTTP (definidas en [RFC 9421](https://www.rfc-editor.org/info/rfc9421/)), un encabezado firmado, y un directorio de claves publicado. El [grupo de trabajo del Internet Engineering Task Force (IETF)](https://datatracker.ietf.org/wg/webbotauth/documents/) mantiene los borradores, así que verifica el estado actual antes de confiar en él. Cloudflare ya [verifica estas firmas](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/) para bots que se registran con ellos. La dirección es una web donde a un agente verificado se le permite acceso y un agente no verificado debe completar el desafío completo. Nada de esto hace que un token de Kasada sea opcional para un scraper. ## Reflexiones finales Kasada bloquea las solicitudes que carecen de un token válido, y emite uno solo después de que el cliente complete su desafío que se verifica a sí mismo. La suplantación TLS solo pasa la verificación TLS, así que el problema a resolver es el token `x-kpsdk-ct`. Compara un solucionador que creas y mantienes, que puede dejar de funcionar en cuestión de horas, con el Web Unlocker de Bright Data, que ejecuta el desafío por ti e incluye 5,000 solicitudes gratuitas al mes sin necesidad de tarjeta de crédito. Si estás decidiendo dónde enfocar tu tiempo de ingeniería, comienza con la opción gestionada enviando 1 solicitud a la URL exacta que está devolviendo tus 429, y verifica el cuerpo de la respuesta en lugar del código de estado. ## Preguntas frecuentes ### ¿Cómo funciona Kasada? Kasada sirve un desafío JavaScript ofuscado desde una ruta como `/ips.js`. El script ejecuta una máquina virtual que hace fingerprinting del entorno de ejecución, calcula una prueba de trabajo y envía de vuelta un paquete cifrado. Si pasa, Kasada emite un token `x-kpsdk-ct`, y cada solicitud debe incluirlo o recibir una respuesta 429. ### ¿Se puede evadir Kasada con un solucionador gratuito de código abierto? Un solucionador gratuito de GitHub puede funcionar al principio, pero deja de funcionar rápidamente. La carga útil cambia su clave de decodificación con frecuencia (aproximadamente cada 5 horas en mi captura) y verifica su propia integridad, así que la lógica capturada deja de decodificar en cuestión de horas. Un solucionador público puede estar desactualizado, así que úsalo para estudiar, no en producción. ### ¿Actualizar Chrome evade Kasada? Actualizar ayuda pero no resuelve el problema. Una compilación antigua de Chrome es una señal por sí misma, así que una compilación actual elimina esa señal. No elimina las otras señales, como `navigator.webdriver`, una lista de plugins vacía, o las propias señales del framework de automatización, que el desafío también verifica. ### ¿Qué son los encabezados x-kpsdk? Son los encabezados de Kasada. `x-kpsdk-ct` es el token del cliente (uno válido otorga acceso), `x-kpsdk-r` y `x-kpsdk-c` son encabezados de desafío relacionados, y las cookies `KP_UIDz` correspondientes rastrean la sesión. Ver cualquier encabezado `x-kpsdk-*` en un 429 o 403 es una señal confiable de que Kasada rechazó la solicitud. ### ¿Cuál es la forma más rápida de evadir un 429 de Kasada? Enruta la solicitud a través del Web Unlocker de Bright Data, que toma la URL, maneja el desafío por ti y cobra por solicitud exitosa. Para páginas que necesitan inicio de sesión o interacción de varios pasos, usa la Browser API sobre CDP, cuyo desbloqueo integrado maneja el desafío. Contactar ventasPrueba gratuita![google social icon](/wp-content/themes/brightdata/assets/images/ic_google.svg) Tabla de Contenidos [ ](https://news.ycombinator.com/submitlink?t=C%C3%B3mo+Evadir+Kasada+en+2026&u=https://brightdata.es/blog/procedimientos/how-to-bypass-kasada) [ ](https://www.linkedin.com/shareArticle?mini=true&title=C%C3%B3mo+Evadir+Kasada+en+2026&url=https://brightdata.es/blog/procedimientos/how-to-bypass-kasada) [ ](http://www.reddit.com/submit?title=C%C3%B3mo+Evadir+Kasada+en+2026&url=https://brightdata.es/blog/procedimientos/how-to-bypass-kasada) ## Usted también puede estar interesado en [ ![Auto parts and tire data](https://media.brightdata.es/2026/10/Auto-parts-and-tire-data.png) ](https://brightdata.es/blog/datos-web/auto-parts-and-tire-data "Datos de autopartes y neumáticos: precios, ajuste, coincidencia de productos y cobertura de mercado") [Datos web ![Satyam Tripathi](https://media.brightdata.es/2024/09/Satyam-Tripathi-50x50.png) Satyam Tripathi Technical Writer ### Datos de autopartes y neumáticos: precios, ajuste, coincidencia de productos y cobertura de mercado Por qué una pieza muestra precios diferentes entre minoristas, cómo hacer coincidir listados por número de pieza, y cómo Bright Data entrega datos de autopartes y neumáticos. 05-Oct-2026 21 min de lectura ](https://brightdata.es/blog/datos-web/auto-parts-and-tire-data) [ ![Audio Web Scraping for AI Processing](https://media.brightdata.es/2026/09/Audio-Web-Scraping-for-AI-Processing.png) ](https://brightdata.es/blog/datos-web/audio-web-scraping "Scraping de Audio Web para Procesamiento con IA: Tutorial Completo") [Datos web ![Antonello Zanini](https://media.brightdata.es/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Scraping de Audio Web para Procesamiento con IA: Tutorial Completo Extrae audio a gran escala para procesamiento con IA usando Bright Data. Aprende conversión de formatos y transcripción con IA para resultados empresariales. 05-Oct-2026 18 min de lectura ](https://brightdata.es/blog/datos-web/audio-web-scraping) [ ![Chrome Dev tools with Bright Data](https://media.brightdata.es/2026/09/Chrome-Dev-tools-with-Bright-Data.png) ](https://brightdata.es/blog/ai/chrome-devtools-mcp-with-bright-data "Permite que chrome-devtools-mcp controle navegadores anti-detección en la nube") [AI ![Antonello Zanini](https://media.brightdata.es/2022/12/Antonello-Zanini-2-50x50.jpg) Antonello Zanini Technical Writer ### Permite que chrome-devtools-mcp controle navegadores anti-detección en la nube Combina chrome-devtools-mcp con el Browser API de Bright Data para que los agentes de IA controlen navegadores anti-detección en la nube sin esfuerzo. 05-Oct-2026 12 min de lectura ](https://brightdata.es/blog/ai/chrome-devtools-mcp-with-bright-data)