Índice

¿Intentas usar Claude Code en un equipo corporativo o a través de una VPN y no consigue conectar, con errores como estos?

# Lo que verás ahora (ejemplos)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Unable to connect to API. Check your internet connection
Unable to connect to Anthropic services
fetch failed

# Lo que mostraban las versiones anteriores
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates

El texto depende de la versión. Desde la v2.1.227, los mensajes que antes solo añadían un código, como Unable to connect to API (ECONNREFUSED), empiezan ahora por el tipo de fallo, como Connection refused — o Can't reach the API server — (tabla de correspondencias en §2). Veas el texto que veas, lo que ocurre y cómo se arregla es lo mismo.

Estos son errores de red que significan "Claude Code no puede alcanzar el servidor de Anthropic (api.anthropic.com)." No son de autenticación (401/403), ni de sobrecarga del servidor (529/500), ni un límite de tasa (429): la solicitud nunca llegó al servidor. Las causas habituales son los proxies corporativos, la inspección TLS (certificados) y los firewalls, lo que lo hace especialmente frecuente en redes empresariales. Este artículo cubre la configuración del proxy, los certificados CA corporativos, los dominios a permitir y los pasos de diagnóstico, basándose en información oficial.

Puntos clave por adelantado. (1) Detrás de un proxy, configura HTTPS_PROXY. (2) Ante un error de certificado por inspección TLS (Zscaler, etc.), apunta NODE_EXTRA_CA_CERTS a la CA corporativa y nunca desactives la verificación con NODE_TLS_REJECT_UNAUTHORIZED=0 (expone todo el tráfico a interceptación). (3) Empieza ejecutando curl -I https://api.anthropic.com para comprobar "¿siquiera llega?": ese es el punto de partida del diagnóstico.

CLAUDE CODE · NETWORK / PROXY

Nunca llega al servidor

— dónde se detiene decide la solución

Claude Code
solicitud
→✗
Proxy / TLS / Firewall
aquí suele bloquearse
→
api.anthropic.com
Proxy
HTTPS_PROXY
Certificado TLS
NODE_EXTRA_CA_CERTS
Firewall
api.anthropic.com etc.

Primero ejecuta curl -I https://api.anthropic.com para comprobar si puede llegar.
Una vez sepas dónde se detiene (proxy / TLS / firewall), queda decidido qué ajuste aplicar.

1. Qué te está diciendo este error

Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (desde la v2.1.227, con textos como Connection refused —; ver §2) significan "la solicitud no llegó al servidor de Anthropic" = falló en algún punto de TCP/TLS/DNS. Esta es la diferencia decisiva frente a otros errores: autenticación (401/403), servidor (529/500) y tasa (429) son respuestas tras haber alcanzado el servidor, mientras que los errores de red significan que nunca llegó allí.

En redes empresariales, los bloqueos típicos se dividen en tres capas. (1) Proxy: no puedes salir directamente y debes pasar por un proxy corporativo que no está configurado. (2) Inspección TLS (certificados): un proxy de inspección como Zscaler reemplaza los certificados, así que debes confiar en la CA raíz corporativa. (3) Firewall: los dominios necesarios no están permitidos. Lo primero que hay que hacer es confirmar "¿puede llegar?" con curl -I https://api.anthropic.com: esta única comprobación separa "un problema de red" de "todo lo demás."

3 LAYERS

Dónde se detiene = qué ajuste aplicar

1) Sin proxy configurado
ECONNREFUSED/ETIMEDOUT/fetch failed. Debes pasar por el proxy corporativo → configura HTTPS_PROXY.
2) Error de certificado por inspección TLS
SSL certificate verification failed/self-signed → pon la CA corporativa en NODE_EXTRA_CA_CERTS. Nunca desactives la verificación.
3) Dominio bloqueado por el firewall
Dominios necesarios no permitidos → permite api.anthropic.com etc. (§5).
4) DNS / VPN / herramientas locales
Could not resolve host/ENOTFOUND. DNS caído, VPN obsoleta o Docker interceptando el tráfico.

Si curl -I https://api.anthropic.com tiene éxito, el problema se reduce a algo entre Claude Code y la red.

