How to see the traffic from a phone

Phone and computer on one Wi-Fi, a proxy in the network settings, a root certificate with full trust. Four steps, and the six things that break them.

What has to be set up

Two things. The proxy setting on the Wi-Fi network makes the phone send its requests through your computer. The root certificate lets your computer decrypt them. Miss the proxy and you see nothing; miss the certificate and you see connections open and die.

How to do it

Step 1. One Wi-Fi network. Phone and computer on the same network. Not a guest network, because guest access points isolate clients and the devices cannot see each other. Turn mobile data off on the phone. Both iOS and Android switch to cellular on their own when Wi-Fi looks broken to them.

Step 2. Find the computer's address.

# macOS — Wi-Fi is usually en0; try en1 if this prints nothing
ipconfig getifaddr en0

# Linux
ip route get 1.1.1.1 | awk '{print $7}'

# Windows
ipconfig | findstr IPv4

You want a private address: 192.168.x.x, 10.x.x.x, or 172.16.x.x–172.31.x.x. Those are the three blocks RFC 1918 § 3 reserves. Not 127.0.0.1.

Step 3. Set the proxy on the phone. Address from step 2, port of the proxy. Solpuga listens on 7070. Authentication off.

iOS: Settings → Wi-Fi → ⓘ next to the network → Configure Proxy → Manual.

Android: Settings → Network & internet → Internet → gear next to the network → pencil (edit) → Advanced options → Proxy → Manual. On older Android: long-press the network → Modify network.

Now open any http:// page on the phone. Nothing loads? A firewall on the computer is blocking the port; that takes ten seconds to settle, and the proxy is not the problem. It loads? The proxy already shows http requests and attempted https connections.

Step 4. Install the certificate. The certificate is served through the proxy, so step 3 has to work first. In Solpuga the SSL Certificate menu gives you a QR code to scan, or sends the file over AirDrop.

iOS needs two more steps and both are mandatory. Install the downloaded profile: Settings → General → VPN & Device Management → the entry under Downloaded Profile → Install. Then turn on full trust: Settings → General → About → Certificate Trust Settings. The long version walks through it.

Android puts the certificate in the user store, and apps that target Android 7 (API 24) or later ignore that store. Chrome included. The fix lives in the app: a network_security_config that trusts user certificates. The long version covers it.

What usually gets in the way

A firewall on the computer. Windows blocks incoming connections by default. The macOS firewall is off out of the box, but switch it on or install a security tool and it blocks too. The check in step 3 catches both.

A VPN on the phone. An active VPN takes the traffic, and the Wi-Fi proxy setting stops applying. Turn it off.

iCloud Private Relay on iOS. Safari's traffic goes around the proxy. Fastest fix: turn off Settings → Wi-Fi → ⓘ → Limit IP Address Tracking. Globally: Settings → Apple ID → iCloud → Private Relay.

DNS over HTTPS (RFC 8484). It does not break capture, and the proxy still sees every request. It only adds connections to a resolver like dns.google or cloudflare-dns.com. Don't read those as app traffic.

An app that pins. No certificate will ever work on it. Put its host in the bypass list and the app keeps running: the traffic is recorded, just not readable. To read it you need a build that trusts your CA.

QUIC and HTTP/3. A Wi-Fi proxy only covers TCP. Anything speaking QUIC over UDP walks straight past it. In Chrome, turn it off at chrome://flags/#enable-quic; for other apps, block outbound UDP port 443 on the router.

See it on your own traffic

With all four steps in place, every request shows up: host, method, path, headers, body, response. Certificate installed and the browser on the computer still complains? That is ERR_CERT_AUTHORITY_INVALID. The full reference — Android system vs. user store, Linux/Windows ADB notes — lives in Mobile Devices.

View in Solpuga

Related