HTTP_PROXY, HTTPS_PROXY, and NO_PROXY on macOS: Why Your Proxy Variables Don't Work

You export HTTP_PROXY and HTTPS_PROXY, point them at your debugging proxy on macOS, and rerun your client. The request still returns a normal 200 — but nothing shows up in Rockxy. The variables are set, env confirms it, and yet the proxy stays empty.

This is one of the most confusing parts of the proxy environment variables, because they look like a standard the whole system obeys. They are not. They are a loose convention that each client reads — or ignores — on its own terms. Case, a stray NO_PROXY entry, or a library that never consults them at all can each quietly defeat the setup. The outcome of this guide is a captured request: after understanding what these variables actually control, your traffic shows up in Rockxy with full method, URL, headers, body, response, and timing.

What the proxy environment variables actually are

There is no macOS-wide switch called "the HTTP proxy environment." HTTP_PROXY, HTTPS_PROXY, NO_PROXY, and ALL_PROXY are a de-facto convention that many command-line tools and HTTP libraries agreed to read. The operating system does not enforce them; each client decides whether to look at them, which spellings to accept, and how to interpret the exclusion list. That is the root of most "my proxy variables don't work" reports — the assumption that setting them once configures everything.

Three quirks account for nearly every failure:

1. Case matters, per client. Some tools read only lower-case (http_proxy, https_proxy, no_proxy), some read only upper-case, and some prefer one over the other. A well-known wrinkle: for HTTP_PROXY specifically, several libraries deliberately ignore the upper-case form to avoid a CGI header-spoofing issue, and only honor lower-case http_proxy. Setting both spellings is the safe move.
2. NO_PROXY silently drops your host. If the target hostname matches an entry in NO_PROXY / no_proxy — often inherited from a shell profile, a corporate setup, or a .env file — the client connects directly and skips the proxy. There is no error and no warning; the row just never appears.
3. Not every client reads them at all. Plenty of HTTP stacks ignore these variables entirely and require an explicit in-code proxy option instead. GUI apps are the sharpest case: an app you launch from Finder or the Dock does not inherit the exports you typed in a shell, so it never sees them.

The reliable pattern is the same one experienced debuggers reach for: configure one specific client explicitly, and treat the environment variables as a convenience that some tools happen to support. Rockxy is a local proxy on your Mac, so routing traffic to it is a matter of client configuration, not a system-wide toggle.

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 set the variables for one run and inspect them.
• A target URL you want to capture — an external HTTPS endpoint is easiest to start with, because loopback has its own separate rules (covered below).
• The proxy port Rockxy is listening on, shown in its toolbar. The examples below use 8888; use whatever value Rockxy shows.

Step 1 — Confirm Rockxy is capturing and read its proxy port

Start Rockxy and make sure capture is enabled. Read the active proxy port from the toolbar. Then send one request through that port with an explicit flag — bypassing the environment variables entirely — so you have proof the listener is alive before you trust any export:

curl -x http://127.0.0.1:8888 --noproxy "" https://api.github.com/zen

What you should see in Rockxy: a new row for api.github.com. If even this does not appear, the proxy port is wrong or capture is off. Fix that first — no environment-variable adjustment will help until the listener itself receives traffic.

Step 2 — Reproduce the failure with the variables set

Now do the thing that fails, so you can watch it fail. Set the variables the way most guides tell you to, and run a request through a client that reads them:

export HTTP_PROXY="http://127.0.0.1:8888"
export HTTPS_PROXY="http://127.0.0.1:8888"

curl https://api.github.com/zen

If the request succeeds but no row appears in Rockxy, one of the three quirks is in play. The most common culprit is an inherited NO_PROXY. Check what your shell actually holds:

env | grep -i proxy

A line like no_proxy=localhost,127.0.0.1,.internal,github.com is enough to send your target straight past the proxy. Confirming the miss now, and seeing exactly which variables are set, means you can trust the fix in the next step.

Step 3 — Set both cases and clear NO_PROXY for the run

Set the lower-case and upper-case spellings together, and clear the exclusion list so nothing is quietly dropped. Doing this in a single command scopes it to that one process, so you are not permanently altering your shell:

HTTP_PROXY="http://127.0.0.1:8888" \
HTTPS_PROXY="http://127.0.0.1:8888" \
http_proxy="http://127.0.0.1:8888" \
https_proxy="http://127.0.0.1:8888" \
NO_PROXY="" no_proxy="" \
  curl https://api.github.com/zen

Three things are happening. Setting both cases covers clients that only read one spelling. Clearing NO_PROXY and no_proxy removes any inherited exclusion that would skip your host. Scoping the variables to the command keeps the change reproducible and disposable. If your tool also honors ALL_PROXY, set it to the same value — it acts as a fallback when the scheme-specific variables are absent.

For a script rather than a one-liner, export the same set at the top of the run:

