Decide whether the proxy saw a connection
An empty request list has two states behind it, and the event log distinguishes them. If the proxy recorded a TCP connection and then a failed TLS handshake, the device reached the proxy and the certificate step failed. If it recorded nothing at all, the traffic never arrived. Everything that follows depends on which of those two you have, so read the connection log before changing any setting.
Check the proxy before the app
- Confirm the proxy process runs and listens on an address the device can reach. A listener bound to the loopback address accepts connections from the host machine and refuses them from the network.
- Confirm the port is open on the host firewall, because a blocked port looks exactly like an app that never connected.
- Confirm the device is on the network you think it is on, since a Wi-Fi proxy setting has no effect over mobile data.
- Confirm the proxy runs in the mode you expect. A listener started in reverse or transparent mode does not accept a device-side proxy setting, so connections have nowhere to go.
The quick test is a request from the device browser to an unencrypted address. If that request appears in the proxy, routing and the proxy configuration both work, and the remaining problem belongs to the app or to TLS. If it does not appear, no app setting will fix it.
When nothing reaches the proxy
- The proxy setting does not apply to the network in use. A proxy configured for Wi-Fi has no effect when the device is on mobile data, and a proxy set inside one app does not apply to another app.
- The app does not read the system proxy. Some HTTP stacks and most native network libraries open their own sockets without consulting the proxy setting, so the request leaves the device directly.
- The device is on a different network from the proxy host. A proxy bound to the loopback address is reachable from the machine that runs it and from nowhere else, so the device needs an address it can actually reach.
- The traffic is not HTTP over TCP. A UDP transport such as QUIC does not appear in an HTTP proxy, and the app keeps using it until that path fails. Disabling the UDP path or capturing on the device itself brings the traffic back into view.
- A tunnel or private DNS path carries the traffic. Another app can hold a VPN tunnel, and traffic routed through it may bypass the proxy entirely.
When a connection appears and TLS fails
- The certificate authority is not installed or not trusted. The platform on current Android releases ignores a user-installed certificate for application traffic unless the app opts in, so a certificate that works in a browser can still be refused by the app.
- The app pins a certificate or a public key. The handshake fails even though the certificate chain is valid, and the proxy sees a connection close rather than a request.
- The app requires a client certificate. Mutual TLS needs the proxy to present a certificate the server accepts, and without one the server ends the connection.
- The app checks the handshake in code. A library that inspects the peer certificate or the negotiated parameters can refuse a connection that the platform accepted.
What each result rules out
- A completed handshake with no request leaves TLS working. The problem then sits in the request itself or in a protocol the proxy does not carry.
- A connection with a failed handshake points at the certificate layer. Routing works and the certificate layer is refusing, so move to the certificate checks.
- No connection at all while the app is clearly online means routing is the problem. Certificate settings cannot be the cause.
- Traffic from other apps but not from the target app points inside the app. The proxy and the certificate work for those apps, which leaves a check inside the target app.
Where to go next
A handshake refusal caused by a pinning check is a known problem with documented approaches. Intercepting pinned traffic describes the options, and Android certificate pinning traffic analysis covers the analysis. When the traffic is visible and the goal is a repeatable client rather than a one-off capture, undocumented API reverse engineering describes that work. A transport fingerprint that refuses non-app clients is covered in TLS fingerprinting.
Related work
Reviewed 28 September 2026 · SReverse research desk