2. Qué significa cada mensaje (textos desde la v2.1.227)

Según la referencia oficial de errores, los mensajes de esta familia indican que la conexión TCP con la API falló o no llegó a completarse. Para los códigos de error habituales, el mensaje describe el tipo de fallo y conserva el código entre paréntesis. Esto es lo que verás ahora:

Unable to connect to API. Check your internet connection
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
No internet route — check your connection or VPN (EHOSTUNREACH)
Couldn't connect through your proxy (ERR_PROXY_TUNNEL) — the proxy refused the tunnel: check its credentials and that it allows this host
Connection dropped (ECONNRESET)
fetch failed
Request timed out. Check your internet connection and proxy settings

Antes de la v2.1.227, todos estos mensajes con código decían Unable to connect to API seguido del código (por ejemplo, Unable to connect to API (ECONNREFUSED)). Los códigos que Claude Code no reconoce siguen apareciendo así. Además, un mismo mensaje puede llevar códigos distintos: Connection refused puede mostrar ConnectionRefused o ECONNREFUSED, y Can't reach the API server puede mostrar ENOTFOUND o FailedToOpenSocket.

El mensaje empieza porLo que indica el mensajeQué revisar primero
Connection refused —Se rechazó la conexión; puede que un firewall o un proxy la esté bloqueandoLa lista de permitidos (§5) y HTTPS_PROXY (§3)
Can't reach the API server —No se alcanza el servidor de la API; sospecha de la conexión a internet o del DNSEl DNS y la VPN; en WSL, /etc/resolv.conf (§6)
No internet route —No hay ruta hasta el destinoEl estado de tu línea y de la conexión VPN
Couldn't connect through your proxyEl proxy rechazó el túnelLas credenciales del proxy y si permite el host de destino
Connection droppedLa conexión se restableció (ECONNRESET)La estabilidad del proxy y de la red

Sea cual sea el mensaje, los fallos transitorios se reintentan automáticamente, así que cuando aparece en pantalla los reintentos ya se han agotado. Si se repite, la causa está en tu red local. La referencia oficial cita como causas habituales no tener acceso a internet, una VPN que bloquea api.anthropic.com o un proxy corporativo obligatorio sin configurar. Las soluciones están en §3–§6.

Unable to connect to Anthropic services (configuración inicial)

En la configuración del primer arranque, antes de mostrar el paso de inicio de sesión, Claude Code comprueba que puede alcanzar api.anthropic.com y platform.claude.com. Si alguna de las dos comprobaciones falla, muestra el motivo y se cierra. El ejemplo oficial:

Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ECONNREFUSED
Connection to api.anthropic.com timed out after 10 seconds
A proxy is configured via HTTPS_PROXY. Check that it allows connections to the host above.

La comprobación usa la misma configuración de proxy que las solicitudes a la API y da 10 segundos a cada intento. Si el intento fallido pasó por un proxy, el mensaje indica la variable de entorno que lo configuró (como HTTPS_PROXY). Qué hacer:

  • Comprueba que la variable indicada apunta al proxy correcto y pide a tu equipo de red que permita a través de él las conexiones HTTPS al host del mensaje (lista de permitidos en §5)
  • Haz la comprobación de alcance con curl de §6 en la misma shell
  • Si se queda en Checking connectivity... detrás de una URL de proxy que empieza por https://, puede ser un fallo anterior a la v2.1.222 (la comprobación seguía una ruta distinta de la de las solicitudes a la API y no tenía tiempo límite). Actualiza
  • Si tu organización inicia sesión a través de una pasarela en la nube (Claude apps gateway) y este error aparece en el primer arranque, actualiza a la v2.1.247 o posterior

Si tu red está abierta y el fallo persiste, la referencia oficial señala que Claude Code puede no estar disponible en tu país o región. Consulta la lista de países y regiones admitidos.

Streaming response ended before any complete data was received

Streaming response ended before any complete data was received. Retrying without streaming. If this keeps happening, check any proxy or gateway between Claude Code and your model provider.

