How to see network requests on your iPhone

By Ryan · Published 2026-07-28

You can watch every network request an iPhone app makes, in plaintext, on the phone itself. It takes two ordinary iOS features: a root certificate you install and trust from Settings, and a local VPN configuration that lets an app publish device-wide proxy settings. Neither needs a jailbreak, and once both are in place the requests show up as they happen — including the ones from apps you didn't open.

Two pieces of iOS do all the work

Seeing network requests on iOS means putting something in the middle of the connection and giving it permission to decrypt. The proxy half is a NEProxySettings configuration published by a NetworkExtension provider, which is the only way to set an HTTP proxy that applies to cellular as well as Wi-Fi on a device with no MDM enrollment. The decryption half is a root certificate: TLS refuses to hand plaintext to anything that can't present a certificate signed by an authority the client already trusts, so the inspector generates its own authority and you decide to trust it. That's the whole design.

Install the certificate, then trust it — they're two decisions

iOS splits installing a root certificate and trusting it into two separate steps in two separate places, and skipping the second one is the single most common reason a capture comes back empty. Installing puts the certificate on the device; trusting it is what allows it to vouch for other hosts.

1. Install. The inspector serves a configuration profile from 127.0.0.1 — your own device, not the internet — and iOS asks whether to allow the download. Approve it, then open Settings, tap the Profile Downloaded row near the top, and install it. The warning about an unmanaged, unsigned root is expected: the certificate was generated on your device moments earlier and no outside authority has signed it.
2. Trust. Settings → General → About → Certificate Trust Settings, at the very bottom. Turn on the switch under "Enable Full Trust for Root Certificates". This screen only lists certificates that are already installed, so if the toggle isn't there, step 1 didn't finish.
3. Allow the VPN configuration, confirm with Face ID or your passcode, and start a capture.

The setup guide has a screenshot of every one of those dialogs, including the VPN prompt where iOS highlights "Don't Allow" rather than the button you want.

The VPN prompt isn't what it looks like

The VPN configuration iOS asks you to approve exists to carry a proxy setting, not to tunnel your traffic somewhere. A NetworkExtension provider is the mechanism iOS offers for setting a device-wide proxy on an unmanaged phone, so an on-device inspector has to register one — and the status bar shows the VPN icon regardless of whether anything is actually being routed.

In Tracer, three details make that checkable rather than just reassuring. The provider claims a single route inside 198.18.0.0/15, the range RFC 2544 reserves for benchmarking, and the code never reads packetFlow, so nothing is captured at the packet layer at all. Every hostname is matched by declaring the empty string as a match domain, the empty string being a suffix of every hostname. And the proxy listens on loopback inside the extension process, so a request goes: app → system proxy setting → 127.0.0.1 → the real origin server. The full mechanism is in how on-device network inspection works.

One consequence worth knowing up front: this is a device-wide capture, not a per-app one. Every proxy-aware app on the phone lands in the same log, which is what makes the technique useful for reading apps you didn't write, and also why a session contains traffic you didn't knowingly cause.

What a single logged request contains

Each HTTPS connection arrives at the proxy as a CONNECT host:443 line; the proxy answers HTTP/1.1 200 Connection Established, performs the TLS handshake itself using a leaf certificate minted for that hostname on the spot, and from there records a normal HTTP conversation before forwarding it on. What gets stored for every exchange:

• method, full path, status code and HTTP version;
• request and response headers, verbatim;
• both bodies, decoded — JSON, form data, protobuf blobs;
• start and end timestamps, giving a duration per request (the call below took 592 ms);
• the remote IP, and the cloud provider and region it resolves to, frozen onto the connection at the moment it was made.

Read a session by who it talked to, not request by request

A minute of ordinary use produces more requests than anyone wants to page through, so the useful first pass is to group them by hostname and ask who owns each host. Most of the surprises in a capture aren't individual payloads — they're the number of separate companies involved in an app you thought of as one thing. In a capture of a single indie iOS app on 2026-07-23, five organizations showed up in one session: PostHog and Google for analytics, Axiom for logs, RevenueCat for subscriptions, and Supabase for the backend.

