Android app cannot connect to Mockttp server - "socket hang up" error

[PhamH1eu]

Environment

• HTTP Toolkit Server version: 1.24.1
• Android device: Emulator (emulator-5554)
• Setup: Python script automating HTTP Toolkit integration (simulating UI flow)

Problem

Android app (tech.httptoolkit.android.v1) installs successfully but cannot connect to Mockttp server. Server logs show:
Mock session started, http on port 8000, webrtc enabled
...
Failed to handle request: socket hang up
Failed to handle request: socket hang up

Httptoolkit app on mobile device show "We couldn't connect to HTTP Toolkit. Is it running, and connected to the same network as this device?"

Flow we're using (simulating UI behavior)

We're following the exact same flow as the HTTP Toolkit UI website's worked version

1. Start Mockttp session

POST http://127.0.0.1:45456/start
Content-Type: application/json
Origin: https://app.httptoolkit.tech

{
"plugins": {
"http": {
"options": {
"cors": false,
"suggestChanges": false,
"http2": "fallback",
"https": {"tlsPassthrough": []},
"socks": true
}
},
"webrtc": {}
}
}
Response:
{
"id": "6bffc757-67ca-4d43-81c0-8a84b2f34440",
"pluginData": {
"http": {
"port": 8000,
"mockRoot": "https://localhost:8000"
},
"webrtc": {}
}
}

2. Set upstream proxy rules (simulating rules-store.ts reaction)

POST http://127.0.0.1:45456/session/{session_id}/
Content-Type: application/json
Origin: https://app.httptoolkit.tech

{
"query": "mutation SetRules($newRules: [MockRule!]!) { endpoints: setRules(input: $newRules) { id explanation } }",
"variables": {
"newRules": [{
"id": "default-wildcard",
"matchers": [{"type": "wildcard", "uiType": "default-wildcard"}],
"steps": [{
"type": "passthrough",
"proxyConfig": {
"proxyUrl": "http://gw.dataimpulse.com:823",
"noProxy": [],
"additionalTrustedCAs": []
},
"lookupOptions": {
"servers": ["127.0.0.1:8000"]
},
"simulateConnectionErrors": true,
"ignoreHostCertificateErrors": ["localhost"],
"extraCACertificates": [],
"clientCertificateHostMap": {},
"hasBeforeRequestCallback": false,
"hasBeforeResponseCallback": false
}]
}]
}
}
Also set WebSocket rules with same proxyConfig and lookupOptions.

3. Activate Android interceptor (simulating interceptor-store.ts)

POST http://127.0.0.1:45457/interceptors/android-adb/activate/8000
Content-Type: application/json
Origin: https://app.httptoolkit.tech

{
"deviceId": "emulator-5554"
}
Server behavior:

• ✅ APK installs successfully
• ✅ Certificate injection works
• ✅ Chrome flags set successfully
• ✅ ADB reverse tunnel created: adb reverse tcp:8000 tcp:8000
• ✅ Android app launched with intent: tech.httptoolkit.android.ACTIVATE
• ✅ Intent data includes correct port in setupParams:
  {
  "addresses": [...],
  "port": 8000,
  "localTunnelPort": 8000,
  "enableSocks": false,
  "certFingerprint": "..."
  }

  What happens

1. ✅ Session created on port 8000
2. ✅ Upstream proxy configured for session
3. ✅ Android interceptor activated with port 8000
4. ✅ ADB reverse tunnel exists: tcp:8000 tcp:8000 (verified via adb reverse --list)
5. ❌ Connection fails: "socket hang up" error

Verification

• Port consistency: All operations use port 8000 from /start response
• ADB reverse tunnel: tcp:8000 tcp:8000 exists and verified
• Session exists: Server log shows "Mock session started, http on port 8000"
• Intent data: Android app receives correct port in setupParams.port and setupParams.localTunnelPort
• Flow matches UI: Same sequence as web UI (start session → set rules → activate)

Expected behavior

Android app should successfully connect to 127.0.0.1:8000 via ADB reverse tunnel and establish VPN connection.

Actual behavior

Android app attempts to connect but gets "socket hang up" error. Connection fails before VPN service can start.

Additional context

• This flow exactly matches the UI behavior:
  • proxy-store.ts: Start session via PluggableAdmin.AdminClient.start()
  • rules-store.ts: Auto-sync rules via reaction when proxyConfig changes
  • interceptor-store.ts: activateInterceptor() with proxyPort
• We're using the same API endpoints and formats as the web UI
• The issue occurs even when all ports match correctly
• Manual adb reverse tcp:8000 tcp:8000 doesn't help (tunnel already exists)

Questions

1. Are there any additional requirements for the session or rules configuration?
2. Could this be related to the session being created via /start API vs. the UI's PluggableAdmin client (WebSocket connection)?
3. Does the Android app need the session to be "active" or have specific rules already set before it can connect?

[pimterry]

Hi @PhamH1eu. The tools aren't designed for automation like this - those APIs are internal, so they'll change unpredictably, they're not documented, and there's plenty of small issues you'll run into like this that could cause you problems. If you're really sure you're welcome to mess around with this of course, but I can't offer support for this kind of thing and I think it's very likely it will frequently break.

Just as one example, I have some upcoming work to significantly change this flow as part of the Android SOCKS integration, so at the very minimum you're going to have to rewrite all of this in a month or two.

For use cases like this, most of the time what you really want to do is to use Mockttp directly (getting started guide: https://httptoolkit.com/blog/javascript-mitm-proxy-mockttp/) and just manually configure the device directly (just set the proxy and install the CA certificate). You can look at the server interceptor code here to see how the system CA cert is installed, and there's more explanation here and here. If you really need the VPN, not just normal proxy config, you can use the Android app code if you want, but you'll only need the VPN part - you can just skip all the connection setup & management (which is what's causing you problems here). More info: https://httptoolkit.com/blog/inspecting-android-http. Everything you need is open source under AGPL or Apache 2.

The HTTP Toolkit desktop app will change unpredictably and has to deal with all sorts of constraints that don't make sense for fully headless automation use cases like this - you should avoid it entirely and build something out of the separate components instead. Good luck!