Locked-down corporate networks typically deny all outbound traffic except to allowlisted destinations, and inspect anything arriving from outside. To make Claude usable behind that kind of perimeter, Anthropic publishes fixed IP ranges and states they "will not change without notice" — stable enough to put in firewall rules. There are two distinct ranges, and mixing up which one goes where is the most common mistake in this setup.
The two ranges and their directions
| Direction | Traffic | Range |
|---|---|---|
| Inbound to Anthropic | Your API calls to the Claude API | 160.79.104.0/23 (IPv4), 2607:6bc0::/48 (IPv6) |
| Outbound from Anthropic | Claude's tool calls to your systems (MCP servers, web search, web fetch) | 160.79.104.0/21 |
Inbound here means traffic arriving at Anthropic: when your application calls the Claude API, your egress firewall needs to allow connections to 160.79.104.0/23 (and the IPv6 block if you route v6). That rule replaces a fragile hostname allowlist for api.anthropic.com.
Outbound is the direction people forget. When a Claude request uses the web fetch tool, web search, or the MCP connector to reach a server you host, the connection originates from Anthropic's infrastructure and arrives at your perimeter. If your MCP server sits behind an ingress allowlist, the source addresses to permit come from the broader 160.79.104.0/21 block. (Arithmetically, the /21 contains the /23 — the outbound pool is the wider slice of the same address space.)
160.79.104.0/21. Check that before debugging the application.Retire the legacy 34.162.* addresses
Earlier documentation listed five individual 34.162.* /32 addresses for outbound traffic. These are being phased out and should be removed from allowlists. Keeping dead entries costs little day to day, but stale firewall rules are exactly the kind of cruft that fails a network review — and if your rules list only the legacy /32s without the current /21, tool calls will start failing as those addresses are decommissioned. Audit now rather than during an incident.
Claude Platform on AWS: the split is different
If you use Claude Platform on AWS — Anthropic's own service fronted by AWS infrastructure — the picture changes on one side only:
- Your calls in: the endpoint (
aws-external-anthropic.{region}.api.aws) resolves to AWS IP ranges, not Anthropic's. For egress allowlisting, use AWS's published IP ranges — or skip public egress entirely, since the platform supports AWS PrivateLink for a private VPC path. - Claude's calls out: tool calls (MCP, web search, web fetch) still originate from the Anthropic ranges above, so your ingress rules for those don't change.
Bedrock, Vertex AI, and Foundry are cloud-operated services with their own network controls — endpoint addressing there follows each cloud's model (see Bedrock's network controls and the private-networking overview) rather than Anthropic's published ranges.
What these ranges do not give you
Two controls that network teams often ask for are, per the current documentation, not offered on the first-party Claude API: customer-configurable inbound IP allowlisting (restricting which source IPs may use your organization's API keys) and private or VPC endpoints to api.anthropic.com. The documented controls are Anthropic's published ranges for your own firewall, plus PrivateLink on the Claude Platform on AWS variant. If key misuse from unexpected networks is the threat you are defending against, the stronger tools are short-lived credentials via Workload Identity Federation and tight workspace scoping, not source-IP rules.
Where to go next
Pair this with the private-connectivity comparison across platforms, or start at the deployment checklist for the full network-review sequence.