Debug a network request

Outcome: identify what happened to a request and verify how the app handles the result.

Prerequisites

Use a development app and a connected device. HTTPS inspection requires the app to trust the proxy CA; certificate pinning or a network stack that ignores the system proxy may prevent capture. Follow the trust instructions in the network guide. Starting capture changes device proxy settings; stop it when finished.

Ask your agent

Refreshing the list fails. Use Olef to capture requests to our development
API, reproduce the refresh, and determine whether the problem is transport,
HTTP status, response data, or app handling. Check HTTPS trust first.
Restore the proxy settings when finished.

Capture one useful flow

Replace api.example.com with your development API host:

olef net start --host api.example.com
olef net status

Perform the failing action in the app, then inspect the captured requests:

olef net log
olef why

Use the returned flow IDs and the network command reference to inspect a particular request or response. A missing flow can mean the request bypassed the proxy or failed before capture; it does not establish that the app made no request.

Separate the causes

• A TLS rejection points to trust, certificates, or pinning.
• An HTTP error status means a response exists; inspect its body and the app’s handling.
• A successful HTTP response can still contain invalid or unexpected application data.
• A correct response with a stale screen points toward app state or UI handling.

For repeatable failure scenarios, use response rules or fixtures from the network guide. Keep request and response evidence scoped to development data.

Restore and verify

olef net stop

Inspect the cleanup result, including any unresolved restoration. Then make a real app request to verify connectivity. A successful raw network probe is not proof that your application’s HTTP requests work.