Error 403 en Claude Code: región, gateway, TLS o inicio de sesión

Un HTTP 403 de Claude Code no demuestra, por sí solo, que tu cuenta esté bloqueada. Usa Claude Code 2.1.318 o posterior para disponer de las correcciones de diagnóstico, gateways y certificados descritas aquí. Después, sigue la comprobación correspondiente al error en lugar de iniciar sesión repetidamente.

Las notas de la versión 2.1.317 distinguen los bloqueos regionales o de red de los fallos de inicio de sesión. Las notas de la versión 2.1.318 mejoran la gestión de archivos de certificados defectuosos y aclaran los errores de sesiones guardadas que han caducado. Estos cambios ayudan a identificar fallos. No eliminan las restricciones de acceso ni corrigen cualquier configuración de gateway.

Empieza por la versión corregida y una solicitud pequeña

A fecha de 2026-11-10, 2.1.318 es la versión mínima que reúne estas correcciones, no necesariamente la versión más reciente. Cada corrección apareció por primera vez en las versiones siguientes.

Síntoma	Primera versión con la corrección correspondiente	Primera comprobación
Un HTTP 403 por bloqueo regional o de red aparece como un fallo de inicio de sesión	2.1.317	Lee la explicación del bloqueo e identifica qué servicio responde
VS Code abre la pantalla de inicio de sesión tras un bloqueo regional o de red	2.1.317	Repite la solicitud en la interfaz de VS Code afectada
Auto falla en cada turno cuando el gateway configurado como Base URL rechaza la comprobación de seguridad con 403 o 422	2.1.317	Compara Manual y Auto; se mantiene la excepción del 403 con apiKeyHelper
Aparece unable to get local issuer certificate después de que un proxy con inspección TLS renueve su certificado raíz	2.1.317	Comprueba la cadena de certificados aprobada y la versión del cliente
El archivo NODE_EXTRA_CA_CERTS está vacío, no está en PEM o empieza con un certificado dañado y provoca fallos de conexión	2.1.318	Corrige el archivo de certificados y revisa las advertencias al iniciar
No se puede acceder a un Claude apps gateway obligatorio	2.1.317	Comprueba la conexión de red y la confianza en el certificado
Caduca la sesión de claude.ai guardada en el cliente	2.1.318	Renueva la sesión activa en lugar de cambiar la red

En Bash, comprueba el CLI que realmente utilizas:

claude --version
claude auth status

La referencia del CLI describe claude auth status como un informe del estado de autenticación. Úsalo para conocer la autenticación configurada, no como prueba de que las solicitudes al modelo funcionan.

Utiliza el método de actualización admitido para tu instalación. Si tienes una instalación nativa, ejecuta:

claude update
claude --version

Para instalaciones mediante un gestor de paquetes o administradas de forma centralizada, sigue las instrucciones de instalación y actualización. Confirma que la versión mostrada alcanza el mínimo necesario. Repite la prueba en la interfaz que falló: una solicitud correcta desde el terminal no confirma que la conexión de VS Code funcione.

Después, envía una solicitud pequeña desde el mismo entorno de Bash:

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

El resultado esperado es OK, sin errores de conexión ni de autenticación. Esto comprueba una solicitud básica al modelo. No prueba el mecanismo de revisión de Auto ni confirma la compatibilidad con todas las funciones.

Un bloqueo regional o de red no es una sesión caducada

Investiga la red o la decisión de denegar el acceso cuando el error indique un bloqueo. Volver a autenticarte no es la primera solución para ese síntoma.

El registro de cambios de 2.1.317 indica, en traducción:

Se corrigió un problema que mostraba un bloqueo regional o de red (HTTP 403) como un fallo de inicio de sesión. Ahora el error explica el bloqueo.

La misma versión corrige por separado que VS Code abra su pantalla de inicio de sesión en esta situación. Ninguna de las dos entradas afirma que la actualización elimine el bloqueo.

Inicia Claude Code y ejecuta /status. Comprueba la ruta activa y el origen de las credenciales con las instrucciones de conexión al gateway. Antes de investigar la cuenta, determina si la solicitud se dirige directamente a Anthropic o al gateway configurado.

En una red corporativa, pide al equipo de TI que revise la configuración del proxy utilizada por el proceso afectado. Esto incluye HTTPS_PROXY y HTTP_PROXY, documentadas en la guía de configuración de red. Si se confirma un bloqueo regional, consulta la disponibilidad del servicio con el proveedor en lugar de renovar las credenciales repetidamente.

Conserva el cuerpo de la respuesta, el nombre del host de destino, la marca de tiempo y el identificador de la solicitud, si está disponible. No envíes volcados del entorno, credenciales ni prompts completos en un ticket de soporte.