export HTTP_PROXY="http://127.0.0.1:8888"
export HTTPS_PROXY="http://127.0.0.1:8888"
export http_proxy="http://127.0.0.1:8888"
export https_proxy="http://127.0.0.1:8888"
export NO_PROXY=""
export no_proxy=""

# run your client here — e.g. a Node, Python, or Go script

What you should see in Rockxy: a new row for the request, with the full method, URL, request headers your client sent, and the response. If it appears now but did not in Step 2, an inherited NO_PROXY or a case mismatch was the cause.

Why explicit per-client config is the reliable choice

Environment variables are a convenience, not a contract. Because each library decides for itself whether to read them, the outcome is inconsistent across a real stack: one service honors them, another silently ignores them, a third reads only https_proxy and not HTTPS_PROXY. When a client refuses to cooperate through the environment, the dependable answer is an explicit in-code proxy option — a proxy argument on the request, or a client-level proxy setting — pointed at Rockxy's port. That configuration is visible in your code, survives a GUI launch, and does not depend on what the shell happened to inherit.

The framework-specific setups are covered in the Node.js and Python guides. Both show the in-code proxy option alongside the environment approach, so you can pick whichever your client actually respects.

HTTPS: pointing a client at the certificate

Once the request routes through the proxy, an HTTPS target needs one more thing to be readable: the host must be inside Rockxy's SSL Proxying scope, and the client must trust Rockxy's certificate. Many command-line clients and libraries do not use the macOS keychain; they read a CA bundle from a file, and some of them read that path from their own environment variable. For those clients, point them at Rockxy's exported root certificate rather than expecting system trust to apply.

The exact variable name differs by client and is not part of the HTTP_PROXY family — check your tool's documentation for whether it reads a CA bundle path. The certificate export and trust steps live in the certificates and trust docs.

What you should see in Rockxy: for a decrypted HTTPS request, the selected flow shows a readable request and response body. If instead you see a CONNECT or tunnel-only row, the proxy path exists but decryption did not happen — enable HTTPS decryption for that host and confirm the client trusts the certificate. The mechanics are covered in How to Debug HTTPS Traffic on macOS.

If it does not work

The variables are set but no row appears. Run env | grep -i proxy and look for a no_proxy that lists your target host or a wildcard that matches it. Clear it for the run. Also set both the lower-case and upper-case spellings, since some clients read only one.

It works with -x on curl but not through the variables. The client you are actually running does not read these variables. Use its explicit in-code proxy option instead — an environment variable cannot force a library that never checks for one.

A GUI app ignores everything you exported. An app launched from Finder or the Dock does not inherit a shell's exports. Configure the proxy inside the app's own settings, or launch it from the same terminal session where the variables are set so it inherits them.

Loopback traffic still skips the proxy. Requests to localhost and 127.0.0.1 have their own bypass rules that these variables do not override, because loopback is often excluded by default. That case has its own fix — see Why Localhost Traffic Isn't Showing in Your Proxy on macOS.

A tunnel row appears but the HTTPS body is unreadable. That is TLS, not routing. Add the host to SSL Proxying scope and make sure the client trusts Rockxy's certificate path. If the server 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.

Limitations to keep in mind

Whether a client reads HTTP_PROXY and friends is a property of that client and its HTTP stack, not something Rockxy can force. Rockxy listens on its port and captures whatever is sent there; it cannot reach into a library and make it honor an environment variable it was never written to read. When a tool ignores the variables, the answer is always the client's own explicit proxy configuration.

Keep the scope in mind too: the widely-standard names are HTTP_PROXY, HTTPS_PROXY, NO_PROXY, and ALL_PROXY (with their lower-case twins). Any other proxy or certificate variable is client-specific — do not assume a name until your tool's docs confirm it.

Inspect the captured flow with your AI assistant (optional)

Once the request is captured, you can let an MCP-capable AI tool read it directly instead of pasting terminal output into a chat. Rockxy ships a built-in local MCP server that exposes read and replay tools — list_flows, get_flow_detail, replay_request, and diff_flows — so an assistant like Claude or Cursor can ask "which proxy variables did that request actually use?" against the real capture.

Local MCP is 100% free and unlimited in the Free tier. No license upgrade required. The workflow is local-first and user-controlled: Rockxy's MCP server binds to localhost, and captured data stays in a local store on your Mac. Rockxy itself never uploads your traffic to an AI provider. If you enable the workflow, the assistant you connect may include the data it retrieves in its own prompts — that is your choice to make per tool. Setup is in the Connect Claude Desktop to Rockxy guide.

Next steps

The short version: the proxy environment variables are a convention, not a system setting. Set both cases, clear NO_PROXY for your host, and fall back to an explicit in-code proxy option whenever a client refuses to read them. Once a request lands in Rockxy, every harder question has far fewer places to hide.

From here, wire it into your real stack with the Node.js or Python setup guide, handle the loopback case in Why Localhost Traffic Isn't Showing in Your Proxy on macOS, move to HTTPS on macOS when you need decrypted bodies, or read the traffic capture docs. If capture behaves oddly in general, the FAQ covers the most frequent setup questions.