Proxies for Claude Code: The Scrapers You Build, the Corporate Proxy It Documents, and What an IP Never Does

Claude Code is Anthropic's agentic coding tool: a command-line assistant, also shipped as the Claude Agent SDK, that reads your codebase, writes and edits files, runs commands, and builds software from a plain-English brief. More and more of what people build with it touches the open web at scale, a scraper for a research project, a price monitor, a crawler feeding a dataset, a browser agent that fills forms and clicks through flows. And the moment that code runs, it meets the same walls every scraper meets, and it needs proxies.

That is the honest shape of "proxies for Claude Code", and it is three separate questions wearing one name. The big one is the code Claude Code writes for you, which is where a proxy genuinely earns its place. The second is routing Claude Code's own connection to Anthropic through a proxy, which Claude Code documents and which matters in two narrow situations. The third is the pile of things a proxy is imagined to do and never does. We run a proxy network and we build with Claude Code every day, so here is the version with no sales gloss.

The three questions, kept apart

Getting these confused is how people buy the wrong thing, so the table first.

The big one: the code Claude Code writes for you

This is why most developers reach this page. You ask Claude Code to build a scraper, a competitor-price watcher, a review harvester, a browser agent that logs into a dashboard and pulls a report, or a data-collection run that feeds a model. Claude Code writes it, and it works against one site from your own IP. Then you point it at a hundred pages, or a defended target, or a schedule, and the failures start: rate limits, then CAPTCHAs, then a block. That is not a bug in the code Claude Code wrote. It is the target metering and fingerprinting the single address the code runs from, exactly as it would for any scraper a human wrote.

The fix is the same as it has always been, and it lives in the code, not in Claude Code. Route the requests through proxies so the target sees many ordinary addresses instead of one machine hammering it. Which type depends on the target, and the choice is the ordinary one:

• Defended sites read at volume (retail, search, social, travel, anything with a real bot team): rotating residential proxies, because they read as home users and Google, Amazon and the rest burn datacenter ranges fast. The fundamentals are in proxies for web scraping.
• Anything with a login or a multi-step session: one sticky residential or ISP address held for the task, because a mid-session IP change reads as a hijack. This is the pattern for the browser agents people build, covered in proxies for AI agents and proxies for browser-use.
• Friendly APIs and open data: cheap datacenter is fine and faster.
• Collecting a dataset or corpus at scale: a mix, detailed in proxies for LLM scraping and proxies for AI training data.

The genuinely useful move is to tell Claude Code the proxy setup you want, so it writes it in from the start rather than bolting it on after the first block. Claude Code writes idiomatic proxy handling in whatever language you are in, and our library guides are the reference for the exact code it should produce: Python requests, httpx, aiohttp, Playwright, Puppeteer, Scrapy, Selenium, Node.js and Go. Paste the one that matches your stack into the chat, and Claude Code will match it.

A prompt that works: give Claude Code the gateway endpoint and ask it to route every outbound request through the proxy, honour a retry with backoff on a block, and rotate the exit per request for stateless fetches or hold one sticky exit for a logged-in flow. That is the whole integration, and it is the code's job.

The second question: routing Claude Code itself

Claude Code also lets you route its own traffic, the connection it makes to the Anthropic API, through a proxy. Its enterprise network documentation is explicit about how: it respects the standard environment variables, read once at startup.

# Claude Code reads these; https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY, first one set wins
export HTTPS_PROXY=http://username:password@host:port
export NO_PROXY="localhost,127.0.0.1"

That basic-auth form, http://username:password@host:port, is exactly the shape an HProxy gateway uses, so an HProxy endpoint drops straight in. One documented limit matters when you choose a product: Claude Code does not support SOCKS proxies, so use an HTTP or HTTPS endpoint, which is what our gateways speak. You can also set the variables in the env block of settings.json, which the docs note is the only way to reach background agents reliably.

Now the honest part, because this is where a proxy company could mislead you. Routing Claude Code's own connection matters in exactly two situations, and neither is about hiding from Anthropic:

