How to Redirect an API to Staging or Localhost with Map Remote on macOS

You have a build in your hands that talks to production, and you need it to talk to staging — or to a server running on your own Mac — for one debugging session. The base URL is compiled in, the release is signed, and recompiling right now is not an option. You just want this client, on this run, to send its calls somewhere else.

Map Remote in Rockxy does exactly that. It rewrites the destination of matching requests as they pass through the proxy, so the app keeps sending the same URL it was built with while the traffic actually lands on staging or 127.0.0.1. The outcome of this guide is a new row in the traffic list that hits your redirected destination instead of the original host — with no code change, no rebuild, and no config file edit in the app.

What Map Remote actually does

A Map Remote rule has two halves: a match (which requests it applies to) and a target destination (where those requests should go instead). When a request passes through Rockxy and matches the rule, Rockxy opens the upstream connection to the target you specified rather than the one the client asked for. The client never knows; it thinks it reached its original URL.

One thing to be precise about up front, because it is the single most common misread of this feature:

• Map Remote rewrites the destination only. It changes protocol, host, port, and path — where the request is sent. It does not change the request's header values or body. If your app also sends something like X-App-Environment: production and the new backend keys off that header, redirecting the host is not enough on its own.
• To change a header value as well, add a separate Modify Header rule. The two features compose: Map Remote handles the routing, Modify Header handles the header. Keep them as distinct rules so each stays easy to reason about.

That split is deliberate. Redirecting where a request goes and rewriting what it carries are different operations, and keeping them separate means you can toggle one without disturbing the other.

What you will need

• Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
• A client whose traffic already flows through Rockxy — an app, a browser, or a command-line tool routed through the proxy port. If your requests are not showing up yet, start with why localhost traffic isn't showing in your proxy and get one row captured first.
• The exact destination you want to redirect to: a staging host (for example staging-api.example.com) or a local server (for example 127.0.0.1:4000).
• The original request URL the client sends, so you can write a match that hits it and nothing else.

Step 1 — Capture the original request first

Before you redirect anything, prove you can see the request in its unredirected form. Run capture, trigger the call from your client, and find the row in the traffic list. Open it and read the full URL — host, port, and path — exactly as the client sent it.

What you should see in Rockxy: a row for the original destination, for example GET https://api.example.com/v1/orders. Copy that URL out of the inspector. It is the source of truth for the match you are about to write — a rule that does not match the exact captured URL will silently do nothing.

Step 2 — Add a Map Remote rule

Open the Map Remote tool in Rockxy and click the + button to add a new rule. The dialog has two sections: a matching rule at the top and a map-to destination below.

Fill the matching rule so it targets only the requests you want to redirect:

Click Add to save, then make sure the rule is toggled on before your next request. To redirect to a local server instead of staging, the only change is the Map To section: set Protocol to http, Host to 127.0.0.1, and Port to your local port.

Step 3 — Trigger the request again and watch the destination change

With the rule active, make the client send the same call it sent in Step 1. The app does not know anything changed — it still asks for api.example.com. Watch the traffic list for the new row.

What you should see in Rockxy: a fresh row whose destination is your target — staging-api.example.com or 127.0.0.1:4000 — rather than the original host. Open the before and after rows together: the request headers, method, and query string are identical because the client is unchanged; only the destination moved, and that move came entirely from the Rockxy rule.

That row is the whole point. The client asked for one host, the rule redirected it to another, and the traffic list shows the redirect happened. From here you can inspect the response from staging or your local server exactly as if the app had been built to call it.

Redirecting an HTTPS destination

If your target speaks HTTPS — a real staging host almost always does — the redirect still works, but decryption has its own requirement. To read the request and response bodies on the mapped destination, the target host must be inside Rockxy's SSL Proxying scope and the client must trust Rockxy's certificate path. Without that, you will still see the redirected row, but as a tunnel with no readable body.

The certificate mechanics are the same as for any HTTPS capture. Add the destination host to SSL Proxying, install and trust the certificate for your runtime, and confirm the decrypted body appears. The steps live in the Map Remote docs and the certificates and trust guide. One boundary to know: if the target host pins its certificate, Rockxy will not silently defeat that — a pinned or failed handshake surfaces as a failed transaction in the request list rather than a decrypted body.

If it does not work

No redirected row appears; the request still hits the original host. The rule did not match. Compare its match pattern against the exact URL you captured in Step 1 — a wrong host, port, path prefix, or a stray trailing segment is enough to miss. Confirm the rule is toggled on, and if you used Use Wildcard, check the wildcard scope actually covers the captured path.

Another rule fires instead. Rules are evaluated in order. If a broader or conflicting rule sits ahead of this one, it can claim the request first. Move your Map Remote rule before any rule that could also match, and disable rules you are not using for this session.

The destination changed but the backend still behaves as production. That is the destination-only limit doing its job. Map Remote moved the host; it did not touch your request headers. If the backend keys off a header value such as X-App-Environment, add a Modify Header rule to set the value the new environment expects.

A redirected HTTPS row is a tunnel with no readable body. That is TLS, not routing. Add the mapped host to SSL Proxying scope and trust the certificate. If the target pins its certificate, the handshake will fail rather than decrypt, and Rockxy surfaces it as a failed transaction so you can see it happened.

Limitations to keep in mind

• Destination only. Map Remote rewrites protocol, host, port, and path. Request header values and bodies pass through unchanged — pair it with Modify Header when a header also needs to change.
• Match precision matters. The rule must match the exact request URL, and it must sit before any conflicting rule in the list. A rule that does not match does nothing, silently.
• HTTPS targets need SSL Proxying scope and certificate trust before you get a decrypted body on the mapped destination.
• Pinned hosts will not decrypt. A pinned or failed handshake is surfaced as a failed transaction, not silently bypassed.

Next steps

Map Remote turns a rebuild-and-redeploy loop into a two-field rule: match the request, name the new destination, and the same shipped client points wherever you need it for the session. Redirect one call to staging or 127.0.0.1, confirm the row lands there, and iterate.

From here, the Map Remote docs cover wildcard patterns and rule ordering in depth, and the Modify Header docs cover the header side. For a worked, case-by-case walkthrough that uses Map Remote alongside Modify Header, Breakpoints, and Map Local, see the advanced API debugging workbook. If a request is not reaching the proxy in the first place, the localhost capture guide is the place to start.