Este aviso no significa "no llegó", sino "algo intermedio alteró la respuesta". Una respuesta en streaming de tu proveedor de modelos terminó sin entregar ningún dato utilizable, así que Claude Code reenvió la solicitud sin streaming para completar el turno. Cada solicitud afectada se envía dos veces: el intento en streaming vacío y el reintento. Según la referencia oficial, la causa habitual es un proxy o una pasarela que consume o transforma por el camino el cuerpo de la respuesta en streaming, y la solución es configurar cualquier proxy o pasarela entre Claude Code y tu proveedor de modelos para que deje pasar sin modificar el cuerpo y las cabeceras de las respuestas en streaming. El aviso aparece una vez por sesión y solo en sesiones interactivas. Antes de la v2.1.239, Claude Code reintentaba sin streaming en silencio.

3. Configuración del proxy (HTTPS_PROXY)

Cuando debes pasar por un proxy corporativo, configura las variables de entorno de proxy estándar. Claude Code las respeta.

# Recomendado: proxy HTTPS
export HTTPS_PROXY=http://proxy.example.com:8080
# Si HTTPS no está disponible, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Destinos que omiten el proxy (separados por espacios o comas)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Proxy con autenticación (evita codificar contraseñas en duro)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Advertencias: los proxies SOCKS no son compatibles. Para proxies NTLM / Kerberos, la recomendación oficial es montar un LLM gateway en medio y apuntar ANTHROPIC_BASE_URL a él. Estas variables también pueden ir en el bloque env de settings.json.

4. TLS y certificados CA corporativos (lo más importante, de forma segura)

El bloqueo empresarial más común es un error de certificado provocado por un proxy de inspección TLS (Zscaler, Netskope, Palo Alto, etc.) que reemplaza los certificados. Los mensajes típicos son unable to get local issuer certificate y SELF_SIGNED_CERT_IN_CHAIN.

Desde la v2.1.273, los mensajes del propio Claude Code incluyen el código de error y la solución. Durante una sesión, las solicitudes a la API muestran:

Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config
Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config

Durante /login y la comprobación de conectividad al arrancar, el mismo fallo produce otro mensaje:

SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.

Antes de la v2.1.273, los dos primeros mensajes terminaban en Check your proxy or corporate SSL certificates, sin el código ni la indicación de NODE_EXTRA_CA_CERTS (la salida antigua del principio del artículo). Además, desde la v2.1.199 un fallo de validación del certificado no se reintenta, así que el error aparece en el primer intento (las versiones anteriores pasaban unos minutos reintentando). Las condiciones TLS transitorias, como un tiempo de espera agotado en el handshake, se siguen reintentando.

Como contexto, las versiones recientes de Claude Code confían TANTO en su conjunto de CA incluido COMO en el almacén de confianza del sistema operativo. Por eso, si la CA raíz corporativa está en el almacén de certificados del sistema operativo, a menudo funciona sin configuración adicional (el comportamiento varía según la versión, así que confirma la más reciente). Si no está en el almacén del sistema operativo, apunta NODE_EXTRA_CA_CERTS al paquete de CA (PEM) que recibiste de TI:

# La forma correcta y segura: confiar en la CA corporativa
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

# Si el proxy requiere un certificado de cliente (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

⚠️ NO hagas: desactivar la verificación TLS

Desactivar la verificación de certificados con NODE_TLS_REJECT_UNAUTHORIZED=0 parece "arreglarlo", pero nunca lo hagas. Desactiva la verificación TLS de todo el proceso, de modo que todo el tráfico — incluido el dirigido a api.anthropic.com — queda expuesto a ataques de intermediario (escucha/manipulación). Eso arriesga filtrar credenciales y código. La respuesta correcta siempre es "confiar adecuadamente en la CA corporativa mediante NODE_EXTRA_CA_CERTS."

Si te topas con un error de certificado en el momento de la instalación (antes de que exista el binario), pasa la CA a curl: curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash.

OAuth error: SSL certificate error (CERT_HAS_EXPIRED)

A mitad del inicio de sesión (el paso OAuth de /login) puede aparecer el siguiente mensaje y detenerse todo. Es el texto exacto que los usuarios reportaron en issues de GitHub:

