TL;DR
- ✓A proxy-unaware app ignores the OS HTTP proxy setting (or uses raw sockets/QUIC), so configuring Burp as a system proxy captures nothing.
- ✓The fix is to force its traffic to your proxy at a lower layer using transparent redirection: iptables NAT on a rooted Android device, DNSChef to spoof DNS, or a tun/VPN interface that routes all app traffic.
- ✓Once redirected, you still must defeat certificate pinning, typically with a Frida script or objection so the app trusts your interception CA.
- ✓mitmproxy in transparent mode and Burp's invisible/transparent proxy mode are built to receive this forcibly redirected traffic.
- ✓For non-HTTP protocols, a tun-based VPN capture plus Frida hooks on the raw socket or TLS layer is the last resort.
You set Burp as the device proxy, install the CA, open the app, and see nothing. The app is proxy-unaware: it does not read the system HTTP proxy setting, or it talks over raw sockets or QUIC that an HTTP proxy does not handle. Configuring a proxy the polite way will never work here.
The answer is to stop asking the app and start forcing it. This post walks through transparent redirection (iptables, DNSChef, VPN/tun), getting that traffic into mitmproxy or Burp, and then the pinning bypass you still need afterward to actually read it.
What makes an app proxy-unaware?
An app is proxy-unaware when it does not honor the operating system's HTTP proxy configuration, so traffic bypasses any proxy you set in Wi-Fi settings. This happens for a few distinct reasons, and the cause determines the fix.
- The HTTP client is configured to ignore system proxy settings (common with some OkHttp, Flutter, and React Native configurations).
- The app uses raw TCP/UDP sockets or a custom protocol rather than a standard HTTP stack.
- It uses QUIC/HTTP3 over UDP, which a classic HTTP proxy does not intercept.
- It pins certificates, so even captured traffic is encrypted to a cert you do not control.
The first three need forced redirection at the network layer. The last needs a pinning bypass, covered later. The two problems are independent and you often have to solve both.
How do you force traffic with a transparent proxy?
You force redirection by rewriting the packet path at a layer below the app so it cannot opt out. On a rooted Android device, iptables NAT rules redirect outbound ports to your interception proxy running transparently.
A typical setup runs mitmproxy in transparent mode and uses iptables to redirect ports 80 and 443 to it. For example: iptables -t nat -A OUTPUT -p tcp , dport 443 -j DNAT , to-destination <proxy-ip>:8080, with mitmproxy started as mitmproxy , mode transparent. Burp offers the same idea through its invisible/transparent proxy listener. Because the redirect happens in the kernel NAT table, the app's own proxy settings are irrelevant. This is the cleanest path when you have root and the app uses TCP-based HTTPS.
Proxy-aware vs proxy-unaware interception path
1
Proxy-aware
Set Burp/mitmproxy as the device HTTP proxy, install the CA, traffic flows. Done if no pinning.
2
Force redirect (rooted)
iptables NAT redirects ports 80/443 to a transparent mitmproxy. App proxy settings become irrelevant.
3
Force redirect (no root/iOS)
DNSChef spoofs DNS plus a tun/VPN interface routes all packets through your proxy.
4
Bypass pinning
objection or a Frida hook on TrustManager/OkHttp/NSURLSession so the app trusts your CA.
5
Non-HTTP fallback
tun capture plus Frida hooks on socket/TLS calls; or block UDP/443 to force QUIC down to TCP.
When do you use DNSChef or VPN redirection?
Use DNS spoofing or a VPN/tun interface when iptables alone is not enough, for example on a non-rooted device, an iOS device, or when the app uses non-HTTP protocols. DNSChef answers the app's DNS queries with your machine's IP, pulling its connections to a host you control where your proxy listens.
The VPN/tun approach is the most general: a local VPN profile (or a tool that creates a tun interface) routes every packet from the device through your machine, where you redirect or capture it regardless of the app's proxy awareness. This works on iOS and on non-rooted Android because it operates at the OS VPN layer rather than needing iptables. Combine DNSChef (to control where the app connects) with a transparent mitmproxy (to terminate TLS) for full coverage of stubborn HTTP apps.
How do you bypass certificate pinning after redirecting?
After redirection you still need the app to trust your interception CA, which means defeating certificate pinning. The fastest route is objection's one-liner (android sslpinning disable or the iOS equivalent), which patches common pinning implementations at runtime.
When that fails, write a Frida script targeting the app's actual pinning layer: the Android TrustManager and OkHttp CertificatePinner, or NSURLSession and the lower-level SecTrust APIs on iOS. Hook the verification method and force it to return success. For deeper pinning, you may patch the smali after decompiling with apktool and repackage. Pinning bypass is a core MASVS network control; we cover where it fits in the mobile pentest checklist and the broader workflow in what mobile app penetration testing is.
Strobes insight
Redirection and pinning are two separate problems. iptables or a VPN gets the packets to you; a Frida hook makes the app trust your CA. Solve both or you will capture encrypted noise.
What if the app uses non-HTTP protocols?
For raw sockets, custom binary protocols, or QUIC, fall back to a tun/VPN capture plus Frida hooks on the app's own networking calls. An HTTP proxy cannot parse these, so you intercept at the boundary where the app hands data to the OS.
Hook the app's socket write/read functions or its TLS library with Frida and log the plaintext buffers before encryption and after decryption, which sidesteps both pinning and the unusual wire format. For QUIC specifically, the simplest move is often to disable HTTP3 (block UDP/443 with iptables so the app falls back to TCP/TLS) and then intercept normally. Record exactly what leaves the device; this same forced-interception capability is part of the runtime testing that agentic pentesting automates.
Frequently asked questions
What does proxy-unaware mean for a mobile app?
It means the app ignores the operating system's HTTP proxy setting, so configuring Burp Suite as the device proxy captures none of its traffic. This happens when the app's HTTP client is set to ignore system proxies, or when it uses raw sockets, a custom protocol, or QUIC/HTTP3 over UDP instead of a standard HTTP stack.
How do you intercept traffic that ignores the proxy?
Force redirection at a layer below the app. On rooted Android, use iptables NAT to redirect ports 80 and 443 to a transparent mitmproxy. On iOS or non-rooted devices, use DNSChef to spoof DNS plus a tun/VPN interface that routes all packets through your machine. The app cannot opt out of kernel-level or VPN-level redirection.
Do I still need to bypass SSL pinning after redirecting?
Yes, if the app pins certificates. Redirection only gets the packets to your proxy; pinning means the app still refuses to trust your interception CA. Use objection's sslpinning disable command, or a Frida hook on the TrustManager, OkHttp CertificatePinner, or NSURLSession to force certificate validation to succeed.
What is the difference between iptables redirect and a VPN capture?
iptables NAT redirection works in the kernel on a rooted Android device and is ideal for TCP-based HTTPS. A VPN/tun capture works at the OS VPN layer, so it functions on iOS and non-rooted Android and handles non-HTTP protocols. Use iptables when you have root and standard HTTPS; use VPN/tun for broader coverage.
How do you intercept an app that uses QUIC or raw sockets?
For QUIC, block UDP port 443 with iptables so the app falls back to TCP/TLS, then intercept normally. For raw sockets or custom binary protocols, use a tun/VPN capture combined with Frida hooks on the app's socket read/write or TLS functions to log plaintext buffers before encryption and after decryption.
What is DNSChef used for in interception?
DNSChef is a DNS proxy that answers the app's DNS queries with an IP you control, pulling its connections to your interception host. It is useful on non-rooted or iOS devices where iptables is unavailable, and it pairs well with a transparent mitmproxy that terminates TLS for the redirected connections.
Sources and references
S
Shubham Jha
Security Researcher, Strobes
Shubham Jha leads offensive security research at Strobes, focused on web and API exploitation and red team tradecraft.
