Unable to connect to Anthropic servicesの対処 — Claude Code

Unable to connect to Anthropic services — Claude Codeを初めて起動したとき、サインイン画面が出る前にこの文言で終了することがあります。初回セットアップでは、サインインの手順を見せる前にapi.anthropic.comとplatform.claude.comの両方へ到達できるかを確認し、片方でも失敗すれば理由を表示して終了します。

似た文言の「Unable to connect to API」とは発生する段階が違います。あちらはサインイン後の通常利用中に出るエラーで、今回のエラーはまだ一度もサインインしていない起動直後にしか出ません。

初回起動のどこで止まるのか

Claude Codeのインストールが終わり、初めてclaudeを起動してから先の流れは次のとおりです。

認証情報の拒否やトークン失効といった認証エラーとは別の段階です。原因は認証ではなく接続側にあります。多くはネットワーク経路で、最後の手順にある提供地域の問題もここに含まれます。

メッセージの読み方

実際の表示は次のような形になります。

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.

1行目は見出し、2〜3行目がどのホストでどんな失敗が起きたかの詳細です。4行目はプロキシ経由だったときにだけ付きます。各プローブには10秒の猶予があり、過ぎるとタイムアウト扱いです。

4行目の有無が手がかりになります。この確認はAPIリクエストと同じプロキシ設定を通るので、HTTPS_PROXYなどで設定していれば、その変数名がメッセージに出ます。変数名が出ないなら、プロキシよりネットワークやファイアウォールそのものを疑う番です。

プロキシ変数はhttps_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXYの順に見て、最初に設定されていた値が使われます。小文字と大文字を別々の値で設定していると、意図しない方が先に読まれます。メッセージに出た変数名が想定と一致しているか、NO_PROXYにAnthropicのホストが紛れていないかも確認します。

2つのホストで役割が違う

チェック対象はapi.anthropic.comとplatform.claude.comの2つに固定されています。ネットワークの許可設定では、2つを別々の理由で通す必要があります。

片方だけ許可すると、サインインまでたどり着けません。ただし、この起動時チェックが確認するのは上の2つだけです。claude.aiアカウントでサインインする場合は、claude.aiと、ブラウザーで開くclaude.comのページも許可が要ります。チェックを通ったのにその先のサインインで止まるときは、こちらの許可漏れを疑えます。

起動チェックを通ったあとに必要になる許可先

起動時のチェックを通っても、許可リストが2ホストで足りるわけではありません。ネットワーク設定のページには、Claude Codeが使うURLの一覧があります。用途ごとに分けると、止まる場面が読み取りやすくなります。

• プラグインとインストーラー: ネイティブインストーラーと自動アップデートはdownloads.claude.aiを使います。プラグインの導入数やメタデータはstorage.googleapis.com、npmで配布されるプラグインやnpx起動のMCPサーバーはregistry.npmjs.orgです。GitHub上のマーケットプレイスをクローンするにはgithub.comも要ります。
• claude.aiのコネクタ: claude.aiで設定したMCPコネクタはmcp-proxy.anthropic.comを経由します。claude.aiでサインインしたユーザーでは既定で有効なので、ここを塞ぐとコネクタだけが使えなくなります。取得自体を止めたいときは、環境変数ENABLE_CLAUDEAI_MCP_SERVERSをfalseにします。
• 任意のテレメトリ: 運用テレメトリはDatadogの2つの受信ホストへ送られます。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定すると、どちらも止まります。
• ドキュメント参照: code.claude.comは、組み込みのclaude-code-guideエージェントによる文書の参照に使われます。塞いでも影響は文書の参照だけです。

ブラウザー連携のClaude in Chromeは、bridge.claudeusercontent.comのWebSocketで接続します。組織でClaudeにIPアドレス制限をかけている場合、このホストもclaude.aiやapi.anthropic.comと同じプロキシの出口を通す必要があります。出口が違うと、ほかの機能は動くのにChrome拡張とだけ接続できない状態になります。

v2.1.222で接続確認の土台が変わった

v2.1.222以降は、確認がAPIリクエストと同じプロキシ対応のトランスポートを使い、失敗すれば理由つきでタイムアウトします。古いバージョンで「固まったまま動かない」場合は、アップデートが第一候補です。

社内ゲートウェイ構成ではチェック自体が省かれる

組織が管理設定でサインイン先を指定している環境では、このチェックは走りません。

管理設定ファイル、MDMポリシー、ポリシーヘルパーのいずれかが次のどちらかを設定していると、チェックは省略されます。

• forceLoginMethodを"gateway"にしている
• forceLoginGatewayUrlを設定していて、forceLoginMethodは未設定

この場合、サインインの手順はAnthropicのサインイン方法ではなく、Cloud gateway画面から始まります。管理設定のソースがマシン上にあるのに読み取れないときも、そこにゲートウェイ設定が入っているかもしれないため、チェックは省略されます。

v2.1.247より前は、この構成でもチェックが走っていました。ゲートウェイ経由でしか外に出られない環境でAnthropicのエンドポイントに届かず、このエラーで終了する状況があり得ました。ゲートウェイ構成の組織でv2.1.247より古いバージョンを使っていて起きるなら、アップデートが解決策になります。