OAuth error: SSL certificate error (CERT_HAS_EXPIRED). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run /doctor for details.

Este mensaje no figura en la referencia oficial de errores. La sección oficial SSL certificate errors solo muestra los códigos UNABLE_TO_GET_ISSUER_CERT_LOCALLY y SELF_SIGNED_CERT_IN_CHAIN; el certificado caducado solo se menciona de pasada, como un ejemplo de fallo de validación de certificados en la explicación de los reintentos automáticos. El texto de arriba procede de usuarios en los issues de GitHub #71708 y #71727 (ambos de junio de 2026).

Qué significa CERT_HAS_EXPIRED: es uno de los códigos de error de certificado que devuelve la capa TLS de Node.js, y la documentación oficial de Node.js lo describe como «Certificate has expired» (el certificado ha caducado). Es decir, se comprobó el certificado recibido del servidor y se consideró que había superado su fecha de caducidad. Esa comprobación se hace con el reloj de tu propio equipo.

Qué dicen los reportes: quienes abrieron los dos issues escribieron que no usaban proxy ni VPN y que curl llegaba sin problemas al mismo host (el autor de #71708 también comprobó que el reloj era correcto). Es decir, también aparece en entornos que no encajan con lo que sugiere el propio mensaje (proxy corporativo, inspección TLS). Los autores sospechaban del runtime incluido en Claude Code, y varios comentarios dicen que volver a una versión anterior lo resolvió. Pero en ninguno de los dos issues hay respuesta de Anthropic, y ambos se cerraron por inactividad. La causa no está confirmada oficialmente. A 30 de septiembre de 2026, el CHANGELOG oficial tampoco tiene ninguna entrada que diga corregir este síntoma.

Qué comprobar, en este orden:

  1. El reloj del equipo: ¿son correctos la fecha, la hora y la zona horaria? Si el reloj está muy desviado, incluso un certificado válido puede considerarse caducado.
  2. El certificado del proxy de la empresa: si tu tráfico pasa por un proxy o un producto de seguridad que inspecciona TLS, pregunta a TI si el certificado que inserta (incluida la CA corporativa) ha caducado.
  3. NODE_EXTRA_CA_CERTS: si necesitas confiar en una CA corporativa, apunta NODE_EXTRA_CA_CERTS al paquete de CA que te dé TI, como indica la página oficial de configuración de red (los pasos de arriba). Para confirmar que se cargó, busca la línea CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS en el registro de claude --debug.
  4. Si sigue apareciendo: si el reloj es correcto, no hay proxy y curl -I https://platform.claude.com funciona, puede que estés en la misma situación que los reportes de GitHub. Actualiza Claude Code y revisa los issues y el changelog. Un comentario dice que NODE_TLS_REJECT_UNAUTHORIZED=0 lo hizo funcionar, pero, como explica el recuadro de arriba, eso desactiva por completo la verificación, así que no lo uses.

5. Dominios a permitir en el firewall

Si tu firewall restringe los destinos, permite estos dominios principales sobre HTTPS (443) (según los requisitos de red oficiales; si usas conectores MCP, plugins, etc., también necesitas otros hosts de la lista oficial).

DominioPara qué sirve
api.anthropic.comSolicitudes a la API de Claude (obligatorio)
claude.aiAutenticación de cuenta de claude.ai
claude.comLa página que abre el navegador al iniciar sesión con una cuenta de claude.ai (redirige a claude.ai)
platform.claude.comAutenticación de cuenta de la Consola; las cuentas de claude.ai también lo usan para obtener y renovar tokens (lo revisa la comprobación de conectividad inicial)
downloads.claude.aiInstalador, actualización automática, plugins
raw.githubusercontent.comRegistro de cambios de /release-notes

Los hosts de telemetría operativa y de reporte de errores (http-intake.logs.us5.datadoghq.com y browser-intake-us5-datadoghq.com) son opcionales, y CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC desactiva ambos (no es necesario incluirlos en la lista de permitidos obligatoria). Si instalas vía npm, no necesitas los usos de instalador y actualización automática de downloads.claude.ai, pero sí el registro de paquetes registry.npmjs.org. Los dominios y rangos de IP exactos pueden cambiar, así que confirma lo más reciente en la página oficial de configuración de red.

6. El flujo de diagnóstico

Cuando no consigue conectar, ve de arriba abajo. El primer curl marca la dirección.

DIAGNOSE

Aíslalo de arriba abajo

1
curl -I https://api.anthropic.com (Windows: curl.exe) para probar la accesibilidad. Si pasa, el problema está de tu lado.
2
/doctor (o claude doctor si no arranca) y comprueba las variables de entorno del proxy.
3
Error de certificado → aplica NODE_EXTRA_CA_CERTS; sin proxy configurado → aplica HTTPS_PROXY.
4
Prueba una conexión directa (sin VPN/proxy) para confirmar que el proxy es la causa. Pide a TI la URL del proxy y la CA.
5
Si curl pasa pero Claude Code falla, sospecha del DNS (resolv.conf de WSL), una VPN obsoleta o Docker interceptando el tráfico.

La regla: "prueba primero la accesibilidad (curl) y luego aplica el ajuste de la capa que te detuvo."
Gestiona los certificados con NODE_EXTRA_CA_CERTS. Nunca desactives la verificación.

7. Cómo distinguirlo de errores parecidos

"Se detuvo" también puede no ser de red. La gran división es "¿llegó al servidor?"

SíntomaQué es en realidadSolución principal
Unable to connect / Connection refused / Can't reach the API server / fetch failed / error de certificadoEste artículo = red (nunca llegó al servidor)HTTPS_PROXY / NODE_EXTRA_CA_CERTS / lista de permitidos del firewall
401 / 403 / Invalid API keyAutenticación (llegó, pero hay un problema de credenciales)errores de autenticación / inicio de sesión
529 / 500Del lado del servidor (llegó, pero está sobrecargado / error interno)errores 529/500
429 Request rejectedLímite de tasa (llegó, pero demasiado tráfico)Reduce el ritmo, espera
Connection lost mid-response (antes de la v2.1.227: Connection closed mid-response)Corte a mitad del stream (llegó y la respuesta empezó a fluir, y entonces la conexión se cerró)La respuesta se corta a mitad (artículo sobre el texto antiguo)

Una regla mnemotécnica: los errores de red significan "nunca llegó al servidor" (TCP/TLS/DNS), y HTTPS_PROXY o NODE_EXTRA_CA_CERTS solo ayudan en esta capa. En cambio, 401/403, 529/500 y 429 son "respuestas tras haber llegado", así que ajustar el proxy o la CA no los resolverá. Que curl tenga éxito o no es la mejor señal para separar ambos casos. Para otros errores comunes, consulta el recopilatorio de errores.

Resumen

Los errores de red/proxy de Claude Code (Unable to connect / fetch failed / SSL certificate verification failed, etc.) significan que la solicitud nunca llegó al servidor = un fallo de TCP/TLS/DNS. Son distintos de los de autenticación (401/403), servidor (529/500) y tasa (429), y los culpables habituales son el proxy, la inspección TLS y el firewall empresariales. Desde la v2.1.227 se muestran con textos que nombran primero el tipo de fallo, como Connection refused — o Can't reach the API server —, y la configuración inicial se cierra con Unable to connect to Anthropic services.

Las soluciones: (1) detrás de un proxy, configura HTTPS_PROXY (SOCKS no compatible; NTLM/Kerberos mediante un gateway), (2) ante errores de certificado pon la CA corporativa en NODE_EXTRA_CA_CERTS — nunca NODE_TLS_REJECT_UNAUTHORIZED=0, (3) permite api.anthropic.com etc. en el firewall. Diagnostica probando primero la accesibilidad con curl -I https://api.anthropic.com -> /doctor y comprobación del proxy -> ajustes de certificado/proxy -> una conexión directa para confirmar -> DNS/VPN/Docker. La clave es separar red de autenticación/servidor/tasa según "¿llegó al servidor?" Relacionados: errores de autenticación / inicio de sesión, errores 529/500, recopilatorio de errores de Claude Code.

FAQ

Q. En el PC de mi empresa me sale "Unable to connect to API" y no consigo conectar.
A. Normalmente debes pasar por un proxy corporativo que no está configurado. Primero comprueba la accesibilidad con curl -I https://api.anthropic.com; si falla, configura un proxy como export HTTPS_PROXY=http://proxy.example.com:8080 (añade user:password@ para un proxy con autenticación). Ten en cuenta que SOCKS no es compatible, y para proxies NTLM/Kerberos la recomendación oficial es pasar por un LLM gateway.

Q. ¿"Can't reach the API server" y "Connection refused" son errores distintos del antiguo "Unable to connect to API"?
A. Son de la misma familia; solo cambió el texto en la v2.1.227. Antes solo se añadía un código, como Unable to connect to API (ECONNREFUSED); ahora se nombra primero el tipo de fallo, como Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) o Can't reach the API server — check your internet or DNS (ENOTFOUND). El código entre paréntesis orienta sobre la causa, así que busca qué revisar en la tabla de §2.

