Rockxy is open, capture looks on, your app is clearly making requests — and the traffic list stays empty. There are no rows to inspect, and no error to point at. The frustrating part is that "nothing is captured" has at least five separate causes, and they live in different layers: capture is off, the client is not using the proxy, the target host is outside HTTPS decryption scope, a certificate is not trusted, or an active filter is hiding rows that are actually there.
Guessing which layer is at fault is slow. This post is an ordered checklist instead. Work it top to bottom — each step either produces a captured row or rules out one cause and hands you to the next. By the end, either traffic is showing in Rockxy or you know exactly which layer to keep digging into. Two topics get their own deep-dives and are only referenced here: loopback and localhost, and proxy environment variables.
What you will need
- Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
- A terminal, so you can send a known request with explicit proxy settings and compare it against the app you are actually debugging.
- The client you care about — a browser, an app, a script, or a CLI tool — ready to repeat the request that is not showing up.
- Two numbers held apart in your head: the proxy port (Rockxy's listener, shown in its toolbar) and any app port your service runs on. Confusing the two is the most common self-inflicted miss.
Step 1 — Confirm capture is enabled and read the proxy port
Start with the cheapest cause. Open Rockxy and confirm capture is actually on — a paused or stopped session records nothing, no matter how the client is configured. While you are there, read the active proxy port from the toolbar. The examples below assume 8888, but use whatever value Rockxy shows; the port can differ between machines and can drift after a restart.
Two facts from this step carry through the rest of the checklist: capture is enabled, and you know the exact proxy port. If capture is off, turn it on and retry the failing client before doing anything else — several later steps will look broken when the real cause is simply a stopped session.
Step 2 — Prove the listener with a known request
Before blaming your client, prove the proxy port itself works. Send one request you fully control straight through Rockxy's listener — a plain external HTTPS URL, routed with an explicit proxy flag so nothing is left to system configuration:
curl -x http://127.0.0.1:8888 https://api.github.com/zenWhat you should see in Rockxy: a new row for api.github.com, with a method, a status, and timing. That single row proves capture is on and the listener is receiving traffic on the port you read in Step 1. From here, any client that still does not appear is a client-configuration problem, not a Rockxy problem — you have moved the fault out of the proxy and onto the thing sending requests.
If even this row does not appear, do not continue down the list. Re-check that capture is enabled (Step 1) and that the port in the -x flag matches the toolbar exactly. A Connection refused here almost always means a wrong or stale port. Nothing else in the checklist can succeed until this baseline works.
Step 3 — Check that the client actually uses the proxy
Step 2 proved the listener works with an explicit flag. The client you are debugging almost certainly is not passing that flag, so the question becomes: is it sending its request to the proxy at all? This is where most empty captures actually live.
Three routing rules bite here, in rough order of frequency:
- The client has no proxy configured. Many apps and libraries do not read the macOS system proxy by default. If nothing tells the client to use
127.0.0.1:8888, it connects directly and Rockxy never sees it. - A no-proxy list is excluding the host. Command-line tools and HTTP libraries honor
NO_PROXY/no_proxy. If your target is on that list, the proxy is configured but skipped for exactly the host you are testing. - Loopback is short-circuited. Requests to
localhostand127.0.0.1take a direct path that bypasses the proxy by design, even when one is set.
To test rule 1 cleanly, run the exact same request your client makes, but through curl with an explicit proxy — if that row appears in Rockxy while your app's request does not, the app is not routing to the proxy and the fix belongs in the app's configuration:
curl -x http://127.0.0.1:8888 https://your-target-host/pathRules 2 and 3 have their own dedicated guides, because the specifics differ per client and per shell. If your target is a local service, read Why Localhost Traffic Isn't Showing in Your Proxy on macOS. If you set HTTP_PROXY / HTTPS_PROXY and the client still ignores them, read Why HTTP Proxy Environment Variables Aren't Working on macOS. Both come back to the same rule: point the specific client at the proxy on purpose, and keep the target off the no-proxy list.
Step 4 — For HTTPS, confirm decryption scope and certificate trust
If your client reaches the proxy but you only see a bare CONNECT or tunnel-only row with no readable body, the request is being captured — it just is not being decrypted. That is a different failure from "no row at all," and it means routing already works.
Two conditions have to hold for Rockxy to show a decrypted HTTPS request. First, the host must be inside Rockxy's SSL Proxying scope so the app knows to decrypt it rather than pass it through blindly. Second, the client must trust Rockxy's certificate path, or the handshake fails and you get a failed transaction instead of a readable flow. The mechanics — how interception works and how to enable it per host — are covered in How to Debug HTTPS Traffic on macOS, and the certificate steps live in the certificates and trust docs.
One case will not decrypt no matter what you configure: a host that pins its certificate. Rockxy does not silently defeat pinning — a pinned or otherwise failed handshake is surfaced as a failed transaction in the request list so you can see the attempt happened, rather than quietly presenting a decrypted body that was never really available.
Step 5 — Clear any active filter or search
Sometimes the rows are already there and you are looking at a filtered view. A leftover search term, a host filter, or a status filter from an earlier session can hide the exact traffic you are hunting for, and an empty-looking list is easy to misread as an empty capture.
Clear the search box and reset any active filters, then repeat the request. If rows suddenly appear, capture was working the whole time — the view was just scoped. This is worth checking early whenever the known-request test in Step 2 succeeded but "real" traffic seems missing, because it costs nothing and rules out a whole class of false alarms.
Step 6 — Confirm the app is not ignoring the system proxy
The last common cause is an app that simply does not honor the macOS system proxy at all. Some applications ship their own network stack and either ignore system proxy settings or require the proxy to be set explicitly in their own configuration. In that case, every earlier step can look correct and the app still connects directly.
The tell is the contrast you built in Step 3: a curl request to the same host shows up in Rockxy, but the app's request never does, regardless of system proxy settings. When that is true, the fix is in the app — set its proxy option directly, or use whatever per-app network configuration it exposes. There is no proxy setting on Rockxy's side that can force an app to route traffic it was never told to route.
What success looks like in Rockxy
When the right layer is fixed, the traffic list fills in the same way it does in the screenshot below: one row per request, each with a method, a host, a status, and timing, and a detail pane that shows headers, body, and response once a row is selected. The whole point of the checklist is to get from an empty list to that first honest row — after which every harder question has far fewer places to hide.
If it does not work
The known-request test in Step 2 fails. This is a proxy-side problem, not a client one. Capture is off, or the port in your command does not match Rockxy's toolbar. Fix that first; nothing downstream can work until the listener receives the request you fully control.
The curl row appears but your app's request never does. The proxy is fine; the app is not routing to it. Either it has no proxy configured, its target is on a no-proxy list, or it ignores the system proxy and needs an explicit in-app setting. See Steps 3 and 6.
You see a tunnel row but no readable HTTPS body. Routing works; decryption does not. Add the host to SSL Proxying scope and confirm certificate trust (Step 4). If the host pins its certificate, it will stay a failed transaction — that is expected, not a bug.
The list looks empty but the known request worked earlier. Check for an active filter or search before assuming anything is broken (Step 5). A scoped view is the most overlooked cause of a "missing" capture.
Your target is on localhost or set through environment variables. Those two cases have specifics this triage post deliberately does not repeat. Follow the localhost and proxy environment variable guides for the exact commands.
Limitations to keep in mind
A few things are outside what any checklist can change. Some apps ship their own network stack and ignore the system proxy entirely — for those, an explicit in-app proxy setting is the only route, and there is nothing to toggle on Rockxy's side. Loopback and environment-variable behavior have client-specific details that the two linked deep-dives cover rather than this post. Hosts that pin their certificate will appear as failed transactions and will not decrypt, by design. And Rockxy is a native macOS app — this workflow assumes traffic originating from clients on your Mac.
Next steps
The checklist collapses to one idea: work from the proxy outward. Confirm capture and the port, prove the listener with a request you control, then move the fault onto the client — routing, HTTPS scope, certificate trust, or a stray filter — one layer at a time. The moment a known request shows up, you have turned a vague "nothing captures" into a specific, fixable layer.
From here, go deeper on whichever layer stopped you: localhost capture, proxy environment variables, or HTTPS decryption on macOS. The traffic capture docs cover the capture model in full, and the FAQ answers the most frequent setup questions. If you have not installed Rockxy yet, start from the download page.
