Proxy · MITM

Captura HTTP(S) de tus aplicaciones

A browser, a backend, a TV, a cron job — point it at one address. Same live feed.

An Android phone, a browser and a backend server stream traffic into a central proxy hexagon on port 8888; one stream passes a block-and-script rule gate and comes out transformed, then one live stream flows on into a dashboard feed with green status codes. A globe marks upstream proxy routing. android browser server {} rules :8888 upstream live 200 201 200
Apunta cualquier cliente al proxy
bash
# Any client — point it at your per-device PAC URL:
http://<port>.busymate.net/

# Android:  Wi-Fi → Proxy → Auto-config  →  paste the URL
# Desktop:  System proxy → Automatic     →  paste the URL
# Then trust the Busymate CA once, and decrypted traffic
# streams straight into the shared live feed.

Por qué el proxy

Charles-style MITM, shared feed

Las mismas simulaciones, scripts y puntos de interrupción que cualquier otra fuente.

Una URL PAC, cualquier cliente

Sin SDKs, sin agentes que instalar. Cualquier cosa que hable con un proxy — un móvil, un navegador, un cron — se configura sola desde una URL de autoconfiguración y empieza a transmitir.

Cada dispositivo conserva su identidad

Cada dispositivo recibe su propio subdominio y puerto, así que el tráfico de todo un equipo queda limpiamente atribuido lado a lado. Se acabó adivinar de quién son esas peticiones.

Las reglas corren en el cable

Las reglas de bloqueo, simulación y descarte — y el mismo motor de scripts JS aislado — corren dentro del propio proxy, idéntico a la captura de iOS y Chrome. Un solo conjunto de reglas, aplicado allá donde fluya tu tráfico.

Enruta la salida a donde quieras

Encadena cualquier dispositivo a través de un proxy ascendente o regional — por país o con un host explícito — directamente desde el panel. Prueba comportamientos geobloqueados sin levantarte de la silla.

Operable sin SSH

El demonio del proxy informa su build y estado en vivo, transmite sus logs al panel y puede reiniciarse o actualizarse en remoto. Puede que nunca vuelvas a abrir una terminal en esa máquina.

How it works

Trust once, decrypt on demand

A Charles-style MITM that runs as a shared service: one CA, per-host leaves, and rows that land in the same table as every other capture source.

  1. 01

    A CA is born on first run

    The proxy generates its own certificate authority the first time it starts — there are no shared keys to pass around. Each device trusts that one certificate once; nothing else on the device changes.

  2. 02

    Per-host leaves, minted on demand

    For every intercepted hostname the proxy mints a leaf certificate on the fly — read from the TLS handshake's server name — and handshakes both directions: client to proxy, proxy to origin.

  3. 03

    Cada par llega al feed compartido

    Cada par de petición/respuesta descifrado aparece en el feed de tu dashboard en cuanto se completa — con la misma forma que producen las capturas de iOS y Android, así que un solo feed reúne todas las fuentes y un reintento nunca duplica una entrada.

  4. 04

    The dashboard steers it live

    Breakpoint continues, request resends, device renames and settings pushes arrive over Realtime channels the proxy subscribes to — applied in-process, no restart, no SSH session.

Endpoints & specs

The proxy, mapped

Everything a client or a script needs is served by the proxy itself — autoconfig, the CA bundle, and a per-device port pool.

Proxy + management
:8888 (HTTP proxy + management API)
TLS interception
SNI listener :8443 · per-host leaf certificates
Per-device ports
:9000–19999 pool · <port>.busymate.net
PAC autoconfig
/ · /proxy.pac · /wpad.dat (same PAC body at all three)
CA distribution
Certificate bundle served by the proxy itself; the CA is generated on first run
Ingest
Las capturas fluyen al feed según ocurren — sin colas, sin archivos por lotes, y un reintento nunca duplica una entrada
Remote control
Realtime channels for breakpoints, resends and settings; live build/status reporting and remote restart from the dashboard

FAQ

Proxy questions, answered

Which clients can I point at the proxy?

Anything that can use an HTTP proxy or a PAC URL: Android phones, desktop browsers, smart TVs, your own backends, cron jobs, debug builds. If it has proxy settings, it can stream into the feed.

Do I have to trust a certificate on every device?

Once per device. The proxy has a single CA (generated on its first run); every per-host leaf certificate chains to it, so one trust step covers every host you later decrypt.

What happens to hosts I don't want decrypted?

They pass through encrypted, untouched. Decryption is scoped by the same dashboard-managed SSL host lists that drive iOS and Android capture — one rule set for every source.

Why does each device get its own port and subdomain?

Each allocated device gets a dedicated port from the pool and a matching hostname, so a whole team's traffic stays exactly attributed in the shared feed — no guessing whose requests those are.

¿Necesito mi propia cuenta de proxy ascendente para enrutar la salida de un dispositivo?

No: elige un país y Busymate selecciona automáticamente un proxy saludable del grupo integrado. También puedes aportar tu propio host y puerto, si lo prefieres.

Si reviso las IP de salida de un dispositivo, ¿estoy viendo lo que ve el sitio web de destino?

No: esa lista son las IP de admisión desde las que nuestro proxy acepta conexiones para ese dispositivo, no el origen visible para el destino. El proxy externo (ascendente) es lo que realmente ve el destino.

Integración de proxy externo

Proxies integrados, salida real

Enruta un dispositivo a través de un proxy ascendente de un grupo integrado por defecto, o de tu propio host, y sabe exactamente qué IP es cuál.

  1. 01

    Proxies reales, listos por defecto

    Cada dispositivo puede enrutar a través de un grupo de proxies ascendentes predefinidos desde el primer momento: elige uno por país (o pásale un host explícito) y el tráfico realmente sale por él. No hace falta configurar antes una cuenta aparte.

  2. 02

    Una escritura enruta la salida de un dispositivo

    Selecciona automáticamente un proxy saludable por país, o pásale un host y puerto explícitos. Tanto el proxy-server como el conector CDP lo recogen automáticamente a través de su suscripción de ajustes: sin reinicio, sin volver a implementar.

  3. 03

    IP de admisión ≠ lo que ve el destino

    Las direcciones que muestra el estado de salida de un dispositivo son las IP de origen CONNECT que nuestro proxy admite de ese dispositivo, no la IP que ve el servidor de destino. Ese origen visible para el destino está gobernado por completo por el proxy externo por el que hayas enrutado.

  4. 04

    Las credenciales nunca llegan a una lectura

    El usuario y la contraseña ascendentes se escriben una vez y se eliminan de toda lectura posterior: una consulta de ajustes, una fusión de ajustes efectivos o una llamada a herramienta de un agente de IA ven todos una marca hasCredentials editada, nunca el valor.

Connect a device in a minute

Toma tu URL PAC, confía en la CA una vez y mira cómo el tráfico descifrado aterriza en el feed.

Ask your mate