Q. En el primer arranque aparece "Unable to connect to Anthropic services" y se cierra.
A. Falló en el paso que comprueba la conectividad con api.anthropic.com y platform.claude.com antes de iniciar sesión. Si el mensaje nombra una variable de proxy (como HTTPS_PROXY), confirma su valor con tu equipo de red y comprueba que las conexiones al host del mensaje estén permitidas. También puedes comprobar el alcance con curl -I https://api.anthropic.com. Si tu red está abierta y persiste, la referencia oficial señala que Claude Code puede no estar disponible en tu país o región, algo que puedes consultar en la lista oficial de países admitidos.

Q. Me sale "SSL certificate verification failed".
A. Esto suele ser un proxy corporativo de inspección TLS (p. ej., Zscaler) que reemplaza los certificados. Consigue la CA raíz corporativa (PEM) de TI y configura export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. Si la CA corporativa ya está en el almacén de certificados del sistema operativo, puede que funcione sin configuración. Nunca desactives la verificación con NODE_TLS_REJECT_UNAUTHORIZED=0: eso expone todo el tráfico a interceptación.

Q. Poner NODE_TLS_REJECT_UNAUTHORIZED=0 lo arregló. ¿Está bien?
A. No: reviértelo ahora mismo. Desactiva la verificación de certificados TLS en todo el proceso, dejando todo el tráfico — incluido el dirigido a api.anthropic.com — indefenso ante ataques de intermediario (escucha/manipulación). Es un riesgo de seguridad grave que puede filtrar credenciales y código fuente. La única solución correcta es confiar adecuadamente en la CA corporativa mediante NODE_EXTRA_CA_CERTS.

