Claude Code「Can't reach the API server」「Connection refused」の原因と対処

API Error: Can't reach the API server — check your internet or DNS (ENOTFOUND)
API Error: Connection refused — a firewall or proxy may be blocking it (ECONNREFUSED)
API Error: Connection dropped (ECONNRESET)

これらは、Claude Code が会話のリクエストを API に送ろうとしたが、通信そのものが成立しなかったことを表すメッセージです。認証や使用量の上限、Anthropic 側の障害ではなく、手元の回線・DNS・プロキシ・ファイアウォール、または送り先の設定（ANTHROPIC_BASE_URL）のどこかで止まっています。どこで止まったかは、メッセージの書き出しと末尾のカッコ内のコードで見分けられます。

先に結論を書くと、ENOTFOUND なら DNS とインターネット接続、ECONNREFUSED ならプロキシの設定か ANTHROPIC_BASE_URL に残った古い値、ECONNRESET なら途中のプロキシやファイアウォール、ERR_PROXY_TUNNEL ならプロキシの認証と許可設定を最初に確認します。

本記事の情報について: 内容は2026年10月10日時点の公式ドキュメント（Error reference の「Unable to connect to API」「Automatic retries」、Enterprise network configuration）と、手元の Claude Code v2.1.287 での再現にもとづいています。実機で確認した内容とドキュメント記載の内容は書き分けています。

意味：API への接続そのものが成立しなかった

「Unable to connect to API」系のエラーとは、Claude Code が API との通信（TCP 接続）を始められなかった、または途中で切られたときのメッセージです。公式ドキュメントは「The TCP connection to the API failed or never completed」と説明しています（Error reference）。

v2.1.227 以降は、よくあるエラーコードについて、失敗の種類を書き出しに、コードを末尾のカッコに入れて表示します。それより前の版では、どれも Unable to connect to API (ECONNREFUSED) のように「Unable to connect to API」にコードが付くだけの表示でした（Error reference）。古い版を使っている場合や、ネット上の古い情報を見ている場合は、この表示の違いに注意してください。

表示されるまでに最大10回やり直している

このメッセージが出た時点で、Claude Code はすでに自動でやり直しを済ませています。公式ドキュメントによると、一時的な失敗は指数的に間隔を空けながら最大10回やり直し、それでも失敗したときにエラーを表示します（Error reference の「Automatic retries」）。やり直しの間は、スピナーに Retrying in Ns · attempt x/y のカウントダウンが出ます。

つまり、表示されたあとにすぐ同じメッセージを送り直しても、多くの場合は同じ結果になります。一時的な瞬断ではなく、設定や環境に原因があると考えて、下の手順で切り分けてください。やり直しの回数は環境変数 CLAUDE_CODE_MAX_RETRIES（既定は10）で変えられ、スクリプトで失敗を早く知りたいときは小さくするよう案内されています（同「Tune retry behavior」）。

表示の書き出しで、止まった場所を読み分ける

書き出しの英文と末尾のコードは、通信が止まった場所に対応しています。v2.1.287 の実行ファイルに含まれる処理を確認したところ、コードと表示の対応は次のとおりでした（最後の Request timed out の行は、Error reference の表示例にもとづきます）。

Connection refused の末尾は ECONNREFUSED と ConnectionRefused のどちらの場合もあり、Can't reach the API server の末尾は ENOTFOUND と FailedToOpenSocket のどちらの場合もあると公式ドキュメントにも書かれています（Error reference）。

上の図のとおり、Connection refused はプロキシと接続先、Connection dropped は途中の機器と接続先というように、同じ表示が複数の場所で起こりえます。プロキシを使っていない場合は、まず送り先（ANTHROPIC_BASE_URL を設定していればその宛先）を疑います。

実機での再現結果

2026年10月10日に、macOS 上の Claude Code v2.1.287 で、ログイン情報のない新しい設定ディレクトリ（CLAUDE_CONFIG_DIR）とダミーの API キーを使い、手元のパソコンの中だけで通信が失敗するように送り先やプロキシを指定して、非対話モード（claude -p）で再現しました。本物のログイン情報は使っておらず、リクエストは外部に送られていません。表示を早く確かめるため、CLAUDE_CODE_MAX_RETRIES=1 でやり直しを1回にしています。

