Sommaire

Vous tentez d'utiliser Claude Code sur une machine d'entreprise ou via un VPN, et la connexion échoue avec des erreurs de ce genre ?

# Ce qui s'affiche aujourd'hui (exemples)
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

# Ce qu'affichaient les versions précédentes
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates

La formulation dépend de la version. Depuis la v2.1.227, les messages qui se contentaient d'ajouter un code, comme Unable to connect to API (ECONNREFUSED), commencent désormais par le type d'échec, comme Connection refused — ou Can't reach the API server — (tableau de correspondance au §2). Quelle que soit la formulation affichée, ce qui se passe et la façon d'y remédier sont les mêmes.

Ce sont des erreurs réseau qui signifient « Claude Code ne peut pas atteindre le serveur d'Anthropic (api.anthropic.com). » Il ne s'agit ni d'authentification (401/403), ni de surcharge serveur (529/500), ni d'une limite de débit (429) — la requête n'a tout simplement jamais atteint le serveur. Les causes habituelles sont les proxys d'entreprise, l'inspection TLS (les certificats) et les pare-feux, ce qui rend ce problème particulièrement fréquent sur les réseaux d'entreprise. Cet article couvre la configuration du proxy, les certificats CA d'entreprise, les domaines à autoriser et les étapes de diagnostic — sur la base d'informations officielles.

Les points clés d'emblée. (1) Derrière un proxy, définissez HTTPS_PROXY. (2) Pour une erreur de certificat due à l'inspection TLS (Zscaler, etc.), pointez NODE_EXTRA_CA_CERTS vers le CA d'entreprise — et ne désactivez jamais la vérification avec NODE_TLS_REJECT_UNAUTHORIZED=0 (cela expose tout le trafic à l'interception). (3) Commencez par lancer curl -I https://api.anthropic.com pour vérifier « est-ce que ça atteint même le serveur ? » — c'est le point de départ du triage.

CLAUDE CODE · RÉSEAU / PROXY

Ça n'atteint jamais le serveur

— l'endroit où ça s'arrête décide du correctif

Claude Code
requête
→✗
Proxy / TLS / Pare-feu
souvent bloqué ici
→
api.anthropic.com
Proxy
HTTPS_PROXY
Certificat TLS
NODE_EXTRA_CA_CERTS
Pare-feu
api.anthropic.com etc.

Lancez d'abord curl -I https://api.anthropic.com pour vérifier si ça atteint le serveur.
Une fois que vous savez où ça s'arrête (proxy / TLS / pare-feu), le réglage à appliquer est décidé.

1. Ce que cette erreur vous dit vraiment

Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (depuis la v2.1.227, formulés comme Connection refused — ; voir §2) signifient « la requête n'a pas atteint le serveur d'Anthropic » = elle a échoué quelque part au niveau TCP/TLS/DNS. C'est la différence décisive avec les autres erreurs : l'authentification (401/403), le serveur (529/500) et le débit (429) sont des réponses obtenues après avoir atteint le serveur, tandis que les erreurs réseau signifient que ça n'est jamais arrivé jusque-là.

Sur les réseaux d'entreprise, les blocages typiques se répartissent en trois couches. (1) Proxy — vous ne pouvez pas sortir directement et devez passer par un proxy d'entreprise qui n'est pas configuré. (2) Inspection TLS (certificats) — un proxy d'inspection comme Zscaler remplace les certificats, vous devez donc faire confiance au CA racine de l'entreprise. (3) Pare-feu — les domaines requis ne sont pas autorisés. La première chose à faire est de confirmer « est-ce que ça atteint le serveur ? » avec curl -I https://api.anthropic.com — cette seule vérification sépare « un problème réseau » de « tout le reste ».

3 COUCHES

Où ça s'arrête = quel réglage appliquer

1) Aucun proxy défini
ECONNREFUSED/ETIMEDOUT/fetch failed. Vous devez passer par le proxy d'entreprise → définissez HTTPS_PROXY.
2) Erreur de certificat due à l'inspection TLS
SSL certificate verification failed/self-signed → placez le CA d'entreprise dans NODE_EXTRA_CA_CERTS. Ne désactivez jamais la vérification.
3) Domaine bloqué par le pare-feu
Domaines requis non autorisés → autorisez api.anthropic.com etc. (§5).
4) DNS / VPN / outils locaux
Could not resolve host/ENOTFOUND. DNS hors service, VPN résiduel ou Docker qui intercepte le trafic.

