Claude Code 403 Errors: Region, Gateway, TLS, or Sign-in?

A Claude Code HTTP 403 does not, by itself, prove that your account is banned. Use Claude Code 2.1.318 or later to include the diagnostic, gateway, and certificate fixes covered here. Then follow the matching error branch instead of repeatedly signing in.

The 2.1.317 release notes distinguish region or network blocks from sign-in failures. The 2.1.318 release notes add certificate-file recovery and clearer handling of expired stored logins. These changes help identify failures; they do not remove access restrictions or repair every gateway configuration.

Start with the fixed version and one small request

As of 2026-11-10, 2.1.318 is the minimum combined version for these fixes, not a claim about the latest release. Individual fixes first appeared in the versions below.

Symptom	First release containing the relevant fix	First check
A region or network HTTP 403 appears as a sign-in failure	2.1.317	Read the block explanation and identify the responding service
VS Code opens its sign-in screen after a region or network block	2.1.317	Retry in the affected VS Code interface
Auto mode fails every turn when a Base URL gateway rejects its safety check with 403 or 422	2.1.317	Compare Manual and Auto; the apiKeyHelper 403 exception remains
unable to get local issuer certificate after a TLS-inspecting proxy renews its root certificate	2.1.317	Check the approved certificate chain and client version
An empty, non-PEM, or damaged-first-certificate NODE_EXTRA_CA_CERTS file breaks connections	2.1.318	Repair the certificate file and inspect startup warnings
A required Claude apps gateway cannot be reached	2.1.317	Check its network path and certificate trust
A stored claude.ai login reaches its time limit	2.1.318	Renew the active login rather than changing the network

In Bash, inspect the CLI you actually use:

claude --version
claude auth status

The CLI reference documents claude auth status as an authentication-status report. Treat it as evidence about the configured authentication state, not proof that inference works.

Use your installation’s supported update method. For a native installation, run:

claude update
claude --version

Follow the installation and update instructions for package-manager or centrally managed installations. Confirm the printed version meets the required floor. Retry in the interface that failed; a successful terminal test does not establish that the VS Code path works.

Next, send one small request from the same Bash environment:

claude -p 'Reply with exactly OK. Do not use tools.'

The expected result is OK without a connection or authentication error. This checks a basic model request. It does not test auto mode’s review path or establish compatibility with every feature.

A region or network block is not an expired login

Investigate the network or access decision when the error identifies a block. Reauthentication is not the first remedy for that symptom.

The 2.1.317 changelog states:

Fixed a region or network block (HTTP 403) being shown as a sign-in failure; the error now explains the block

The same release separately fixes VS Code opening its sign-in screen for this condition. Neither entry says that updating grants access to a blocked request.

Start Claude Code and run /status. Check the active route and credential source using the gateway connection instructions. Establish whether the request targets Anthropic directly or your configured gateway before investigating the account.

For a corporate network, have IT check the proxy settings used by the affected process, including HTTPS_PROXY and HTTP_PROXY. The network configuration guide documents those variables. For a confirmed region block, confirm service availability with the provider rather than repeatedly renewing credentials.

Keep the response body, destination hostname, timestamp, and request ID when available. Do not send environment dumps, credentials, or full prompts in a support ticket.

A separate account-hold notice belongs in the account-support branch. Anthropic’s error reference identifies that condition as a suspended account. A different possibility is missing model access: the installation and authentication guide documents 403 errors after successful authentication when the account cannot use the requested model.

The verification step is another small request through the intended, approved route. If it still returns 403, use its current explanation and provider records to identify the denial. Do not infer an account ban from the status code alone.

Auto mode fails every turn through a gateway

Investigate the safety-check path when Manual works but Auto repeatedly fails through the same gateway. The 2.1.317 fix has a specific scope:

Fixed auto mode failing every turn when an LLM gateway set as the base URL answers 403 or 422 to its server-side safety check (a 403 with an apiKeyHelper is unchanged)

The parenthetical matters. A 403 while apiKeyHelper is active is not covered by this change. Have the gateway owner check the credential and authorization path without exposing the helper’s secret output.

The gateway compatibility guide identifies an anthropic-beta value and a safeguards request field for server-side review. A gateway’s rejection of that capability needs different investigation from a rejected credential. The status code alone cannot establish which happened.

Compare two sessions in a trusted Git checkout. Keep the model, endpoint, credentials, and task unchanged.

Start claude --permission-mode default. Ask Claude to run git status --short using Bash and report the result without changing files. Approve a permission prompt if one appears.

Exit that session, then start claude --permission-mode auto and repeat the task. Confirm the requested mode is active using the permission-mode controls. A session that did not enter Auto is not a successful Auto comparison.

If only the Auto session fails, match its failing request to gateway records. Ask the gateway operator to inspect the rejection against the compatibility guide. This comparison narrows the investigation; it does not prove the exact gateway rule responsible.

With your administrator’s approval, a temporary diagnostic can select Claude Code’s own classifier requests instead of server review:

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

The environment-variable reference documents this switch. It changes where review happens; it does not turn permission checking off. The classifier still makes model requests, so inspect request usage and latency before keeping the override.