Un aviso específico de suspensión de la cuenta requiere acudir al soporte de cuentas. La referencia de errores de Anthropic identifica ese caso como una cuenta suspendida. Otra posibilidad es que falte acceso al modelo. La guía de instalación y autenticación documenta errores 403 después de autenticarte correctamente si la cuenta no puede usar el modelo solicitado.

Para verificarlo, envía otra solicitud pequeña por la ruta prevista y aprobada. Si vuelve a devolver 403, consulta la explicación actual y los registros del proveedor para identificar el motivo del rechazo. No deduzcas que la cuenta está bloqueada solo por el código de estado.

Auto falla en cada turno a través de un gateway

Investiga la comprobación de seguridad cuando Manual funcione, pero Auto falle repetidamente a través del mismo gateway. La corrección de 2.1.317 tiene un alcance concreto. Traducción de la entrada:

Se corrigió el fallo de Auto en cada turno cuando un gateway LLM configurado como URL base responde 403 o 422 a su comprobación de seguridad del servidor. Un 403 con apiKeyHelper no cambia.

La excepción importa. Un 403 con apiKeyHelper activo queda fuera de este cambio. Pide al responsable del gateway que revise las credenciales y el proceso de autorización sin revelar la salida secreta del helper.

La guía de compatibilidad de gateways identifica un valor de anthropic-beta y un campo de solicitud safeguards para la revisión del servidor. Si el gateway rechaza esa capacidad, la investigación debe ser distinta de la de una credencial rechazada. El código de estado, por sí solo, no distingue ambos casos.

Compara dos sesiones en una copia de trabajo de un repositorio Git de confianza. Mantén el mismo modelo, endpoint, credenciales y tarea.

Inicia claude --permission-mode default. Pide a Claude que ejecute git status --short con Bash y comunique el resultado sin modificar archivos. Aprueba la solicitud de permiso si aparece.

Sal de esa sesión, inicia claude --permission-mode auto y repite la tarea. Confirma que el modo solicitado está activo mediante los controles de modos de permisos. Una sesión que no haya entrado en Auto no sirve para validar ese modo.

Si solo falla la sesión de Auto, localiza la solicitud fallida en los registros del gateway. Pide al operador que examine el rechazo siguiendo la guía de compatibilidad. Esta comparación acota la investigación; no demuestra qué regla concreta del gateway causó el fallo.

Con la aprobación de tu administrador, puedes seleccionar temporalmente las solicitudes del clasificador de Claude Code en lugar de la revisión del servidor:

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

La referencia de variables de entorno documenta este ajuste. Cambia dónde se realiza la revisión; no desactiva la comprobación de permisos. El clasificador sigue enviando solicitudes al modelo, así que revisa su consumo y latencia antes de mantener el ajuste.

Si esta sesión funciona, pero Auto sin el ajuste falla, investiga la compatibilidad con la revisión del servidor. Si ambas fallan, investiga el error de credenciales, modelo o gateway indicado. No presupongas que esta corrección se aplica.

Para entender la facturación, consulta los cargos del clasificador del servidor y el comportamiento de la revisión alternativa. No consideres las solicitudes separadas del clasificador como una alternativa sin conexión o necesariamente gratuita.

Corrige la confianza en los certificados, no la autenticación

Trata unable to get local issuer certificate como un problema de confianza en los certificados. Es un fallo de una capa distinta a la de una respuesta HTTP de autorización.

El registro de cambios de 2.1.317 indica, en traducción:

Se corrigieron los fallos de solicitudes API con “unable to get local issuer certificate” detrás de algunos proxies con inspección TLS tras renovar un certificado raíz.

Esta corrección cubre el problema de renovación descrito. No demuestra que todos los errores del certificado del emisor tengan esa causa.

Primero, confirma la versión del cliente. Después, pregunta a TI si cambió el certificado raíz del proxy y qué paquete de autoridades de certificación debe aceptar el cliente. Usa un paquete PEM aprobado, no un certificado copiado de una fuente sin verificar.

Si tu entorno necesita un paquete propio, guarda el archivo proporcionado por TI como $HOME/company-ca.pem. Inicia un proceso nuevo de Claude Code desde la misma shell de Bash:

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

Esto sigue la configuración documentada de CA personalizadas. La ruta del ejemplo es un nombre de archivo local que eliges. Los certificados deben proceder de tu organización.

La comprobación es una solicitud completada sin el error del certificado del emisor. Si vuelve a fallar, pide a TI que revise el paquete proporcionado y la cadena de certificados presentada a través del proxy.

No establezcas NODE_TLS_REJECT_UNAUTHORIZED=0. Las instrucciones de Anthropic sobre errores de certificados advierten de que esto desactiva la validación de certificados.

Archivos NODE_EXTRA_CA_CERTS vacíos o dañados