Si curl -I https://api.anthropic.com réussit, le problème se réduit à l'espace entre Claude Code et le réseau.

2. Ce que signifie chaque message (formulations depuis la v2.1.227)

D'après la référence officielle des erreurs, les messages de cette famille signifient que la connexion TCP à l'API a échoué ou ne s'est jamais établie. Pour les codes d'erreur courants, le message décrit le type d'échec et garde le code entre parenthèses. Voici ce qui s'affiche aujourd'hui :

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

Avant la v2.1.227, tous ces messages avec code s'affichaient sous la forme Unable to connect to API suivi du code (par exemple Unable to connect to API (ECONNREFUSED)). Les codes que Claude Code ne reconnaît pas s'affichent toujours ainsi. Un même message peut aussi porter des codes différents : Connection refused peut afficher ConnectionRefused ou ECONNREFUSED, et Can't reach the API server peut afficher ENOTFOUND ou FailedToOpenSocket.

Le message commence parCe que dit le messageÀ vérifier en premier
Connection refused —La connexion a été refusée ; un pare-feu ou un proxy la bloque peut-êtreLa liste d'autorisation (§5) et HTTPS_PROXY (§3)
Can't reach the API server —Le serveur de l'API est injoignable ; soupçonnez la connexion Internet ou le DNSLe DNS et le VPN ; sous WSL, /etc/resolv.conf (§6)
No internet route —Aucune route vers la destinationL'état de votre ligne et de la connexion VPN
Couldn't connect through your proxyLe proxy a refusé le tunnelLes identifiants du proxy, et s'il autorise l'hôte de destination
Connection droppedLa connexion a été réinitialisée (ECONNRESET)La stabilité du proxy et du réseau

Quel que soit le message, les échecs passagers sont réessayés automatiquement : quand il s'affiche, les nouvelles tentatives sont donc déjà épuisées. S'il revient sans cesse, la cause se trouve dans votre réseau local. La référence officielle cite comme causes fréquentes l'absence d'accès à Internet, un VPN qui bloque api.anthropic.com ou un proxy d'entreprise obligatoire non configuré. Les corrections se trouvent aux §3–§6.

Unable to connect to Anthropic services (configuration initiale)

Lors de la configuration du premier lancement, avant d'afficher l'étape de connexion, Claude Code vérifie qu'il peut joindre api.anthropic.com et platform.claude.com. Si l'une des deux vérifications échoue, il affiche la raison et se ferme. L'exemple officiel :

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 vérification passe par la même configuration de proxy que les requêtes à l'API et accorde 10 secondes à chaque tentative. Si la tentative échouée est passée par un proxy, le message indique la variable d'environnement qui l'a configuré (comme HTTPS_PROXY). Que faire :

  • Vérifiez que la variable indiquée pointe vers le bon proxy, et demandez à votre équipe réseau d'autoriser à travers lui les connexions HTTPS vers l'hôte du message (liste d'autorisation au §5)
  • Lancez la vérification d'accès avec curl du §6 dans le même shell
  • S'il reste bloqué sur Checking connectivity... derrière une URL de proxy commençant par https://, il peut s'agir d'un bug antérieur à la v2.1.222 (la vérification empruntait un autre chemin que les requêtes à l'API et n'avait pas de délai d'expiration). Mettez à jour
  • Si votre organisation se connecte via une passerelle cloud (Claude apps gateway) et que cette erreur apparaît au premier lancement, mettez à jour vers la v2.1.247 ou une version ultérieure

Si votre réseau est ouvert et que l'échec persiste, la référence officielle indique que Claude Code n'est peut-être pas disponible dans votre pays ou votre région. Consultez la liste des pays et régions pris en charge.

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.

Cet avertissement ne signifie pas « la requête n'est pas arrivée », mais « un équipement intermédiaire a modifié la réponse ». Une réponse en streaming de votre fournisseur de modèles s'est terminée sans livrer la moindre donnée exploitable, si bien que Claude Code a renvoyé la requête sans streaming pour terminer le tour. Chaque requête concernée est envoyée deux fois : la tentative en streaming vide et le renvoi. D'après la référence officielle, la cause habituelle est un proxy ou une passerelle qui consomme ou transforme en chemin le corps de la réponse en streaming, et la solution consiste à configurer tout proxy ou toute passerelle entre Claude Code et votre fournisseur de modèles pour qu'ils transmettent sans modification le corps et les en-têtes des réponses en streaming. L'avertissement s'affiche une fois par session, et seulement en session interactive. Avant la v2.1.239, Claude Code réessayait sans streaming en silence.