再現からわかったことは次のとおりです。

• 送り先の誤りとプロキシの停止は、同じ Connection refused になる。表示だけではどちらか区別できないため、HTTPS_PROXY と ANTHROPIC_BASE_URL の両方を確認する
• プロキシが認証を求めた場合（407）も、中継を拒否した場合（403）も、表示は同じ ERR_PROXY_TUNNEL だった。認証情報の誤りと、許可リストの不足は表示で区別できない
• ECONNRESET は、送り先でもプロキシでも同じ表示になった

最初の2つは、次のように手元で追試できます（127.0.0.1 の9番ポートは通常何も動いていません）。ふだんの設定やログイン情報を使わないよう、新しい設定ディレクトリとダミーのキーを指定しています。

env CLAUDE_CONFIG_DIR="$(mktemp -d)" ANTHROPIC_API_KEY=dummy \
  CLAUDE_CODE_MAX_RETRIES=1 ANTHROPIC_BASE_URL=http://127.0.0.1:9 \
  claude -p "hi"

なお、通信を制限するサンドボックス（macOS の隔離環境）の中から同じコマンドを実行したところ、表示は API Error: Unable to connect to API (EPERM) でした。EPERM は「その操作が許可されていない」という意味のコードで、上の表の分類にないため Unable to connect to API にコードが付く形になります。エディタの拡張機能、CI、コンテナなど、Claude Code を通信制限のある環境から起動している場合は、この表示になることがあります。その環境の通信の許可設定を確認してください。

まず curl で、API に届くか確かめる

Claude Code を起動するのと同じターミナル（同じ環境変数）で、次のコマンドを実行します。公式ドキュメントが最初の確認として案内している方法です（Error reference）。

curl -I https://api.anthropic.com

Windows の PowerShell では、curl が別のコマンド（Invoke-WebRequest）の別名になっているため、curl.exe と書きます。

curl.exe -I https://api.anthropic.com

結果の読み方は次のとおりです。

応答のステータス番号そのもの（404 など）は気にしなくてかまいません。何らかの HTTP 応答が返れば、通信経路は通っているという意味です。

ただし curl と Claude Code は、プロキシの環境変数の読み方が違います。Claude Code は https_proxy → HTTPS_PROXY → http_proxy → HTTP_PROXY の順に、最初に見つかったものを使います（Enterprise network configuration）。一方 curl は https の URL に http_proxy を使いません。また、Claude Code の settings.json の env に書いたプロキシは curl には効きません。結果が食い違うときは、この違いを疑ってください。

curl は通るのに Claude Code だけ失敗するとき

公式ドキュメントは、curl が成功するのに Claude Code が失敗する場合、原因はネットワークそのものより手元の設定や実行環境にあることが多いとして、次の確認を挙げています（Error reference）。

ANTHROPIC_BASE_URL に古い値が残っていないか

ANTHROPIC_BASE_URL は、Claude Code がリクエストを送る先を api.anthropic.com から別のアドレスに変える環境変数です。社内の LLM ゲートウェイや、検証で立てたローカルのプロキシを使ったときの値が残っていると、そのゲートウェイを止めたあとも Claude Code はそこに送り続け、Connection refused になります。curl は api.anthropic.com に直接アクセスするので成功し、食い違いが生まれます。

echo $ANTHROPIC_BASE_URL

PowerShell では echo $env:ANTHROPIC_BASE_URL です。値が出たら、シェルの設定ファイル（~/.zshrc など）と、Claude Code の設定ファイル（~/.claude/settings.json、プロジェクトの .claude/settings.json と .claude/settings.local.json）の env ブロックを探し、不要なら削除して新しいターミナルから起動し直します。公式ドキュメントによると、シェルで設定した環境変数は起動時に一度だけ読まれ、実行中のセッションには後からの変更が反映されません（Enterprise network configuration）。

Linux・WSL の DNS 設定

Linux と WSL では、/etc/resolv.conf に到達できない DNS サーバーが書かれていないかを確認します。公式ドキュメントは、WSL は Windows 側から壊れた DNS 設定を引き継ぐことがあると注意しています（Error reference）。

macOS の VPN の残骸

