You are on a managed work network. Every outbound connection has to go through the company proxy — usually pushed to your Mac as a .pac file in System Settings → Network → Proxies. You point Rockxy at your traffic to debug an API call, and now nothing reaches the internet at all: requests hang or return Connection refused. So you turn Rockxy off, get your network back, and give up on capturing the call.
The reason is simple. A debugging proxy sits between your client and the destination. On a normal network it opens the outbound connection itself. Behind a mandatory corporate proxy, direct outbound is blocked — only the company proxy is allowed to reach the outside world. Rockxy tries to connect straight out, the firewall drops it, and the request dies at your machine.
The outcome of this guide: a working chain. You configure Rockxy to forward everything it captures to the corporate proxy after it inspects the traffic — proxy behind a proxy. Your request shows up as a row in Rockxy and still reaches its destination through the company's upstream. You keep debugging without fighting IT.
How chaining fixes it
Rockxy's job does not change: it terminates the connection from your client, records the request and response, then sends the request onward. The only difference on a managed network is where "onward" points.
- Without chaining Rockxy opens a direct connection to the destination. On a locked-down network that egress is denied, so the flow fails after Rockxy captures it — you may see the row, but it errors out.
- With chaining Rockxy forwards the request to the corporate proxy instead of dialing the destination itself. The company proxy is the one allowed egress path, so the request completes. You get the capture and the response.
Rockxy calls this its upstream (external) proxy. It accepts an HTTP proxy, an HTTPS proxy, or a PAC file — the same three shapes IT hands out. Whatever your .pac already decides, Rockxy can honor by pointing its upstream at that PAC URL. This is a different problem from tunneling to a self-hosted or reverse upstream for a specific protocol; if you are chaining to reach a service behind your own gateway and decoding binary frames, the upstream proxy and WebSocket Protobuf guide covers that path instead.
What you will need
- Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
- The corporate proxy details IT gave you: either a host and port (for example
proxy.corp.example:8080) or the URL of a PAC file. On macOS these are visible in System Settings → Network → your interface → Details → Proxies. - Whether the proxy requires authentication, and whether it is HTTP, HTTPS, or SOCKS5. Read the caps note below before you rely on the last two.
- The list of internal hosts that must not go through the upstream — internal registries, git servers, staging APIs on the corporate LAN. These become your bypass rules.
A note on community-tier caps
Before you wire anything, know where the free tier draws its lines so you do not get surprised mid-setup. In the community (Free) tier:
- SOCKS5 upstream is gated. If your corporate proxy is HTTP, HTTPS, or a PAC file, you are fine on Free. A SOCKS5 upstream needs Pro.
- Upstream proxy authentication is gated. If the company proxy demands a username and password, forwarding credentials through Rockxy's upstream is a Pro capability.
- Larger bypass lists are capped. A handful of bypass rules is fine on Free; long internal-host lists are lifted by Pro.
None of this changes the core debugging workflow — capture, inspect, replay all stay free. The caps only touch how far the upstream chaining itself scales. Pricing and what each tier includes are on the pricing page.
Step 1 — Read the corporate proxy your Mac already uses
Open System Settings → Network, select your active interface, click Details → Proxies, and note what is enabled. You will see one of two things: an explicit proxy host and port under Web Proxy (HTTP) / Secure Web Proxy (HTTPS), or Automatic Proxy Configuration pointing at a PAC URL. Write down whichever applies — that is exactly what Rockxy's upstream will point to.
If a request works with Rockxy off but fails with it on, this proxy is the reason. You are not going to disable it; you are going to put Rockxy in front of it.
Step 2 — Point Rockxy's upstream at the corporate proxy
In Rockxy, open the external/upstream proxy settings and enter the same target you just read from macOS. For an explicit proxy, that is the host and port. For a PAC-based network, give Rockxy the PAC URL and let it evaluate the same rules your system does.
The shape of the chain is now:
your client
-> Rockxy (captures + inspects on 127.0.0.1)
-> corporate proxy (proxy.corp.example:8080 or via PAC)
-> destination (api.example.com)If the corporate proxy needs a username and password, that is the authentication cap from the section above — a Pro capability. On the Free tier, use a proxy path that does not require credentials, or move to Pro to forward them through the chain.
Step 3 — Add bypass rules for internal hosts
Not everything should take the long way around. Internal hosts — a corporate git server, an artifact registry, a staging API that lives on the LAN — are often reachable directly and may even be broken by the external proxy. Add them to Rockxy's upstream bypass list so those requests skip the corporate proxy and go direct, while public traffic still chains through it.
Think of the bypass list the same way you think of a no_proxy entry: hosts on it are excluded from the upstream. Keep it tight and specific — for example the internal domain suffix and any host that must resolve on the corporate network. Remember the community-tier cap on list size; if you need a long list, that is one of the limits Pro raises.
Step 4 — Send one request and verify the chain
Route a client through Rockxy and hit a public endpoint that you know requires the corporate proxy to reach — a plain external API is enough:
curl -x http://127.0.0.1:8888 https://api.github.com/zenHere 8888 is Rockxy's own listener (read the real value from its toolbar), and Rockxy forwards onward to the corporate proxy you set in Step 2.
What you should see in Rockxy: a new row for api.github.com that completes — a real status code and a response body, not a failed or hung transaction. That success is the whole point: the row proves Rockxy captured the request, and the returned body proves it still reached the destination through the corporate upstream. A captured-but-failed row means the chain is not forwarding; a completed row means client, Rockxy, and the company proxy are wired together.
Capturing HTTPS through the chain
Chaining fixes reachability, not decryption. Once traffic flows, an HTTPS request will show as a tunnel with no readable body until two more things are true: the host is inside Rockxy's SSL Proxying scope, and the client trusts Rockxy's certificate path. That part is identical to any HTTPS debugging session — the corporate proxy in front does not change it. The mechanics are in How to Debug HTTPS Traffic on macOS, and the certificate steps live in the certificates and trust docs.
One real constraint on managed networks: many corporate proxies run their own TLS inspection, re-signing certificates with a company root that your Mac already trusts. When Rockxy also decrypts, you now have two inspection layers, and the certificate the destination presents to Rockxy is the corporate proxy's, not the origin's. That is expected on such networks — Rockxy sees what the company proxy hands it — but it means you are inspecting the corporate-re-signed session, not the raw origin certificate. Keep that in mind when a chain of trust looks unfamiliar.
If it does not work
The row appears but the request fails. Rockxy captured it and then could not forward. Re-check the upstream host and port against System Settings, and confirm the corporate proxy is reachable from your machine right now (VPN up, on-network). A captured-but-failed transaction points at the upstream leg, not at Rockxy's listener.
The proxy demands credentials and requests get rejected. That is upstream authentication — a community-tier cap. Either use a credential-free proxy path or move to Pro to forward the username and password through the chain.
Your proxy is SOCKS5. SOCKS5 upstream is also gated on Free. Confirm the protocol with IT; if it is HTTP, HTTPS, or PAC you are fine on the community tier, otherwise Pro is required.
Internal hosts broke after you set the upstream. They are being forced through the corporate proxy when they should go direct. Add them to the bypass list (Step 3). If your bypass list is long and some entries seem ignored, you may be hitting the community-tier list-size cap.
An HTTPS flow stays a tunnel. That is TLS scope and trust, not the chain. Add the host to SSL Proxying scope and trust the certificate. If a host pins its certificate, Rockxy will not silently defeat that — a pinned or failed handshake is surfaced as a failed transaction in the request list so you can see it happened, rather than being decrypted.
What Rockxy does not do here
Set expectations so you do not chase things that are out of scope. Rockxy chains to an upstream proxy for traffic it captures on your Mac; it does not capture from iOS, the iOS Simulator, or Android, and it does not automate device or mobile network setup. It will not bypass certificate pinning — pinned hosts surface as failed transactions rather than decrypted flows. And on the community tier, SOCKS5 upstream, upstream authentication, and larger bypass lists are the three chaining limits that Pro lifts; everything else in the debugging workflow is free.
Next steps
The rule is short: on a mandatory-proxy network, do not fight egress — chain into it. Point Rockxy's upstream at the corporate proxy or its PAC file, bypass the internal hosts that must go direct, and your captured request completes through the company's own path.
From here, add HTTPS decryption with the HTTPS on macOS guide, handle self-hosted upstreams and binary WebSocket frames in the upstream proxy and WebSocket Protobuf guide, or fix the more common case where nothing shows up at all in why localhost traffic is not captured. The full upstream and bypass reference lives in the Rockxy docs.