3. Configuration du proxy (HTTPS_PROXY)

Lorsque vous devez passer par un proxy d'entreprise, définissez les variables d'environnement de proxy standard. Claude Code les respecte.

# Recommandé : proxy HTTPS
export HTTPS_PROXY=http://proxy.example.com:8080
# Si HTTPS n'est pas disponible, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Destinations qui contournent le proxy (séparées par espace ou virgule)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

# Proxy avec authentification (évitez de coder les mots de passe en dur)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080

Points d'attention : les proxys SOCKS ne sont pas pris en charge. Pour les proxys NTLM / Kerberos, la recommandation officielle est de mettre en place une passerelle LLM (LLM gateway) entre les deux et de pointer ANTHROPIC_BASE_URL vers elle. Ces variables peuvent aussi figurer dans le bloc env de settings.json.

4. TLS et certificats CA d'entreprise (le plus important, en toute sécurité)

Le blocage d'entreprise le plus courant est une erreur de certificat causée par un proxy d'inspection TLS (Zscaler, Netskope, Palo Alto, etc.) qui remplace les certificats. Les messages typiques sont unable to get local issuer certificate et SELF_SIGNED_CERT_IN_CHAIN.

Depuis la v2.1.273, les messages de Claude Code lui-même incluent le code d'erreur et la correction. Pendant une session, les requêtes à l'API affichent :

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

Pendant /login et la vérification de connectivité au démarrage, le même échec produit un autre message :

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.

Avant la v2.1.273, les deux premiers messages se terminaient par Check your proxy or corporate SSL certificates, sans le code ni l'indication sur NODE_EXTRA_CA_CERTS (l'ancienne sortie en haut de l'article). Par ailleurs, depuis la v2.1.199, un échec de validation du certificat n'est pas réessayé : l'erreur apparaît donc dès la première tentative (les versions précédentes passaient d'abord quelques minutes à réessayer). Les conditions TLS passagères, comme un délai dépassé lors de la négociation, sont toujours réessayées.

Pour le contexte, les versions récentes de Claude Code font confiance À LA FOIS à leur jeu de CA intégré ET au magasin de certificats du système d'exploitation. Ainsi, si le CA racine de l'entreprise se trouve dans le magasin de certificats de l'OS, cela fonctionne souvent sans configuration supplémentaire (le comportement varie selon la version, vérifiez donc la dernière en date). S'il n'est pas dans le magasin de l'OS, pointez NODE_EXTRA_CA_CERTS vers le bundle CA (PEM) que vous avez reçu du service informatique :

# La bonne méthode, sécurisée : faire confiance au CA d'entreprise
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem

# Si le proxy exige un certificat client (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem

⚠️ À NE PAS faire : désactiver la vérification TLS

Désactiver la vérification des certificats avec NODE_TLS_REJECT_UNAUTHORIZED=0 semble « résoudre » le problème, mais ne faites jamais cela. Cela désactive la vérification TLS pour l'ensemble du processus, de sorte que tout le trafic — y compris vers api.anthropic.com — est exposé aux attaques de l'homme du milieu (écoute/altération). Cela risque de divulguer des identifiants et du code. La bonne réponse est toujours de « faire correctement confiance au CA d'entreprise via NODE_EXTRA_CA_CERTS ».

Si vous rencontrez une erreur de certificat au moment de l'installation (avant que le binaire n'existe), transmettez le CA à curl : curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash.

OAuth error: SSL certificate error (CERT_HAS_EXPIRED)