Q. ¿Qué dominios debo permitir en el firewall?
A. Sobre HTTPS (443), como mínimo permite api.anthropic.com (API), claude.ai, claude.com y platform.claude.com (autenticación), downloads.claude.ai (instalador/actualizaciones) y raw.githubusercontent.com (registro de cambios). La telemetría operativa y el reporte de errores (Datadog) son opcionales. Los dominios/IP exactos pueden cambiar, así que confirma lo más reciente en la página oficial de configuración de red.

Q. curl funciona, pero solo Claude Code no consigue conectar.
A. La causa suele estar entre Claude Code y el sistema operativo. Casos comunes: un /etc/resolv.conf de WSL que apunta a un DNS caído, restos de una VPN obsoleta (p. ej., interfaces utun antiguas de macOS), o una herramienta residente como Docker interceptando el tráfico. Prueba una conexión directa sin VPN, detén las herramientas residentes y revisa el DNS, en ese orden. Ten en cuenta que los errores 5xx transitorios se reintentan automáticamente hasta 10 veces, así que si ves un error mientras curl tiene éxito, los reintentos ya se han agotado.

La configuración, los costes y las precauciones para apuntar ANTHROPIC_BASE_URL a la pasarela de modelos distintos de Claude (DeepSeek, GLM, Kimi, etc.) se explican en Cómo usar DeepSeek, GLM y Kimi con Claude Code.