macOS では、切断・アンインストールした VPN のトンネル（utun という名前のネットワークインターフェース）や経路の設定が残っていることがあります。ifconfig で古い utun が残っていないかを確認し、不要な VPN のネットワーク拡張をシステム設定から削除します（Error reference）。

Docker Desktop などのコンテナ環境

Docker Desktop などは、パソコンから外への通信を横取りすることがあります。公式ドキュメントは、いったん終了してから試し、原因から外すよう案内しています（Error reference）。

原因別の直し方

Can't reach the API server（ENOTFOUND）のとき

名前解決に失敗しています。次の順に確認します。

1. ブラウザなどで、ほかのサイトに接続できるか（回線そのものが切れていないか）
2. ANTHROPIC_BASE_URL を設定しているなら、ホスト名の綴りが正しいか
3. nslookup api.anthropic.com（または dig api.anthropic.com）で IP アドレスが返るか
4. Linux・WSL なら /etc/resolv.conf、macOS なら VPN の残骸（上の節）

2026年10月10日に確認した時点で、api.anthropic.com を引くと IPv4・IPv6 の両方のアドレスが返りました。nslookup でアドレスが返らない場合は、DNS の問題と判断できます。末尾が EAI_AGAIN の場合は、DNS サーバーが一時的に応答しなかったことを表すコードで、同じ表示になります。

No internet route（EHOSTUNREACH など）のとき

送り先までの経路がない状態です。公式ドキュメントの表示例でも、案内は「接続か VPN を確認」です。回線が切れていないか、VPN が中途半端な状態で接続されていないかを確認し、VPN をいったん切断・再接続して試します。

GitHub には、macOS で Tailscale などの VPN を使っていて IPv6 の経路だけが壊れている環境で、Claude Code が Unable to connect to API (ConnectionRefused) で失敗し続けたという報告があります（anthropics/claude-code #69104。v2.1.179。原因の分析は報告者のもので、issue は修正されないまま自動でクローズされています）。報告者は、curl やブラウザは IPv4 に切り替えて成功する一方、Claude Code は IPv6 での接続を試して失敗し続けたと説明しています（報告者が IPv6 アドレスへ直接接続を試すと EHOSTUNREACH になったとのこと）。Claude Code の表示には接続先のアドレスは出ないため、curl は通るのに Claude Code だけ Connection refused になり、VPN が IPv6 の経路を追加している場合は、VPN の IPv6 設定を確認してください。報告者は /etc/hosts で IPv4 アドレスに固定する回避策を書いていますが、アドレスが変わると逆に接続できなくなるため、恒久的な対処にはしないでください。

Connection refused（ECONNREFUSED）のとき

接続先のアドレスには届いたものの、そのポートで接続を受け付けなかった状態です。実機の再現どおり、原因は大きく2つです。

1. プロキシの設定が残っている・プロキシが止まっている：echo $HTTPS_PROXY（小文字の https_proxy も）で値を確認します。プロキシを使わない環境なら削除し、使う環境ならアドレスとポートが正しいか、プロキシが動いているかを確認します
2. ANTHROPIC_BASE_URL の宛先が動いていない：上の「ANTHROPIC_BASE_URL に古い値が残っていないか」を確認します。ゲートウェイを使う運用なら、ゲートウェイが起動しているかを確認します

社内ネットワークで、プロキシ経由でしか外に出られない場合は、Claude Code を起動する前に HTTPS_PROXY を設定します（Enterprise network configuration）。

export HTTPS_PROXY=http://proxy.example.com:8080
claude

公式ドキュメントに記載のある注意点は次のとおりです。

• 認証が必要なプロキシは http://ユーザー名:パスワード@proxy.example.com:8080 の形で指定する（パスワードをスクリプトに直接書かない）
• SOCKS プロキシには対応していない
• NTLM や Kerberos など高度な認証が必要なプロキシは、それに対応した LLM ゲートウェイの利用が案内されている
• プロキシを通さない宛先は NO_PROXY に、カンマまたはスペース区切りで書ける
• プロキシの URL が解釈できない値（http:// が抜けているなど）の場合は、起動時にその環境変数名を示すエラーで止まる