If this session works while ordinary Auto fails, investigate server-review compatibility. If both fail, investigate the reported credential, model, or gateway error rather than assuming this fix applies.

For the billing distinction, see server-side classifier billing and fallback behavior. Do not treat the separate classifier path as an offline or necessarily free fallback.

Fix certificate trust, not authentication

Treat unable to get local issuer certificate as a certificate-trust problem. It is a different failure layer from an HTTP authorization response.

The 2.1.317 changelog states:

Fixed API requests failing with “unable to get local issuer certificate” behind some TLS-inspecting proxies after a root certificate renewal

This fix covers the stated renewal problem. It does not establish that every issuer-certificate error has that cause.

First confirm the client version. Then ask IT whether the proxy’s root certificate changed and which certificate-authority bundle the client should trust. Use an approved PEM bundle rather than a certificate copied from an unverified source.

When your environment requires a custom bundle, save the IT-provided file as $HOME/company-ca.pem. Launch a new Claude Code process from the same Bash shell:

export NODE_EXTRA_CA_CERTS="$HOME/company-ca.pem"
claude -p 'Reply with exactly OK. Do not use tools.'

This follows the documented custom CA configuration. The example path is a local filename you choose; the certificate contents must come from your organization.

The success check is a completed request without the issuer-certificate error. If it still fails, ask IT to check the supplied bundle and the certificate chain presented through the proxy.

Do not set NODE_TLS_REJECT_UNAUTHORIZED=0. Anthropic’s certificate-error guidance warns that this disables certificate validation.

Empty or damaged NODE_EXTRA_CA_CERTS files

Use 2.1.318 or later when the extra-CA file itself is malformed. Its changelog states:

Fixed every connection failing when the NODE_EXTRA_CA_CERTS file is empty, not PEM, or starts with a damaged certificate: readable certificates are now used, with a warning on stderr

Inspect warnings as well as the final connection result. The fix uses readable certificates; it does not repair the file or supply a missing certificate required by your proxy.

Replace an empty or damaged bundle with the approved PEM file. Remove an unintended NODE_EXTRA_CA_CERTS setting only after confirming that the environment does not require it. Then start a new process and repeat the small request.

If a request succeeds but the certificate-file warning remains, repair the bundle before treating the configuration as finished.

A required Claude apps gateway cannot be reached

Restore connectivity to the required gateway before changing a working login. The 2.1.317 entry says:

Improved the startup error when a required Claude apps gateway can’t be reached: it points to the network instead of a sign-in, and says when the gateway’s TLS certificate can’t be verified

This entry concerns a required Claude apps gateway. Do not automatically apply it to every third-party ANTHROPIC_BASE_URL endpoint.

Give the gateway administrator the affected hostname and sanitized error. Ask them to check service reachability, DNS, proxy policy, and certificate trust. If the message identifies certificate verification, follow the CA branch rather than resetting credentials.

Verification happens in two stages: Claude Code must get past the gateway startup failure, then complete the small model request. A subsequent authentication error is a separate result to investigate.

Renew a login only when that credential has expired

Renew the stored claude.ai login when the error identifies its expiry. The 2.1.318 release notes distinguish this from the network-block case:

Fixed the sign-in failure when a stored claude.ai login reaches its time limit: it now says so, and in claude -p names claude auth login and claude setup-token

For an interactive workflow that should use your claude.ai login, run these commands in Bash:

claude auth login
claude auth status
claude -p 'Reply with exactly OK. Do not use tools.'

Complete the sign-in before continuing to the status check and request. The expected result is the intended authentication state followed by a successful response.

The release also names claude setup-token for headless recovery. Follow the authentication guidance for that workflow rather than embedding a token in a script.

A gateway-issued credential needs recovery through its issuer. Signing in to claude.ai is not a test of that credential. If a renewed login still produces a region, network, or gateway error, return to that branch instead of repeating the login loop.

Verify ANTHROPIC_BASE_URL and the active credential

Verify the route inside the failing session before changing more settings. The connection guide recommends /status to inspect the effective Base URL and credential source.

Use the gateway’s documented Anthropic-compatible base address. The protocol guide associates ANTHROPIC_BASE_URL with the Anthropic Messages format and /v1/messages. Do not copy an OpenAI-compatible URL into this configuration without checking the protocol. The Base URL and endpoint troubleshooting guide explains that distinction.

Match the credential variable to the gateway’s required header. Anthropic documents ANTHROPIC_AUTH_TOKEN as an Authorization: Bearer credential and ANTHROPIC_API_KEY as an X-Api-Key credential. Follow the gateway’s instructions instead of putting one credential into every available variable.

For an existing BetterToken API route, its Claude Code instructions use https://bettertoken.ai, without /v1, and ANTHROPIC_AUTH_TOKEN. Its catalog lists claude-sonnet-5-5 as of 2026-11-10. This is separate API access, not a Claude subscription or a guarantee that every Claude Code feature works.

When the effective route differs from your intended configuration, follow how to verify Claude Code’s active provider. Match one small request to the intended provider’s records, then repeat the specific operation that failed. A basic reply is sufficient for a basic connection check; an Auto-mode incident also needs the Auto comparison to succeed.