Capture HTTP(S) from your 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,
Same mocks, scripts, and breakpoints as every other source.
One PAC URL, any client
No SDKs, no agents to install. Anything that can talk to a proxy — a phone, a browser, a cron job — configures itself from one auto-config URL and starts streaming.
Every device keeps its identity
Each device gets its own subdomain and port, so a whole team's traffic stays cleanly attributed side by side. No more guessing whose requests those are.
Rules run at the wire
Block, mock and drop rules — and the same sandboxed JS scripting engine — run inline in the proxy itself, identical to iOS and Chrome capture. One rule set, enforced everywhere your traffic flows.
Route egress anywhere
Chain any device through an upstream or regional proxy — by country or an explicit host — straight from the dashboard. Test geo-gated behaviour without leaving your chair.
Operable without SSH
The proxy daemon reports its live build and status, streams its logs to the dashboard, and can be restarted or updated remotely. You may never open a terminal on that box again.
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
Every pair lands in the shared feed
Each decrypted request/response pair appears in your dashboard feed the moment it completes — the identical shape iOS and Android capture produce, so one feed carries every source and a retry never duplicates an entry.
- 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 stream into the feed as they happen — no queue, no batch files, and a retry never duplicates an entry
- 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.
Do I need my own upstream proxy account to route a device's egress?
No — pick a country and Busymate auto-selects a healthy proxy from the built-in pool. Bringing your own host and port works too, if you'd rather.
If I check a device's egress IPs, am I seeing what the target website sees?
No — that list is the admission IPs our proxy accepts connections from for that device, not the destination-visible origin. The external (upstream) proxy is what the target actually sees.
Built-in proxies,
Route a device through an upstream proxy from a built-in pool by default, or your own host — and know exactly which IP is which.
- 01
Real proxies, ready by default
Every device can route through a pool of predefined upstream proxies out of the box — pick one by country (or hand it an explicit host) and traffic actually egresses through it. No separate account to set up first.
- 02
One write routes a device's egress
Auto-select a healthy proxy by country, or hand it an explicit host and port. The proxy-server and the CDP connector both pick it up automatically over their settings subscription — no restart, no redeploy.
- 03
Admission IP ≠ what the destination sees
The addresses a device's egress status lists are the CONNECT-source IPs our proxy admits from that device — not the IP the target server sees. That target-visible origin is governed entirely by the external proxy you've routed through.
- 04
Credentials never reach a read
Upstream username and password are written once and stripped from every read after that — a settings fetch, an effective-settings merge, or an AI agent's tool call all see a redacted hasCredentials flag, never the value.
Connect a device in
Grab your PAC URL, trust the CA once, and watch decrypted traffic land in the feed.