If reading those payloads is the actual goal — which requests are the app working and which are tracking riding along — that's the subject of what data apps send about you, and the teardowns do it for specific apps.

Capturing changes two things about your connections

A capture is not transparent, and both distortions are visible in the recorded exchanges rather than hidden.

• HTTP/2 becomes HTTP/1.1. Tracer advertises only http/1.1 in ALPN, to the app and to the origin server alike, so a host that would normally negotiate HTTP/2 is spoken to over HTTP/1.1 for the duration of the session. Every recorded exchange reads HTTP/1.1, and HTTP/2 behavior — multiplexing, header compression — is out of the picture.
• Connections aren't reused. Each forwarded request goes upstream with Connection: close, so every timing you see includes a fresh TCP and TLS handshake. Treat the durations as relative, and don't benchmark through a capture.

When the log stays empty, it's one of three things

An empty or partial capture has three causes worth separating, because they look identical from the outside.

• Trust was never enabled. The certificate is installed but the Certificate Trust Settings switch is off, so nothing decrypts. Check that screen first, every time.
• An old profile is lingering. If the inspector has been reinstalled or its certificate reset, the profile still on the phone belongs to a certificate authority that no longer signs anything. Delete it under Settings → General → VPN & Device Management and install a fresh one.
• The app pins its certificate. A pinned app rejects the inspector's certificate during the handshake, so you get the hostname, the IP and byte counts, but no plaintext — and the app usually shows a connection error until you stop capturing. Pinning is per-host, not per-app: most apps that pin, pin their own API and leave their analytics and ad SDKs on the system trust store, so the rest of the session still decrypts normally.

Telling the first two apart from the third is the annoying part. The test is to evaluate the inspector's own leaf certificate against the device's trust store: if this device trusts a certificate the app just rejected, the app is pinning. Tracer runs that check on the first leaf it mints for a session — SecTrustEvaluateWithError with network fetch disabled — and writes the verdict to the system log. A trusted verdict there means the rejection is app-side and no amount of reinstalling will fix it.

What this method can never show you

Proxy-based inspection only sees clients that honor proxy settings, which on iOS means URLSession, CFNetwork and WKWebView — the large majority of what a normal app sends, but not all of it. Absent from every capture:

• HTTP/3 and QUIC, which run over UDP and ignore NEProxySettings entirely, along with anything that opens a raw socket. These don't appear as errors — they're absent, which is the harder failure to notice.
• Non-HTTP protocols — DNS lookups, push notifications over APNs, VoIP transports. Those need a recording at the packet layer, which means tethering the phone to a computer; no App Store app can read other processes' packets, because that's precisely what the sandbox prevents.
• Traffic the inspector filters by default. Tracer hides Apple system hosts and its own requests so they don't drown a session; both are toggles in settings, and the first one is worth turning off if you're specifically hunting iOS system behavior.

Trusting a root certificate is a real decision

A trusted root certificate lets whoever holds the matching private key impersonate any website to your phone, so the question isn't whether root certificates are dangerous in the abstract — it's where this particular key lives and who can use it.

Three questions settle it for any inspector. Is the authority generated on the device, or shipped inside the app binary — a baked-in root is the same key on every user's phone. Does captured traffic leave the device. And can you remove it completely afterwards.

Tracer's answers, since it's the example throughout: the authority is an ECDSA P-256 key generated on your phone inside the Secure Enclave, marked non-exportable, named CN=Tracer CA <8 hex digits>, O=Tracer, C=US with a random suffix per install — so no two users share a root and the key can't leave the phone, not even for us. Nothing captured is sent anywhere. Removal is two steps, because the key lives in a shared keychain access group rather than the app's container: Reset Certificate in the app's settings, then delete the profile. The longer version is in inspecting HTTPS traffic without a Mac.

FAQ

Generate the certificate on the phone, trust it deliberately, capture only while you're watching, and remove the profile when you're done — that's the discipline the whole technique rests on. Tracer is free to download and walks the three steps above as a checklist in about a minute, then labels every request that appears with the company, SDK and datacenter behind it. The interesting part starts once the requests do appear: the teardowns are what tends to be in them.