Erfasse HTTP(S)-Verkehr deiner Apps
A browser, a backend, a TV, a cron job — point it at one address. Same live feed.
# 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.Charles-style MITM,
Dieselben Mocks, Skripte und Breakpoints wie jede andere Quelle.
Eine PAC-URL, jeder Client
Keine SDKs, keine Agents zu installieren. Alles, was mit einem Proxy sprechen kann — ein Telefon, ein Browser, ein Cron-Job — konfiguriert sich über eine Auto-Config-URL und beginnt zu streamen.
Jedes Gerät behält seine Identität
Jedes Gerät bekommt eigene Subdomain und eigenen Port, sodass der Traffic eines ganzen Teams sauber zugeordnet nebeneinander bleibt. Nie wieder raten, wessen Requests das sind.
Regeln greifen an der Leitung
Block-, Mock- und Drop-Regeln — und dieselbe sandboxed JS-Scripting-Engine — laufen inline im Proxy selbst, identisch zu iOS- und Chrome-Capture. Ein Regelsatz, durchgesetzt überall, wo dein Traffic fließt.
Egress überallhin routen
Kette jedes Gerät durch einen Upstream- oder Regional-Proxy — nach Land oder mit explizitem Host — direkt aus dem Dashboard. Teste geo-gegatetes Verhalten, ohne den Stuhl zu verlassen.
Bedienbar ohne SSH
Der Proxy-Daemon meldet Live-Build und Status, streamt seine Logs ins Dashboard und lässt sich remote neu starten oder aktualisieren. Vielleicht öffnest du auf dieser Box nie wieder ein Terminal.
Trust once,
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.
- 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.
- 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.
- 03
Jedes Paar landet im gemeinsamen Feed
Jedes entschlüsselte Request/Response-Paar erscheint in deinem Dashboard-Feed, sobald es abgeschlossen ist — in exakt derselben Form wie iOS- und Android-Captures, sodass ein Feed alle Quellen vereint und ein Wiederholungsversuch nie einen doppelten Eintrag erzeugt.
- 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.
The proxy,
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
- Captures fließen in Echtzeit in den Feed — keine Warteschlange, keine Batch-Dateien, und ein Wiederholungsversuch erzeugt nie einen doppelten Eintrag
- Remote control
- Realtime channels for breakpoints, resends and settings; live build/status reporting and remote restart from the dashboard
Proxy questions,
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.
Brauche ich ein eigenes Upstream-Proxy-Konto, um den Egress eines Geräts zu leiten?
Nein — wählen Sie ein Land, und Busymate wählt automatisch einen gesunden Proxy aus dem eingebauten Pool. Ihr eigener Host und Port funktionieren ebenfalls, wenn Sie das bevorzugen.
Wenn ich die Egress-IPs eines Geräts prüfe, sehe ich dann, was die Ziel-Website sieht?
Nein — diese Liste sind die Zulassungs-IPs, von denen unser Proxy Verbindungen für dieses Gerät akzeptiert, nicht der für das Ziel sichtbare Ursprung. Der externe (Upstream-)Proxy ist das, was das Ziel tatsächlich sieht.
Eingebaute Proxys,
Leiten Sie ein Gerät standardmäßig über einen Upstream-Proxy aus einem eingebauten Pool oder Ihren eigenen Host — und wissen Sie genau, welche IP welche ist.
- 01
Echte Proxys, standardmäßig einsatzbereit
Jedes Gerät kann sofort über einen Pool vordefinierter Upstream-Proxys leiten — wählen Sie einen nach Land (oder geben Sie einen expliziten Host an) und der Traffic verlässt tatsächlich über ihn. Kein separates Konto vorab nötig.
- 02
Ein Schreibvorgang leitet den Egress eines Geräts
Wählen Sie automatisch einen gesunden Proxy nach Land aus oder geben Sie einen expliziten Host und Port an. Sowohl der proxy-server als auch der CDP-Connector übernehmen dies automatisch über ihr Einstellungs-Abonnement — kein Neustart, kein erneutes Deployment.
- 03
Zulassungs-IP ≠ was das Ziel sieht
Die im Egress-Status eines Geräts aufgelisteten Adressen sind die CONNECT-Quell-IPs, die unser Proxy von diesem Gerät zulässt — nicht die IP, die der Zielserver sieht. Dieser für das Ziel sichtbare Ursprung wird vollständig vom externen Proxy bestimmt, über den geroutet wurde.
- 04
Zugangsdaten erreichen nie eine Lesezugriff
Upstream-Benutzername und -Passwort werden einmal geschrieben und danach aus jedem Lesevorgang entfernt — ein Einstellungsabruf, eine Zusammenführung effektiver Einstellungen oder ein Tool-Aufruf eines KI-Agenten sehen alle nur ein geschwärztes hasCredentials-Flag, nie den Wert.
Connect a device in
Hol dir deine PAC-URL, vertraue der CA einmal und sieh zu, wie entschlüsselter Traffic im Feed landet.