証明書エラーの場合は別の文言になる

/loginと起動時の接続確認では、証明書の検証に失敗したときだけ表示が変わります。コード付きの接続失敗とは違い、OpenSSLのエラーコードと対処のヒントが1行にまとまって出ます。

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.

ネットワーク上のプロキシやセキュリティ製品がTLS通信を自前の証明書で中継しており、Claude Codeがその証明書を信頼できていないときに出ます。組織のCA証明書バンドルを指定します。

export NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.pem

Claude Codeは既定で、同梱のMozilla CA証明書に加えてOSの証明書ストアも信頼します。ネイティブインストーラーは常にこの動作で、npm版はNode 22.15以上が要ります。組織のCAをOSのストアに入れてある環境では、NODE_EXTRA_CA_CERTSなしで通る場合があります。

IT部門に*.anthropic.comの許可を依頼する道もあります。NODE_TLS_REJECT_UNAUTHORIZED=0で証明書の検証を丸ごと切る回避策は、公式が明確に避けるよう書いています。

claude doctorで診断できます。v2.1.285のヘルプでは、次のように説明されています。

Usage: claude doctor [options]
 
Check the health of your Claude Code installation. Reads settings files in the
current directory without a trust prompt. For a full checkup that can also fix
issues, run /doctor in a session.

起動前でもターミナルから実行でき、セッション内の/doctorと役割が分かれています。

証明書の信頼元とmTLSの設定

社内プロキシが自前の証明書で通信を中継する環境では、Claude Codeがどの証明書を信頼するかが分かれ目になります。信頼元はCLAUDE_CODE_CERT_STOREで切り替えます。カンマ区切りで、bundledは同梱のMozilla CA、systemはOSの証明書ストアを指し、既定はbundled,systemです。

export CLAUDE_CODE_CERT_STORE=system

この変数にはsettings.jsonの専用キーが無く、~/.claude/settings.jsonのenvブロックか、プロセスの環境変数として渡します。

クライアント証明書で認証するmTLS環境では、CLAUDE_CODE_CLIENT_CERTに証明書、CLAUDE_CODE_CLIENT_KEYに秘密鍵のパスを指定します。鍵にパスフレーズがあればCLAUDE_CODE_CLIENT_KEY_PASSPHRASEも使います。証明書は起動時に読み込まれ、設定を適用し直すたびに再読み込みされます。

証明書を更新するときは、同じパスのファイルを差し替えます。v2.1.232以降は、接続のリセットやTLSハンドシェイクの失敗でAPIリクエストが落ちると、両方のファイルを読み直して再試行します。ゲートウェイが接続を切った場合は読み直しますが、ハンドシェイクを完了してHTTPエラーを返した場合は読み直さず、次の設定適用か再起動で反映されます。

プロキシ設定の書き方でつまずきやすい点

変数名が出ていても、値の書き方が原因のことがあります。書式は公式のネットワーク設定に沿ったものです。なお、プロキシURLが解釈できない値(http://スキームが無いなど)だと、起動時に直すべき変数名つきの別のエラーで止まります。このエラーとは切り分けられます。

export HTTPS_PROXY=http://username:password@proxy.example.com:8080
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"

• 認証つきプロキシ: 資格情報はプロキシURLに含めます。スクリプトに直書きせず、環境変数や安全な資格情報の保管場所から渡します。
• NO_PROXY: スペース区切りとカンマ区切りのどちらも書けます。*ならすべてのリクエストがプロキシを迂回します。
• SOCKSプロキシ: 非対応です。SOCKSしかない環境では、HTTP(S)で受けるプロキシが要ります。

バックグラウンドエージェントを使う場合は、設定の置き場所にも注意が要ります。バックグラウンドのセッションは、専用のスーパーバイザープロセスが代わりに起動します。このプロセスは、最初に起動したシェルの環境変数だけを引き継ぎます。プロキシやCAの変数をシェルでexportしただけだと、どのシェルが先に起動したかで届いたり届かなかったりします。~/.claude/settings.jsonか管理設定のenvブロックに書けば、すべてのセッションに反映されます。

対処の順番

メッセージにプロキシ変数名が出ているかで、最初の一手が変わります。

よくある質問

失敗したら自動でリトライされますか

公式の説明に、この初回チェックの自動リトライは書かれていません。猶予の10秒を過ぎれば、そのままメッセージを表示して終了します。

claude --debugは役に立ちますか

claude --debugで起動すると、NODE_EXTRA_CA_CERTSやmTLSの証明書が読み込まれたかがデバッグログに残ります。ログは端末ではなく~/.claude/debug/<セッションID>.txtに出ます。サインイン後であれば、/statusのProxy行で有効なプロキシURLを確認できます。

まとめ

ゲートウェイ構成を取っている組織では、v2.1.247以降ならこのチェック自体が走りません。その環境でこの文言に当たったなら、管理設定が意図どおり効いているかを最初に見る手がかりになります。それ以外の環境では、証明書の文言なら信頼するCAの設定、コード付きの接続失敗ならネットワーク経路、と原因の置き場所が分かれます。