1. A corporate network that requires a proxy. If your company forces all traffic through a proxy, that is your company's proxy, an IT-managed egress, not one you buy from us. Claude Code supports it, along with custom CA certificates and mTLS for TLS-inspecting proxies like Zscaler, and that is the right tool for that job. We are not that product, and we will say so.
2. Reaching Anthropic from a network or country where it is blocked. Anthropic serves Claude in a defined set of countries and excludes some, and some networks filter api.anthropic.com outright. Here a static residential or ISP exit in a supported country, set as HTTPS_PROXY, can let Claude Code connect where the network is the only obstacle. This is the same reachability case we describe for Claude AI, and it is a decision to read against Anthropic's usage policy and supported-countries list first.

What routing Claude Code's own traffic does not do is give you a reason to hide your address from Anthropic. It is your account and your key; there is nothing to conceal, and a residential IP in front of your own authenticated API calls buys you nothing. Anyone selling you a proxy for that is selling you air.

MCP servers that fetch the web

Claude Code connects to MCP servers, the tools that extend what it can do, and a growing number of them fetch web data: a server that scrapes a site, checks prices, pulls search results or reads public pages. Those servers make ordinary HTTP requests to ordinary websites, so they hit the same bot walls and per-IP rate limits as any scraper, and they need residential proxies in exactly the same places. The proxy goes in the MCP server's own HTTP client, configured the same way as any scraper in that language, not in Claude Code. An MCP server that only talks to a private API or your own database needs nothing. If you are building or running fetch-heavy MCP servers, proxies for MCP servers covers where the proxy goes, and if you are building agents on the Claude Agent SDK rather than the CLI, proxies with the Claude Agent SDK covers the tool-level placement.

What a proxy never does for Claude Code

Three misconceptions, stated plainly so nobody buys on them.

It does not make Claude Code cheaper. Cost is a function of the model, the effort setting and how much context each request carries, and prompt caching is the real lever. An IP address is not part of the bill.

It does not raise your usage limit. Claude Code's limits are counted against your Anthropic account or subscription, and that quota follows your credential, not the address the packet came from. Sending the same key through a thousand addresses is a thousand requests against one limit, the rule we set out in LLM API rate limits and proxies.

It does not change what Claude Code will do. The model's behaviour and Anthropic's usage policy are the same wherever the request comes from. A proxy is a network tool, not a permission.

Setting it up

For the code you build, the proxy lives in that code, and the library guide for your stack has the exact lines; tell Claude Code the endpoint and let it write them. For Claude Code itself, export HTTPS_PROXY in the form above before launching, or put it in settings.json, and confirm the exit first with our proxy checker so you know it reports the country you expect. Remember the two limits from the docs: no SOCKS, and the variables are read at startup, so restart Claude Code after changing them.

Where HProxy fits

For the scrapers, crawlers, monitors and browser agents you build with Claude Code, our residential pool from $0.44/GB is the workhorse for defended targets, with ISP addresses at $2.70/IP per month for anything that has to hold a session, both metered as you go with no KYC. For the narrow case of reaching Anthropic from a network that blocks it, one static exit in a supported country does the job. Confirm any exit with the free proxy checker, and size the order from the bandwidth your scrape actually moves rather than a round number.

For the corporate-proxy passthrough and the "make it cheaper" hopes, the honest answer is that those are not us, and we would rather tell you than sell you the wrong thing. Build the scraper, proxy the code, and Claude Code becomes the fastest way to ship data collection that actually survives contact with a defended site.

Sources

• Claude Code documentation, Enterprise network configuration: the HTTPS_PROXY / HTTP_PROXY / NO_PROXY variables and their precedence, the http://username:password@host:port basic-auth form, the statement that Claude Code does not support SOCKS proxies, custom CA and mTLS support for TLS-inspection proxies, the settings.json env block for background agents, and the network-access allowlist including api.anthropic.com.
• Anthropic, supported countries and usage policy: where Claude and its API are offered, and the terms that govern access.
• HProxy, proxies for web scraping and the library guides linked above, for the code Claude Code should write.