BotBrowser Launcher: configurar el proxy y verificar la IP de salida

BotBrowser Launcher puede iniciar un perfil autorizado con un proxy declarado, pero no puede reparar una ruta del proveedor ni demostrar que una IP pertenece a una persona. Este artículo añade una comprobación repetible de la IP de salida a BotBrowser Launcher: perfiles, proxy e inicio, en lugar de repetir su introducción.

BotBrowser Launcher admite iniciar un perfil autorizado con un proxy configurado y registrar la ruta observada; no garantiza la disponibilidad del proveedor, el anonimato ni una IP de destino concreta.

TL;DR

• Introduce el endpoint del proxy en Launcher y guarda el protocolo efectivo junto con una etiqueta sin secretos.
• Comprueba la IP pública desde una página controlada y compárala con un segundo servicio independiente.
• Trata DNS, WebRTC, zona horaria e idioma como observaciones separadas.
• No pongas credenciales en capturas ni en JSON. Un fallo de salida describe configuración o proveedor, no identidad.

Contenido

• Qué añade este artículo
• Ejecutar la comprobación de salida
• Guardar un artefacto pequeño
• Diagnosticar una diferencia
• Conclusión

Qué añade este artículo

La guía de Launcher explica perfiles, inicio y la forma general de una URL de proxy. La pregunta operativa que falta es qué endpoint usó realmente el navegador. Una petición controlada y fechada responde a esa pregunta. No sustituye las diferencias de protocolo de configuración de proxy ni la comprobación de familias de dirección de consistencia IPv4 e IPv6.

Usa un perfil temporal nuevo en la primera ejecución. Asigna un identificador como proxy-check-20261016-01 y anota versión, sistema, protocolo y ciclo del perfil. La etiqueta del perfil describe la prueba, no a un usuario.

Ejecutar la comprobación de salida

1. En Launcher selecciona el perfil e introduce un endpoint ocultando el secreto, por ejemplo socks5h://user:***@proxy.example.test:1080.
2. Abre una página HTTPS de eco que controles y registra dirección pública, familia, hora y estado HTTP.
3. Abre un segundo endpoint en el mismo contexto. Una diferencia puede venir de rutas o familias distintas; no demuestra por sí sola qué servicio falla.
4. Comprueba desde tu endpoint dónde se resolvió un nombre de prueba: mediante proxy, localmente o de forma desconocida.
5. Compara idioma y zona horaria observados con la región esperada antes de aplicar una modificación.

Conserva una tabla: respuesta de Eco A, respuesta de Eco B, límite DNS, resultado WebRTC e idioma. Cada fila debe indicar qué observación permite y qué no permite afirmar.

Guardar un artefacto pequeño

{
  "runId": "proxy-check-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "hostOs": "macOS 15",
  "profile": "fresh-temporary",
  "protocol": "socks5h",
  "echoA": { "status": 200, "family": "ipv6" },
  "echoB": { "status": 200, "family": "ipv6" },
  "dns": "proxy-side",
  "webrtc": "no-public-candidate",
  "localeMatch": true,
  "testedOn": "2026-10-16"
}

Este registro no contiene credenciales, cookies ni datos completos del resolver. Solo demuestra el fixture nombrado. Para los detalles del protocolo, consulta la configuración de proxy y la consistencia de proxy IPv4 e IPv6.

Diagnosticar una diferencia

Si ambos ecos muestran la dirección del host, revisa esquema y puerto guardados por Launcher y repite con un perfil nuevo. Si solo cambia un servicio, compara su cadena de redirecciones y la familia de dirección. Si DNS es local con socks5h, confirma el soporte del proveedor antes de cambiar el navegador.

Si WebRTC muestra un candidato público, registra navegador y ruta exactos. Una preferencia de ICE no reescribe la ruta ascendente del proveedor. Si cambian idioma o zona horaria, conserva la diferencia y decide qué fuente es autoritativa para la prueba.

No publiques credenciales de proxy ni registros de tráfico. Un timeout, una autenticación rechazada y una conexión directa de reserva tienen responsables distintos; el artefacto debe mostrar esa responsabilidad sin guardar secretos.

Conclusión

La configuración de Launcher es verificable cuando termina con una IP observada, dos respuestas de eco, el límite DNS, el resultado WebRTC y el perfil que produjo la medición. Es una prueba acotada de un recorrido autorizado, no una promesa de anonimato ni de control del proveedor.

Fuentes públicas

• Proxies y túneles (MDN)
• WebRTC (W3C)
• DNS sobre HTTPS (RFC 8484)