Au milieu de la connexion (l'étape OAuth de /login), le message ci-dessous peut apparaître et tout bloquer. C'est le texte exact que des utilisateurs ont signalé dans des issues 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.

Ce message ne figure pas dans la référence officielle des erreurs. La section officielle SSL certificate errors ne montre que les codes UNABLE_TO_GET_ISSUER_CERT_LOCALLY et SELF_SIGNED_CERT_IN_CHAIN ; le certificat expiré n'y est cité qu'en passant, comme exemple d'échec de validation de certificat, dans l'explication des nouvelles tentatives automatiques. Le texte ci-dessus provient d'utilisateurs dans les issues GitHub #71708 et #71727 (toutes deux de juin 2026).

Ce que signifie CERT_HAS_EXPIRED : c'est l'un des codes d'erreur de certificat renvoyés par la couche TLS de Node.js, et la documentation officielle de Node.js le décrit comme « Certificate has expired » (le certificat a expiré). Autrement dit, le certificat reçu du serveur a été vérifié et jugé au-delà de sa date d'expiration. Cette vérification se fait par rapport à l'horloge de votre propre machine.

Ce que disent les signalements : les auteurs des deux issues indiquent qu'ils n'utilisaient ni proxy ni VPN, et que curl atteignait le même hôte sans problème (l'auteur de #71708 a aussi vérifié que l'horloge était juste). Le message apparaît donc aussi dans des environnements auxquels sa propre suggestion (proxy d'entreprise, inspection TLS) ne s'applique pas. Les auteurs soupçonnaient le runtime intégré à Claude Code, et plusieurs commentaires disent que revenir à une version plus ancienne a réglé le problème. Mais aucune des deux issues ne contient de réponse d'Anthropic, et toutes deux ont été fermées faute d'activité. La cause n'a pas été confirmée officiellement. Au 30 septembre 2026, le CHANGELOG officiel ne contient pas non plus d'entrée indiquant que ce symptôme est corrigé.

Ce qu'il faut vérifier, dans l'ordre :

  1. L'horloge de la machine : la date, l'heure et le fuseau horaire sont-ils justes ? Si l'horloge est très décalée, même un certificat valide peut être jugé expiré.
  2. Le certificat du proxy de l'entreprise : si votre trafic passe par un proxy ou un produit de sécurité qui inspecte le TLS, demandez au service informatique si le certificat qu'il insère (y compris le CA d'entreprise) a expiré.
  3. NODE_EXTRA_CA_CERTS : si vous devez faire confiance à un CA d'entreprise, pointez NODE_EXTRA_CA_CERTS vers le bundle CA fourni par le service informatique, comme l'indique la page officielle de configuration réseau (les étapes ci-dessus). Pour vérifier qu'il a été chargé, cherchez la ligne CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS dans le journal de claude --debug.
  4. S'il apparaît encore : si l'horloge est juste, qu'il n'y a pas de proxy et que curl -I https://platform.claude.com passe, vous êtes peut-être dans la même situation que les signalements GitHub. Mettez Claude Code à jour, puis consultez les issues et le changelog. Un commentaire affirme que NODE_TLS_REJECT_UNAUTHORIZED=0 a débloqué la situation, mais, comme l'explique l'encadré ci-dessus, cela désactive complètement la vérification : ne l'utilisez pas.

5. Domaines à autoriser dans le pare-feu

Si votre pare-feu restreint les destinations, autorisez ces principaux domaines via HTTPS (443) (conformément aux exigences réseau officielles ; si vous utilisez des connecteurs MCP, des plugins, etc., il vous faut aussi d'autres hôtes de la liste officielle).

DomaineUtilisé pour
api.anthropic.comRequêtes à l'API Claude (requis)
claude.aiAuthentification du compte claude.ai
claude.comLa page que le navigateur ouvre lors de la connexion avec un compte claude.ai (redirige vers claude.ai)
platform.claude.comAuthentification du compte Console ; les comptes claude.ai l'utilisent aussi pour obtenir et renouveler leurs jetons (visé par la vérification de connectivité du premier lancement)
downloads.claude.aiInstallateur, mises à jour automatiques, plugins
raw.githubusercontent.comJournal des modifications de /release-notes

Les hôtes de télémétrie opérationnelle et de rapport d'erreurs (http-intake.logs.us5.datadoghq.com et browser-intake-us5-datadoghq.com) sont facultatifs, et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC désactive les deux (pas besoin de les inclure dans la liste d'autorisation obligatoire). Si vous installez via npm, vous n'avez pas besoin des usages installateur et mise à jour automatique de downloads.claude.ai, mais il vous faut le registre de paquets registry.npmjs.org. Les domaines et plages d'adresses IP exacts peuvent être révisés, alors confirmez les dernières informations sur la page officielle de configuration réseau.

6. Le flux de diagnostic

Quand la connexion échoue, procédez de haut en bas. Le premier curl donne la direction.

DIAGNOSTIC

Isolez le problème de haut en bas

1
curl -I https://api.anthropic.com (sous Windows : curl.exe) pour tester l'accessibilité. Si ça passe, le problème est de votre côté.
2
/doctor (ou claude doctor si ça ne démarre pas) et vérifiez les variables d'environnement du proxy.
3
Erreur de certificat → appliquez NODE_EXTRA_CA_CERTS ; aucun proxy défini → appliquez HTTPS_PROXY.
4
Essayez une connexion directe (hors VPN/proxy) pour confirmer que le proxy est en cause. Demandez au service informatique l'URL du proxy et le CA.
5
Si curl passe mais que Claude Code échoue, suspectez le DNS (WSL resolv.conf), un VPN résiduel ou Docker qui intercepte le trafic.

La règle : « testez d'abord l'accessibilité (curl), puis appliquez le réglage de la couche qui vous a bloqué. »
Gérez les certificats avec NODE_EXTRA_CA_CERTS. Ne désactivez jamais la vérification.

7. La distinguer des erreurs similaires

« Ça s'est arrêté » peut aussi être autre chose que du réseau. La grande séparation est « est-ce que ça a atteint le serveur ? »

SymptômeCe que c'est réellementCorrectif principal
Unable to connect / Connection refused / Can't reach the API server / fetch failed / erreur de certificatCet article = réseau (n'a jamais atteint le serveur)HTTPS_PROXY / NODE_EXTRA_CA_CERTS / autorisation pare-feu
401 / 403 / Invalid API keyAuthentification (atteint, mais problème d'identifiant)erreurs d'authentification / connexion
529 / 500Côté serveur (atteint, mais surchargé / erreur interne)erreurs 529/500
429 Request rejectedLimite de débit (atteint, mais trop de trafic)Ralentir, attendre
Connection lost mid-response (avant la v2.1.227 : Connection closed mid-response)Coupure en cours de flux (connecté, la réponse arrivait, puis la connexion s'est fermée)La réponse coupée en plein milieu (article sur l'ancienne formulation)

Un moyen mnémotechnique : les erreurs réseau signifient « ça n'a jamais atteint le serveur » (TCP/TLS/DNS), et HTTPS_PROXY ou NODE_EXTRA_CA_CERTS n'aident qu'à cette couche. En revanche, 401/403, 529/500 et 429 sont des « réponses obtenues après avoir atteint le serveur », donc ajuster le proxy ou le CA ne les corrigera pas. Le succès ou l'échec de curl est le meilleur indice pour séparer les deux. Pour d'autres erreurs courantes, consultez le récapitulatif des erreurs.

Résumé

Les erreurs réseau/proxy de Claude Code (Unable to connect / fetch failed / SSL certificate verification failed, etc.) signifient que la requête n'a jamais atteint le serveur = un échec TCP/TLS/DNS. Elles sont différentes de l'authentification (401/403), du serveur (529/500) et du débit (429), et les coupables habituels sont le proxy, l'inspection TLS et le pare-feu de l'entreprise. Depuis la v2.1.227, elles sont formulées pour nommer d'abord le type d'échec, comme Connection refused — ou Can't reach the API server —, et la configuration initiale se ferme sur Unable to connect to Anthropic services.

Les correctifs : (1) derrière un proxy, définissez HTTPS_PROXY (SOCKS non pris en charge ; NTLM/Kerberos via une passerelle), (2) pour les erreurs de certificat, placez le CA d'entreprise dans NODE_EXTRA_CA_CERTS — jamais NODE_TLS_REJECT_UNAUTHORIZED=0, (3) autorisez api.anthropic.com etc. dans le pare-feu. Diagnostiquez en testant d'abord l'accessibilité avec curl -I https://api.anthropic.com -> /doctor et vérification du proxy -> réglages certificat/proxy -> une connexion directe pour confirmer -> DNS/VPN/Docker. L'essentiel est de séparer le réseau de l'authentification/serveur/débit par « est-ce que ça a atteint le serveur ? » En lien : erreurs d'authentification / connexion, erreurs 529/500, récapitulatif des erreurs Claude Code.

FAQ

Q. Sur mon PC d'entreprise, j'obtiens « Unable to connect to API » et je ne peux pas me connecter.
A. En général, vous devez passer par un proxy d'entreprise qui n'est pas configuré. Vérifiez d'abord l'accessibilité avec curl -I https://api.anthropic.com ; si ça échoue, définissez un proxy comme export HTTPS_PROXY=http://proxy.example.com:8080 (ajoutez user:password@ pour un proxy avec authentification). Notez que SOCKS n'est pas pris en charge, et pour les proxys NTLM/Kerberos, la recommandation officielle est de passer par une passerelle LLM.

Q. « Can't reach the API server » et « Connection refused » sont-elles des erreurs différentes de l'ancienne « Unable to connect to API » ?
A. Elles appartiennent à la même famille ; seule la formulation a changé dans la v2.1.227. Auparavant, le message se contentait d'ajouter un code, comme Unable to connect to API (ECONNREFUSED) ; désormais, il nomme d'abord le type d'échec, comme Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) ou Can't reach the API server — check your internet or DNS (ENOTFOUND). Le code entre parenthèses oriente vers la cause : consultez le tableau du §2 pour savoir quoi vérifier.

Q. Au premier lancement, j'obtiens « Unable to connect to Anthropic services » et le programme se ferme.
A. L'échec a eu lieu à l'étape qui vérifie, avant la connexion, l'accès à api.anthropic.com et à platform.claude.com. Si le message nomme une variable de proxy (comme HTTPS_PROXY), vérifiez sa valeur avec votre équipe réseau et assurez-vous que les connexions vers l'hôte du message sont autorisées. Vous pouvez aussi vérifier l'accès avec curl -I https://api.anthropic.com. Si votre réseau est ouvert et que l'erreur persiste, la référence officielle indique que Claude Code n'est peut-être pas disponible dans votre pays ou votre région, ce que vous pouvez vérifier dans la liste officielle des pays pris en charge.

Q. J'obtiens « SSL certificate verification failed ».
A. Il s'agit généralement d'un proxy d'inspection TLS d'entreprise (par ex. Zscaler) qui remplace les certificats. Obtenez le CA racine de l'entreprise (PEM) auprès du service informatique et définissez export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem. Si le CA d'entreprise est déjà dans le magasin de certificats de l'OS, cela peut fonctionner sans configuration. Ne désactivez jamais la vérification avec NODE_TLS_REJECT_UNAUTHORIZED=0 — cela expose tout le trafic à l'interception.

Q. Définir NODE_TLS_REJECT_UNAUTHORIZED=0 a résolu le problème. Est-ce acceptable ?
A. Non — annulez-le immédiatement. Cela désactive la vérification des certificats TLS pour l'ensemble du processus, laissant tout le trafic — y compris vers api.anthropic.com — sans défense face aux attaques de l'homme du milieu (écoute/altération). C'est un grave risque de sécurité qui peut divulguer des identifiants et du code source. Le seul correctif correct est de faire correctement confiance au CA d'entreprise via NODE_EXTRA_CA_CERTS.

Q. Quels domaines dois-je autoriser dans le pare-feu ?
A. Via HTTPS (443), autorisez au minimum api.anthropic.com (API), claude.ai, claude.com et platform.claude.com (authentification), downloads.claude.ai (installateur/mises à jour) et raw.githubusercontent.com (journal des modifications). La télémétrie opérationnelle et le rapport d'erreurs (Datadog) sont facultatifs. Les domaines/IP exacts peuvent être révisés, alors confirmez les dernières informations sur la page officielle de configuration réseau.

Q. curl fonctionne, mais seul Claude Code ne se connecte pas.
A. La cause se situe souvent entre Claude Code et l'OS. Cas courants : un /etc/resolv.conf de WSL qui pointe vers un DNS hors service, des résidus de VPN (par ex. d'anciennes interfaces utun sous macOS), ou un outil résident comme Docker qui intercepte le trafic. Essayez une connexion directe hors VPN, arrêtez les outils résidents et passez en revue le DNS, dans cet ordre. Notez que les erreurs 5xx transitoires font l'objet de jusqu'à 10 nouvelles tentatives automatiques ; donc si vous voyez une erreur alors que curl réussit, les nouvelles tentatives sont déjà épuisées.

La configuration, les coûts et les points d'attention pour diriger ANTHROPIC_BASE_URL vers des modèles autres que Claude (DeepSeek, GLM, Kimi, etc.) sont expliqués dans Utiliser DeepSeek, GLM et Kimi avec Claude Code.