対話モードで /status を実行すると、Proxy の行に、いま使われているプロキシの URLが表示されます。解釈できない値の場合は無効として無視されたことが示されます（Enterprise network configuration）。設定したつもりの値が Claude Code に届いているかを確かめるのに使えます。

Couldn't connect through your proxy（ERR_PROXY_TUNNEL）のとき

プロキシには届いたものの、プロキシが目的のホストへの中継を断った状態です。表示の後半のとおり、プロキシの認証情報と、プロキシでそのホストが許可されているかを確認します。実機の再現では、認証の要求（407）でも拒否（403）でも同じ表示だったため、両方を確認してください。

社内のプロキシやファイアウォールで通信先を絞っている場合は、ネットワーク担当者に少なくとも次のホストへの HTTPS 通信の許可を依頼します（Enterprise network configuration の「Network access requirements」から、ログインと利用に関わるものを抜粋）。

公式の一覧には、ほかにも MCP コネクタ、プラグイン、npm でのインストールなどに使うホストが載っています。使う機能に合わせて一覧全体を確認してください。

Connection dropped（ECONNRESET など）のとき

いったんつながった接続が、途中で切られた状態です。ときどき出るだけなら、Claude Code が自動でやり直すので気にしなくてかまいません。毎回出る場合は、次を確認します。

• 社内のプロキシや、通信を検査するセキュリティ製品が接続を切っていないか（プロキシを経由しない回線で試せるなら比べる）
• ANTHROPIC_BASE_URL でゲートウェイを使っている場合、ゲートウェイ側のログにエラーが出ていないか
• 通信を検査する機器を使う環境で、証明書のエラーが出ていないか（「SSL certificate verification failed」の対処法）

公式 CHANGELOG によると、v2.1.198 で、応答の途中の短い切断（ECONNRESET など）でターンを止めずに間隔を空けてやり直すよう改善されています。古い版で頻発する場合は claude update で更新してください。

その他のコード（Unable to connect to API (コード)）のとき

上の分類にないコードは、Unable to connect to API の後ろにそのコードが付いて表示されます。実機では、通信を制限するサンドボックスの中から起動したときに EPERM になりました。EPERM・EACCES のように権限を表すコードなら、Claude Code を起動している環境（サンドボックス、セキュリティ製品、コンテナ）の通信の制限を確認します。

古いバージョン・プロキシ関連の修正

まず claude --version で版を確認してください。公式 CHANGELOG と Error reference には、この系統のエラーに関わる次の変更が記載されています。

HTTPS_PROXY と NO_PROXY を両方設定しているのに、サインイン（/login）などで NO_PROXY が効かずにプロキシ経由で送られてしまう場合は、v2.1.292 以降に更新してから試し直してください。この修正の対象は、サインイン・ポリシー・フィードバック・アーティファクトの通信です。

似ているが別のエラー

接続まわりのエラーは、出る場面で原因と対処が変わります。

そのほかのエラーはClaude Code エラー一覧と対処法から表示文で逆引きできます。Docker の中で Claude Code を動かしている場合のネットワーク設定は、Claude Code × Docker活用ガイドも参考にしてください。

よくある質問

まとめ

• 「Can't reach the API server」「Connection refused」「Connection dropped」などは、Claude Code が API との通信そのものを成立させられなかったという意味で、最大10回の自動のやり直しのあとに表示される
• 書き出しと末尾のコードで止まった場所を読み分ける。ENOTFOUND は DNS、EHOSTUNREACH は経路・VPN、ECONNREFUSED はプロキシか送り先、ERR_PROXY_TUNNEL はプロキシの認証・許可、ECONNRESET は途中の機器か送り先
• 最初に同じターミナルで curl -I https://api.anthropic.com を実行し、届くなら ANTHROPIC_BASE_URL・プロキシの環境変数・WSL の DNS・VPN の残骸・Docker を確認する
• 手元の再現では、送り先の誤りとプロキシの停止はどちらも Connection refused、プロキシの認証要求と拒否はどちらも ERR_PROXY_TUNNEL で、表示だけでは区別できなかった

参考：

• https://code.claude.com/docs/en/errors
• https://code.claude.com/docs/en/network-config
• https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• https://github.com/anthropics/claude-code/issues/69104