Every official Claude SDK sits on top of a standard HTTP stack for its language — the Java SDK's primary client class is literally named AnthropicOkHttpClient, after the OkHttp library it builds on. That layering is deliberate: when your network team requires an outbound proxy, a custom certificate authority, or connection-level tuning, you configure the HTTP layer rather than forking the SDK. This article covers the three customizations enterprises actually ask for, and the escape hatches when you need less machinery than a custom transport.
The three common requests
Proxies. Most corporate environments route outbound traffic through an HTTP(S) proxy. Every mainstream HTTP stack — Python's, Node's, OkHttp, .NET's, Go's — supports proxy configuration, typically via standard environment variables or an explicit proxy setting on the underlying client. Because the SDKs delegate to these stacks, proxy support comes along for free; the SDK-specific question is only how to hand your configured HTTP client to the SDK constructor, which each repository's README documents for its language.
Custom trust stores and certificate pinning. If your organization runs TLS inspection, the SDK's HTTP client must trust your internal CA; if you pin certificates, you constrain which certificates it accepts. Both are HTTP-stack concerns, configured exactly as you would for any other outbound API client in that language. One caution: pinning against a managed API endpoint means the provider can rotate certificates on their schedule, not yours — pin thoughtfully and have a rotation plan, or pin to your own egress gateway instead (see below).
Custom transports and middleware. Some SDKs expose formal middleware or transport-injection points. The PHP SDK, for example, documents a middleware pipeline in which platform-specific behavior — OAuth token refresh, Bedrock and Vertex request signing — runs inside the innermost middleware, with your middleware wrapping around it. The exact mechanism differs per language, and the fact sheets this guide is built on do not include copy-paste snippets for each one, so treat the official repositories as the source of truth: Python, TypeScript, Java, Go, and PHP.
Often you don't need a custom transport at all
Two simpler mechanisms cover a surprising share of "customize the HTTP client" requests.
Base URL override. If the goal is to route traffic through an internal gateway, a logging proxy, or a local test server, pointing the SDK at a different host is usually enough. The ant CLI and the SDKs honor ANTHROPIC_BASE_URL (the CLI also takes --base-url), and the gateway then owns the network policy centrally — one place to configure proxies, TLS, and audit, instead of one per service. See Overriding the Base URL in the SDK.
Private connectivity on the platform side. On Claude Platform on AWS, AWS PrivateLink is supported for connecting your VPC to the endpoint — traffic stays on private networking without any SDK-side transport work. If your motivation for a custom transport is "our traffic must not traverse the public internet," check what your platform offers before writing code.
A quick decision table
| Requirement | Reach for |
|---|---|
| Route via corporate proxy | HTTP stack's standard proxy settings / env vars |
| Trust an internal CA (TLS inspection) | Language trust-store configuration |
| Central routing, logging, policy | Base URL override to an internal gateway |
| Private network path on AWS | PrivateLink with Claude Platform on AWS |
| Per-request header or body manipulation | SDK middleware/transport hooks (per repo README) |
Whatever you customize, verify with a real call afterward — transport changes fail in ways unit tests do not catch, and a misconfigured proxy or trust store typically surfaces as connection errors or TLS failures only against the live endpoint.
Where to go next
Start with the base URL override article if a gateway solves your problem, or SDK setup for Claude Platform on AWS for the SigV4 path. The platform overview compares connectivity options across clouds.