Un web unlocker toma una petición HTTP normal y la reenvía desde una IP residencial con la huella TLS de un navegador real, reintenta desde una IP nueva cuando el destino la bloquea y pasa a un navegador real cuando aparece un desafío JavaScript. QuantumProxies.io lo ofrece como endpoint REST y como forward proxy, con un único saldo prepagado.
Las cabeceras de identidad que envía tu cliente (User-Agent, Accept, Sec-Fetch-*) se sustituyen por un conjunto coherente con el handshake TLS. Authorization, cookies, content type y cabeceras personalizadas pasan intactas.
Un desafío o un rechazo provoca un reintento desde una nueva salida residencial con otra familia de huellas: Chrome, Firefox, Brave. Hasta tres intentos TLS dentro de un presupuesto de 90 segundos.
Cuando todos los intentos TLS reciben un desafío, un navegador headless descarga la página y responde al desafío JavaScript. Si pasas un id de sesión sticky, la cookie de clearance obtenida se conserva y se reutiliza en tus siguientes peticiones a ese sitio dentro de la misma sesión.
El mismo motor por debajo. Elige la interfaz que tu código ya habla.
POST /api/v1/scraper/unlock con tu clave de API. Sin protocolo proxy y sin certificado: una llamada HTTPS normal que devuelve el status, las cabeceras y el cuerpo del destino más un indicador blocked.
Apunta cualquier cliente HTTP a unlock.quantumproxies.io:9000 con un subusuario proxy creado en el panel. La segmentación viaja en el nombre de usuario: país, estado, ciudad, sesión, perfil TLS y tier.
x-qp-url, x-qp-country, x-qp-session, x-qp-render, x-qp-keep-headers, x-qp-success-status y x-qp-timeout dirigen cada petición. También se aceptan las grafías de cabecera de los dos unlockers comerciales más habituales.
El Web Unlocker de QuantumProxies.io está hecho para las páginas que un cliente HTTP normal no consigue: aquellas en las que la capa anti-bot puntúa el handshake TLS y la configuración HTTP/2 antes de leer una sola cabecera. Una llamada fetch o requests lleva la firma de su runtime, ponga el User-Agent que ponga. El unlocker lo corrige en la capa de transporte y, a diferencia de la Extract API, devuelve la respuesta en bruto del origen: cualquier método, tus propias cabeceras y cuerpo, un login o un carrito mantenidos en una sola IP de salida.
Un proxy residencial rotativo cambia de dónde viene una petición. No cambia su aspecto: el handshake TLS, el orden de los frames HTTP/2 y el conjunto de cabeceras siguen diciendo Python o Node, y eso es exactamente lo que puntúan los muros anti-bot modernos. Un web unlocker reescribe la petición como la enviaría un navegador real, reintenta con otra huella cuando el origen la rechaza y pasa a un navegador real cuando el origen exige JavaScript. Conservas la interfaz del proxy; el unlocker añade el criterio.
Cada intento sale con uno de seis perfiles de navegador: Chrome, Firefox, Safari, Safari iOS, Edge o Brave, más una opción de Safari móvil en el endpoint REST. Si no fijas ninguno, los reintentos rotan la familia, de modo que un sitio que ya ha quemado un handshake se encuentra con otro. Las cabeceras de identidad se reescriben para coincidir con el perfil, porque un handshake Chrome con un User-Agent de Firefox es una señal más fuerte que cualquiera de los dos por separado. Authorization, Cookie, Content-Type y las cabeceras X-* personalizadas se reenvían tal cual, y keepHeaders envía las tuyas intactas cuando reproduces una petición capturada de una app.
Un GET bloqueado se reintenta desde una nueva salida residencial con huella rotada, hasta tres intentos TLS dentro de un presupuesto de 90 segundos. Si todos vuelven con un desafío, la petición escala a un navegador headless que responde al desafío JavaScript y devuelve la página renderizada. POST, PUT y DELETE nunca se reintentan tras una respuesta HTTP: un 403 significa que el origen vio la petición, y repetirla podría enviar dos veces un pedido o un formulario. Pon render en html o png para empezar directamente en el navegador, o render en false para quedarte en la capa TLS.
Cada respuesta se clasifica antes de llegarte. El clasificador lee las cabeceras y el cuerpo con los que los proveedores de defensa anti-bot firman sus páginas y nombra tanto al proveedor (cloudflare, datadome, akamai y otros) como la clase de bloqueo: js_challenge, captcha, ip_reputation, fingerprint, geo o timeout. En el endpoint REST una página que sigue bloqueada llega con blocked en true y con la propia página para inspeccionarla. En el forward proxy un desafío servido con un 2xx se convierte en un 502 con la cabecera x-qp-unlocker-blocked, mientras que un rechazo real del origen (403, 429, 503) se reenvía intacto. Los captchas interactivos no se resuelven: vuelven etiquetados como captcha.
Indica un país, y opcionalmente un estado o una ciudad, para salir desde ese mercado. Déjalo vacío y el país de salida se elige a partir del dominio de nivel superior del destino, con Estados Unidos como respaldo. Un id de sesión sticky mantiene la misma IP de salida entre llamadas durante 3 a 1.440 minutos, para que un login, un carrito o un listado paginado se queden en una sola identidad. El unlocker también recuerda, por dominio, qué capa y qué familia de huellas pasaron hace poco y empieza por ahí la próxima vez, y pone en cuarentena una salida que un sitio acaba de rechazar en lugar de ofrecérsela de nuevo.
El Web Unlocker funciona sobre dos pools de salida: Premium sobre IPs residenciales y Mobile sobre IPs de operadores 4G/5G, cada uno con su propio saldo prepagado en GB comprado desde el panel. El uso se mide en bytes transferidos, incluidos reintentos y renderizados en navegador, y cuando un saldo se agota el proxy responde 402 en lugar de fallar en silencio. El precio por GB de cada tier aparece en la página Web Unlocker del panel, junto al botón de compra. No hay suscripción ni permanencia mínima.
El forward proxy acepta las grafías de cabeceras de control de los dos unlockers comerciales más habituales junto a sus propias cabeceras x-qp-*, así que una integración suele migrar cambiando el host del proxy y las credenciales y nada más. En modo proxy la segmentación viaja en el nombre de usuario, como ya hacen los proxies residenciales: país, estado, ciudad, sesión, perfil y tier. HTTPS a través del proxy necesita el certificado de interceptación, descargable desde la API con tu clave. El modo directo con x-qp-url y el endpoint REST no necesitan ningún certificado.
Usa la Extract API cuando quieras una página como Markdown, HTML o JSON estructurado y no te importe cómo se obtuvo. Usa el Web Unlocker cuando necesites la respuesta en bruto del origen: una API JSON detrás de un muro anti-bot, un POST que envía un formulario, una petición con tu propia cabecera de autorización, un cookie jar que gestionas tú mismo o un scraper existente que ya habla protocolo proxy. Ambos viven en la misma cuenta y en la misma red residencial; solo el unlocker factura desde su propio saldo prepagado en GB.
Un web unlocker es un servicio que toma una petición HTTP normal y la entrega a un sitio protegido por anti-bot como lo haría un navegador real: desde una IP residencial, con huella TLS de navegador y cabeceras coherentes, reintentando desde una IP nueva si se bloquea y usando un navegador real para los desafíos JavaScript. Devuelve la respuesta en bruto del origen.
Un proxy solo cambia la IP de origen. El handshake TLS y las cabeceras de tu cliente siguen delatando una herramienta automatizada, y eso es lo que puntúan los muros anti-bot modernos. El unlocker reescribe la petición para que coincida con un navegador, reintenta con otra huella si la rechazan y escala a un navegador cuando se exige JavaScript.
Responde a los desafíos JavaScript con un navegador real y, dentro de una sesión sticky, conserva la cookie de clearance para peticiones posteriores al mismo sitio. Los captchas interactivos que requieren un humano no se resuelven: la respuesta vuelve etiquetada como captcha, con el proveedor nombrado, para que tu código decida qué hacer.
Sí. Cualquier método HTTP se reenvía con tu cuerpo, en texto o base64. Authorization, Cookie, Content-Type y las cabeceras X-* personalizadas pasan tal cual; solo se reescriben las cabeceras de identidad. Un POST se intenta exactamente una vez, porque repetirlo tras una respuesta podría enviar dos veces un formulario o un pedido.
Por GB, desde un saldo prepagado que compras en el panel para el tier que uses: Premium sobre salidas residenciales o Mobile sobre salidas de operador. Cuentan todos los bytes transferidos, reintentos y renderizados incluidos. Cuando el saldo se agota, el proxy responde 402. El precio actual por GB se muestra en el panel.
Nunca se devuelve como un éxito silencioso. El endpoint REST pone blocked en true e incluye la clase de bloqueo y el proveedor junto a la página. El forward proxy convierte un desafío servido con un 2xx en un 502 con la cabecera x-qp-unlocker-blocked y reenvía sin cambios un 403, 429 o 503 real del origen.
Sí. Pasa un id de sesión, en el cuerpo de la petición o en el nombre de usuario del proxy, y cada llamada con ese id sale desde la misma IP durante 3 a 1.440 minutos. Así un login, un carrito o un listado paginado se mantienen en una sola identidad en lugar de cambiar de IP en cada página.
Solo para HTTPS a través del forward proxy clásico, que termina el TLS para reescribir la petición; el certificado de interceptación se descarga desde la API con tu clave. El modo directo, en el que el destino va en la cabecera x-qp-url, y el endpoint REST no necesitan ningún certificado.
El tier Premium usa la misma red residencial que los proxies Residential Premium, con segmentación por país, estado y ciudad en más de 200 países. El tier Mobile usa IPs de operadores 4G/5G. Si no indicas país, la salida se elige a partir del dominio de nivel superior del destino, con Estados Unidos como respaldo.
Sáltate el marketing. QuantumProxies.io publica un mapa del sitio para LLM, Markdown de cada página, un servidor MCP gratuito y APIs cobradas del mismo saldo que tus proxies.
Conéctate con un comando: npx -y quantumproxies-mcp