Usa 2.1.318 o posterior cuando el propio archivo de CA adicionales tenga un formato incorrecto. Su registro de cambios indica, en traducción:

Se corrigió el fallo de todas las conexiones cuando el archivo NODE_EXTRA_CA_CERTS está vacío, no está en PEM o empieza con un certificado dañado. Ahora se usan los certificados legibles y se muestra una advertencia en stderr.

Revisa las advertencias, además del resultado final de la conexión. La corrección utiliza los certificados legibles. No repara el archivo ni aporta un certificado ausente que necesite tu proxy.

Sustituye el paquete vacío o dañado por el archivo PEM aprobado. Elimina una configuración accidental de NODE_EXTRA_CA_CERTS solo tras confirmar que el entorno no la necesita. Después, inicia un proceso nuevo y repite la solicitud pequeña.

Si la solicitud funciona, pero continúa la advertencia sobre el archivo de certificados, corrige el paquete antes de dar la configuración por terminada.

No se puede acceder al Claude apps gateway obligatorio

Restablece la conexión con el gateway obligatorio antes de modificar unas credenciales de acceso que funcionan. La entrada de 2.1.317 dice, en traducción:

Se mejoró el error de inicio cuando no se puede acceder a un Claude apps gateway obligatorio. Ahora apunta a la red, no al inicio de sesión, e indica cuándo no se puede verificar el certificado TLS del gateway.

Esta entrada se refiere a un Claude apps gateway obligatorio. No la apliques automáticamente a cualquier endpoint de terceros configurado en ANTHROPIC_BASE_URL.

Facilita al administrador del gateway el nombre del host afectado y el error sin datos sensibles. Pídele que compruebe la disponibilidad del servicio, DNS, la política del proxy y la confianza en el certificado. Si el mensaje señala un problema de verificación del certificado, sigue las comprobaciones de CA en lugar de restablecer las credenciales.

La verificación tiene dos etapas: Claude Code debe superar el fallo de inicio del gateway y después completar la solicitud pequeña al modelo. Un error de autenticación posterior es un resultado distinto que debes investigar.

Renueva la sesión solo cuando haya caducado esa credencial

Renueva la sesión guardada de claude.ai cuando el error indique que ha caducado. Las notas de 2.1.318 distinguen este caso del bloqueo de red. Traducción:

Se corrigió el fallo de inicio de sesión cuando la sesión guardada de claude.ai alcanza su límite de tiempo. Ahora se explica esa causa y, en claude -p, se indican claude auth login y claude setup-token.

Para un flujo interactivo que deba usar tu sesión de claude.ai, ejecuta estos comandos en Bash:

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

Completa el inicio de sesión antes de comprobar el estado y enviar la solicitud. El resultado esperado es el estado de autenticación previsto seguido de una respuesta correcta.

La versión también indica claude setup-token para recuperar el acceso en flujos no interactivos. Sigue las instrucciones de autenticación para ese caso en lugar de incorporar un token al script.

Una credencial emitida por el gateway debe recuperarse a través de su emisor. Iniciar sesión en claude.ai no comprueba esa credencial. Si la sesión renovada sigue produciendo un error regional, de red o del gateway, vuelve a esa comprobación en lugar de repetir el inicio de sesión.

Comprueba ANTHROPIC_BASE_URL y la credencial activa

Verifica la ruta dentro de la sesión que falla antes de cambiar más ajustes. La guía de conexión recomienda /status para consultar el valor efectivo de Base URL y el origen de las credenciales.

Usa la dirección base compatible con Anthropic que documenta el gateway. La guía del protocolo asocia ANTHROPIC_BASE_URL con el formato Anthropic Messages y /v1/messages. No copies una URL compatible con OpenAI en esta configuración sin comprobar el protocolo. La guía de diagnóstico de Base URL y endpoints explica la diferencia.

Elige la variable de credenciales según el encabezado que requiera el gateway. Anthropic documenta ANTHROPIC_AUTH_TOKEN para Authorization: Bearer y ANTHROPIC_API_KEY para X-Api-Key. Sigue las instrucciones del gateway en lugar de poner la misma credencial en todas las variables disponibles.

Para una conexión existente mediante la API de BetterToken, sus instrucciones de Claude Code usan https://bettertoken.ai, sin /v1, y ANTHROPIC_AUTH_TOKEN. A fecha de 2026-11-10, su catálogo incluye claude-sonnet-5-5. Es acceso API independiente, no una suscripción a Claude ni una garantía de que funcionen todas las características de Claude Code.

Cuando la ruta efectiva difiera de la configuración prevista, sigue cómo verificar el proveedor activo de Claude Code. Localiza una solicitud pequeña en los registros del proveedor previsto y repite después la operación concreta que falló. Una respuesta básica basta para comprobar una conexión básica. Un incidente de Auto también requiere que la comparación de Auto funcione.