Claude Desktop HTTP Proxy: 3 Layers to Configure (2026)

Claude Desktop does not have its own proxy settings page. The app follows the operating system's proxy configuration on macOS and Windows, can be forced through a specific HTTP proxy with a Chromium-style launch flag, and any MCP servers it starts need their own proxy environment variables. This guide covers all three layers, in the order that saves the most time.

What "Claude Desktop HTTP proxy" actually involves

Claude Desktop is an Electron application. That single fact explains most of the behaviour people run into:

Network requests from the app window go through Chromium's network stack, which resolves its proxy from the OS, not from shell variables.
MCP servers (the local tools you add in claude_desktop_config.json) run as separate child processes. They inherit nothing from the app's proxy decision and must be configured on their own.
The API endpoint is fixed. Unlike Claude Code or an SDK, the desktop app has no base URL setting. A proxy can carry its traffic, but it cannot redirect the app to a different backend.

If your real goal is to point Claude at a relay or gateway endpoint, that is a Claude Code or SDK job. See Claude Code Proxy: Gateway or Corporate Proxy and Claude API Proxy: How It Works. The rest of this article is about getting the desktop app itself through an HTTP proxy.

Layer 1: the operating system proxy

This is the route that works for most people and requires no flags.

macOS. Open System Settings, go to Network, select the active connection, open Details, then Proxies. Enable "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)" and enter the host and port. Quit Claude Desktop completely (Cmd+Q, not just closing the window) and relaunch it. Electron reads the proxy at startup.

Windows. Open Settings, go to Network & Internet, then Proxy. Either turn on "Use a proxy server" under manual setup or point "Use setup script" at your PAC file. Restart the app afterwards.

Linux. Chromium-based apps generally honour the desktop environment's proxy setting, and fall back to the http_proxy, https_proxy and no_proxy environment variables when no desktop setting exists. Launch the app from a shell where those variables are exported and confirm the behaviour on your distribution, because it varies.

A quick sanity check: if a browser on the same machine reaches the web through the proxy but Claude Desktop does not, the app was probably started before the setting changed. Fully quit and relaunch before investigating anything else.

Layer 2: forcing a proxy with a launch flag

When you need the app on a proxy that the rest of the system should not use, Electron accepts the standard Chromium switches:

# macOS example: launch with an explicit HTTP proxy
open -a Claude --args --proxy-server=http://127.0.0.1:7890

# Windows example (PowerShell), adjust the install path
& "$env:LOCALAPPDATA\Programs\Claude\Claude.exe" --proxy-server=http://127.0.0.1:7890

Useful companions:

--proxy-bypass-list="localhost;127.0.0.1;*.internal" keeps local addresses direct.
--proxy-pac-url= points the app at a PAC script instead of a fixed host.

Two caveats. First, flags apply only to that launch; if the app is opened from the Dock or Start menu later, it goes back to the OS setting. Create a shortcut or small launcher script if you need it every time. Second, a proxy that requires a username and password will trigger an authentication prompt inside the app, and some corporate proxies that only accept NTLM or Kerberos will not negotiate cleanly this way. In that case, a local forwarding proxy that handles authentication is the usual workaround.

Layer 3: MCP servers need their own proxy variables

This is the layer that catches people after the chat window is already working. A tool server that fetches web pages, calls an API or installs packages at startup runs as its own process. Set proxy variables inside its env block:

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"],
      "env": {
        "HTTP_PROXY": "http://127.0.0.1:7890",
        "HTTPS_PROXY": "http://127.0.0.1:7890",
        "NO_PROXY": "localhost,127.0.0.1"
      }
    }
  }
}

The configuration file lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Restart the app after editing; the file is read when servers are spawned.

Whether a given server respects these variables depends on its language and HTTP library. Most Node and Python HTTP clients do, but not all. If a server still fails, run the same command by hand in a terminal with the variables exported and read its error output directly.

Verifying that traffic is actually going through the proxy

Do not trust the absence of an error. Confirm it from the proxy side:

Watch the proxy's connection log while you send a message in Claude Desktop. New connections to Anthropic's hosts should appear within a second or two.
Temporarily stop the proxy. If the app keeps working, it is not using the proxy.
For MCP servers, trigger a tool call that fetches something external and watch for the server process's connections in the same log.

Common failure modes

TLS interception. Proxies that re-sign HTTPS traffic require their root certificate to be trusted at the operating system level. Electron uses the OS trust store on macOS and Windows, so install the certificate there, not in a browser profile. Symptoms are certificate errors or a blank response rather than a clear "proxy" error.

Streaming breaks. Responses arrive as a stream. Some proxies buffer the whole response before forwarding it, which looks like the app hanging and then dumping the entire answer at once. Disable response buffering for the relevant hosts if your proxy supports it.

Proxy set, nothing changed. Almost always a restart problem. Electron does not re-read proxy settings while running.

SOCKS instead of HTTP. The --proxy-server flag accepts socks5://host:port. The OS-level SOCKS setting on macOS also works for the app window, but MCP servers typically need an HTTP proxy variable, so a local HTTP-to-SOCKS bridge is often simpler.

When a proxy is the wrong tool

A proxy moves packets. It does not change which account you are billed under, which models you can call, or which backend answers. If the problem you are solving is API access from a restricted network, cost control across a team, or using Claude models from automation, the fix is at the API layer: Claude Code, the SDKs and OpenAI-compatible tools all accept a base URL, which is where a relay such as ROIBest AI fits. The desktop app is the one Anthropic client where that option does not exist.

FAQ

Does Claude Desktop have a built-in proxy setting?

No. It uses the operating system's proxy configuration by default and can be launched with Chromium proxy flags for an explicit override.

Why does Claude Desktop ignore my HTTP_PROXY environment variable?

On macOS and Windows the app reads the OS proxy settings, not shell variables. Environment variables matter for MCP server processes, and on Linux as a fallback.

Can I use a proxy to point Claude Desktop at a different API endpoint?

No. The desktop app has no base URL option. Endpoint changes are a Claude Code or SDK configuration, not a proxy setting.

Do MCP servers inherit the app's proxy?

No. Each server is a separate process. Put HTTP_PROXY and HTTPS_PROXY in that server's env block in claude_desktop_config.json.