目次
会社のPCやVPN越しで Claude Code を使おうとして、こんなエラーで繋がらなかった経験はないだろうか:
# いまの表示(例)
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
# 以前のバージョンの表示
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
Check your proxy or corporate SSL certificates
表示の文言はバージョンで変わっている。v2.1.227 からは、以前 Unable to connect to API (ECONNREFUSED) のようにコードを付けるだけだったメッセージが、Connection refused — や Can't reach the API server — のように失敗の種類を先に言う形になった(対応表は§2)。どちらの文言でも、起きていることと直し方は同じだ。
これらは 「Claude Code が Anthropic のサーバ(api.anthropic.com)まで“到達できない”」ネットワーク系のエラーだ。認証(401/403)でも、サーバ過負荷(529/500)でも、レート制限(429)でもない——そもそもサーバに届いていない。原因の多くは 社内プロキシ・TLS検査(証明書)・ファイアウォールで、企業ネットワークで特に起きやすい。本記事では、プロキシ設定・社内CA証明書・許可すべきドメイン・切り分け手順を、公式情報をもとに整理する。
先に要点。① プロキシ越しなら HTTPS_PROXY を設定する。② TLS検査(Zscaler等)で証明書エラーなら NODE_EXTRA_CA_CERTS に社内CAを指定——絶対に NODE_TLS_REJECT_UNAUTHORIZED=0 で検証を無効化しない(全通信が傍受リスクに晒される)。③ まず curl -I https://api.anthropic.com で“そもそも届くか”を確認するのが切り分けの起点だ。
サーバまで“届いていない”
— どこで止まったかで、直し方が決まる
HTTPS_PROXYNODE_EXTRA_CA_CERTS
まず curl -I https://api.anthropic.com で到達できるかを確認。
止まる場所(プロキシ/TLS/FW)が分かれば、当てる設定が決まる。
1. このエラーは何を言っているのか
Unable to connect to API や fetch failed、ECONNREFUSED / ETIMEDOUT(v2.1.227 以降は Connection refused — などの文言。§2)は、「リクエストが Anthropic のサーバまで届かなかった」=TCP/TLS/DNS のどこかで失敗したという意味だ。ここが他のエラーと決定的に違う点:認証(401/403)・サーバ(529/500)・レート(429)は“サーバに届いた上での”応答だが、ネットワーク系は そもそも届いていない。
企業ネットワークで詰まる典型は3層に分かれる。① プロキシ——直接外に出られず、社内プロキシ経由が必須なのに未設定。② TLS検査(証明書)——Zscaler 等の検査プロキシが証明書を差し替えるため、社内ルートCAを信頼させる必要がある。③ ファイアウォール——必要なドメインが許可されていない。まずやるべきは curl -I https://api.anthropic.com で“到達できるか”を確かめること——これで「ネットワークの問題か、それ以外か」が一発で切り分けられる。
どこで止まったか=当てる設定
ECONNREFUSED/ETIMEDOUT/fetch failed。社内プロキシ経由が必要 → HTTPS_PROXY を設定。SSL certificate verification failed/self-signed → 社内CAを NODE_EXTRA_CA_CERTS に。検証無効化はNG。Could not resolve host/ENOTFOUND。DNS不通・VPN残骸・Dockerが横取り等。
curl -I https://api.anthropic.com が通れば、問題はClaude Codeとネットワークの間に絞れる。
2. 表示別の意味(v2.1.227 以降の文言)
公式のエラーリファレンスによると、この系統のメッセージはTCP 接続が失敗したか、完了しなかったことを示す。よくあるエラーコードについては、失敗の種類を文章で示し、コードを括弧に残す。いまの表示は次のとおりだ。
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
v2.1.227 より前は、これらのコード付きメッセージがどれも Unable to connect to API +コードだった(例:Unable to connect to API (ECONNREFUSED))。いまも Claude Code が知らないコードは、この形で表示される。また同じメッセージに別のコードが付くことがあり、Connection refused には ConnectionRefused か ECONNREFUSED、Can't reach the API server には ENOTFOUND か FailedToOpenSocket が付く。
| 表示の先頭 | メッセージが示すこと | まず確かめること |
|---|---|---|
Connection refused — | 接続を拒否された、ファイアウォールかプロキシが遮っている可能性 | 許可ドメイン(§5)と HTTPS_PROXY(§3) |
Can't reach the API server — | API サーバに届かない、インターネット接続か DNS を疑う | DNS と VPN、WSL なら /etc/resolv.conf(§6) |
No internet route — | 宛先への経路が無い | 回線と VPN の接続状態 |
Couldn't connect through your proxy | プロキシがトンネルを拒否した | プロキシの資格情報と、接続先のホストを通す設定か |
Connection dropped | 接続がリセットされた(ECONNRESET) | プロキシとネットワークの安定性 |
どの表示でも、一時的な失敗は自動で再試行されるので、画面に出た時点で再試行は済んでいる。繰り返し出るなら、原因は手元のネットワークにある。よくある原因として公式は、インターネットに出られない、VPN が api.anthropic.com を遮っている、必須の社内プロキシが未設定、を挙げている。直し方は§3〜§6。
Unable to connect to Anthropic services(初回セットアップ)
初回起動のセットアップでは、サインインの画面を出す前に api.anthropic.com と platform.claude.com に届くかを確かめる。どちらかが失敗すると、理由を表示して終了する。公式の表示例は次のとおり。
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.
この確認は API リクエストと同じプロキシ設定を通り、1回ごとに10秒で打ち切る。プロキシ経由で失敗したときは、そのプロキシを設定した環境変数(HTTPS_PROXY など)の名前が表示される。対処は次のとおり。
- 表示された変数の値が正しいプロキシを指しているかを確かめ、表示されたホストへの HTTPS 接続を通すようネットワーク担当に依頼する(許可ドメインは§5)。
- §6 の
curlによる到達確認を、同じシェルで行う。 https://で始まるプロキシURLの環境でChecking connectivity...のまま止まるなら、v2.1.222 より前の不具合の可能性がある(確認が API と別の経路を通り、時間切れも無かった)。更新する。- 組織がクラウドゲートウェイ(Claude apps gateway)でサインインする構成なのに初回にこのエラーが出るなら、v2.1.247 以降へ更新する。
ネットワークが開いているのに続く場合について、公式はClaude Code が利用できない国・地域である可能性を挙げている。対応国・地域の一覧で確かめてほしい。
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.
これは「届いていない」のではなく、途中の機器が応答を変えたときの警告だ。モデル提供元からのストリーミング応答が、使えるデータを1つも届けないまま終わったため、Claude Code がストリーミングなしで送り直してターンを続けた。影響を受けたリクエストは、空のストリーミングと再送の2回送られる。公式によれば主な原因は、ストリーミングの応答本文を途中で消費・変換するプロキシやゲートウェイで、対処は Claude Code とモデル提供元の間にあるプロキシ・ゲートウェイを、ストリーミング応答の本文とヘッダーを加工せずに通す設定にすることだ。表示は対話セッションだけで、1セッションに1回。v2.1.239 より前は、表示せずにストリーミングなしで再試行していた。
3. プロキシの設定(HTTPS_PROXY)
社内プロキシ経由が必須の環境では、標準的なプロキシ環境変数を設定する。Claude Code はこれらを尊重する。
# 推奨:HTTPS プロキシ
export HTTPS_PROXY=http://proxy.example.com:8080
# HTTPSが無ければ HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# プロキシを通さない宛先(スペース or カンマ区切り)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"
# 認証付きプロキシ(パスワードのハードコードは避ける)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080
注意点:SOCKS プロキシは非対応。NTLM / Kerberos 認証のプロキシは、間に LLM ゲートウェイを立てて ANTHROPIC_BASE_URL をそこへ向ける構成が公式の推奨だ。これらの変数は settings.json の env ブロックにも書ける。
Claude 以外のモデル(DeepSeek・GLM・Kimi など)の窓口に ANTHROPIC_BASE_URL を向ける場合の設定・費用・注意点は、Claude Code で DeepSeek・GLM・Kimi を使う方法で説明しています。
4. TLS・社内CA証明書(最重要・安全に)
企業ネットワークで最も多いのが TLS検査プロキシ(Zscaler・Netskope・Palo Alto 等)が証明書を差し替えることによる証明書エラーだ。unable to get local issuer certificate や SELF_SIGNED_CERT_IN_CHAIN が典型。
Claude Code 自身の表示は、v2.1.273 以降、原因のコードと直し方まで含む。セッション中の API リクエストでは次のように出る。
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
/login の途中と起動時の接続確認では、同じ失敗が別の文言になる:
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.
v2.1.273 より前は、上の2つがどちらも Check your proxy or corporate SSL certificates で終わり、コードも NODE_EXTRA_CA_CERTS の案内も無かった(冒頭の旧表示)。また v2.1.199 以降、証明書の検証失敗は自動で再試行されず、最初の試行で表示される(それ以前は数分かけて再試行してから表示していた)。ハンドシェイクのタイムアウトのような一時的な TLS の失敗は、いまも再試行される。
まず前提として、近年の Claude Code は 「同梱CA+OSのトラストストア」の両方を信頼する。つまり 社内ルートCAがOSの証明書ストアに入っていれば、追加設定なしで動くことが多い(バージョンにより挙動は変わるため最新を確認)。OSストアに入っていない場合は、IT部門から受け取ったCAバンドル(PEM)を NODE_EXTRA_CA_CERTS で指定する。
# 正しい・安全なやり方:社内CAを信頼させる
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem
# クライアント証明書(mTLS)が必要なプロキシの場合
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem
⚠️ やってはいけない:TLS検証の無効化
NODE_TLS_REJECT_UNAUTHORIZED=0 で証明書検証を切ると一見“直る”が、これは絶対にNG。プロセス全体の TLS 検証が無効になり、api.anthropic.com を含む全通信が中間者攻撃(盗聴・改ざん)に晒される。資格情報やコードが漏れる重大リスク。正解はあくまで NODE_EXTRA_CA_CERTS で社内CAを“正しく信頼させる”ことだ。
インストール時点(バイナリがまだ無い段階)で証明書エラーになる場合は、curl に CA を渡す:curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash。
OAuth error: SSL certificate error (CERT_HAS_EXPIRED)
サインイン(/login の OAuth)の途中で、次の表示が出て止まることがある。下は、GitHub の issue で利用者が報告した文面そのままだ。
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.
この表示は公式のエラー一覧には載っていない。公式のSSL certificate errorsの節が例に挙げるコードは UNABLE_TO_GET_ISSUER_CERT_LOCALLY と SELF_SIGNED_CERT_IN_CHAIN だけで、期限切れの証明書は、自動再試行の説明の中で「証明書の検証失敗」の一例として触れられているにとどまる。上の文面は、GitHub の issue #71708 と #71727(どちらも2026年6月)で利用者が報告したものだ。
CERT_HAS_EXPIRED の意味:Node.js の TLS が返す証明書エラーのコードの1つで、Node.js の公式ドキュメントでは「Certificate has expired」(証明書の有効期限が切れている)と説明されている。接続先から受け取った証明書を検証したところ、有効期限を過ぎていると判定された、ということだ。有効期限は手元の PC の時刻と比べて判定される。
報告の中身:2つの issue の報告者は、プロキシも VPN も使っておらず、同じホストへ curl では問題なく接続できたと書いている(#71708 の報告者は PC の時計が正しいことも確かめている)。つまり、表示の文面が案内する「社内プロキシ・TLS 検査」に当てはまらない環境でも出ている。報告者たちは Claude Code に同梱されたランタイムを疑っており、古い版に戻したら直ったという書き込みが複数ある。ただし issue に Anthropic からの回答は無く、2つとも動きがないまま閉じられた。原因は公式には確かめられていない。2026年9月30日時点で、公式の変更履歴(CHANGELOG)にもこの症状を直したと明記した項目は見当たらない。
確かめる順番:
- PC の時計:日付・時刻・タイムゾーンが正しいか。時計が大きくずれていると、有効な証明書でも期限切れと判定されうる。
- 会社のプロキシの証明書:社内ネットワークで TLS 検査をするプロキシやセキュリティ製品を通っているなら、それが差し込む証明書(社内 CA を含む)の期限が切れていないかを IT 部門に確かめる。
NODE_EXTRA_CA_CERTS:社内 CA を信頼させる必要がある環境なら、公式のネットワーク設定が案内するとおり、IT 部門から受け取った CA バンドルをNODE_EXTRA_CA_CERTSで指定する(上の手順)。読み込まれたかは、claude --debugのログにあるCA certs: Appended extra certificates from NODE_EXTRA_CA_CERTSの行で確かめられる。- それでも出るとき:時計が正しく、プロキシも無く、
curl -I https://platform.claude.comが通るなら、上の GitHub の報告と同じ状況かもしれない。Claude Code を最新にしたうえで、issue の書き込みと変更履歴を確かめる。issue にはNODE_TLS_REJECT_UNAUTHORIZED=0で通ったという書き込みもあるが、上の囲みのとおり検証を丸ごと切るので使わない。
5. ファイアウォールの許可ドメイン
ファイアウォールで宛先を制限している場合、HTTPS(443)で次の主なドメインを許可する(公式のネットワーク要件より。MCP コネクタやプラグインなどを使うなら、公式の一覧にある他のホストも要る)。
| ドメイン | 用途 |
|---|---|
api.anthropic.com | Claude API リクエスト(必須) |
claude.ai | claude.ai アカウント認証 |
claude.com | claude.ai アカウントのサインインでブラウザが開くページ(claude.ai へ転送) |
platform.claude.com | Console アカウント認証、claude.ai アカウントでもトークンの発行・更新に使う(初回セットアップの接続確認の対象) |
downloads.claude.ai | インストーラ・自動更新・プラグイン |
raw.githubusercontent.com | /release-notes の変更履歴 |
運用テレメトリとエラー報告の送信先(http-intake.logs.us5.datadoghq.com・browser-intake-us5-datadoghq.com)は任意で、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で両方とも止められる(必須の許可リストには含めなくてよい)。npm でインストールした場合、downloads.claude.ai のうちインストーラと自動更新の用途は要らないが、代わりにパッケージの取得先 registry.npmjs.org が要る。具体的なドメインやIP範囲は改定されうるため、最新は公式のネットワーク設定ページで確認すること。
6. 切り分けワークフロー
「繋がらない」ときは、上から順に。最初の curl でほぼ方向が決まる。
上から順に切り分ける
curl -I https://api.anthropic.com(Windowsは curl.exe)で到達確認。通れば問題は手元側に絞れる。/doctor(起動しないなら claude doctor)とプロキシ環境変数を確認。NODE_EXTRA_CA_CERTS、プロキシ未設定なら HTTPS_PROXY を当てる。curl は通るのに Claude Code が失敗するなら、DNS(WSLの resolv.conf)・VPN残骸・Docker等の横取りを疑う。
鉄則:「まず到達確認(curl)→ 止まった層に設定を当てる」。
証明書は NODE_EXTRA_CA_CERTS で。検証無効化は決してしない。
7. 紛らわしいエラーとの区別
「止まった」は、ネットワーク以外のこともある。「サーバに届いたか」で大きく分かれる。
| 症状 | 正体 | 主な対処 |
|---|---|---|
| Unable to connect / Connection refused / Can't reach the API server / fetch failed / 証明書エラー | 本記事=ネットワーク(サーバに届いていない) | HTTPS_PROXY / NODE_EXTRA_CA_CERTS / FW許可 |
| 401 / 403 / Invalid API key | 認証(届いたが資格情報の問題) | 認証・ログインエラー |
| 529 / 500 | サーバ側(届いたがサーバが過負荷・内部エラー) | 529/500エラー |
| 429 Request rejected | レート制限(届いたが流量超過) | 流量を落とす・待つ |
| Connection lost mid-response(v2.1.227 より前は Connection closed mid-response) | ストリーム中の切断(届いて応答も流れ始めた後に接続が閉じた) | 応答が途中で切れるエラー(旧表記の記事) |
覚え方:ネットワーク系は「サーバに届いていない」(TCP/TLS/DNS)のが本質で、HTTPS_PROXY や NODE_EXTRA_CA_CERTS が効くのはこの層だけ。一方 401/403・529/500・429 は“届いた上での応答”なので、プロキシやCAをいじっても直らない。curl が通るかどうかが、両者を分ける一番の手がかりだ。その他の頻出エラーは エラー集にまとまっている。
まとめ
Claude Code の ネットワーク・プロキシエラー(Unable to connect / fetch failed / SSL certificate verification failed 等)は、リクエストがサーバまで届いていない=TCP/TLS/DNSの失敗だ。認証(401/403)・サーバ(529/500)・レート(429)とは別物で、企業ネットワークの プロキシ・TLS検査・ファイアウォールが主因になりやすい。v2.1.227 以降は Connection refused — や Can't reach the API server — のように失敗の種類を先に言う文言で表示され、初回セットアップでは Unable to connect to Anthropic services で終了する。
対処は ① プロキシ越しなら HTTPS_PROXY(SOCKS非対応・NTLM/Kerberosはゲートウェイ)② 証明書エラーは NODE_EXTRA_CA_CERTS に社内CA——NODE_TLS_REJECT_UNAUTHORIZED=0 は厳禁 ③ ファイアウォールは api.anthropic.com 等を許可。切り分けは まず curl -I https://api.anthropic.com で到達確認 → /doctor・プロキシ確認 → 証明書/プロキシ設定 → 直接接続で確定 → DNS/VPN/Docker。「サーバに届いたか」で認証・サーバ・レートと切り分けるのが要点だ。関連:認証・ログインエラー、529/500エラー、Claude Codeエラー集。
FAQ
Q. 会社のPCで「Unable to connect to API」が出て繋がりません。
A. 多くは社内プロキシ経由が必須なのに未設定です。まず curl -I https://api.anthropic.com で到達できるかを確認し、ダメなら export HTTPS_PROXY=http://proxy.example.com:8080 のようにプロキシを設定してください(認証付きなら user:password@ を付与)。SOCKSは非対応、NTLM/Kerberosのプロキシは LLM ゲートウェイ経由が公式推奨です。
Q. 「Can't reach the API server」「Connection refused」は、以前の「Unable to connect to API」と別のエラーですか?
A. 同じ系統で、v2.1.227 で文言が変わっただけです。以前は Unable to connect to API (ECONNREFUSED) のようにコードを付けるだけでしたが、いまは Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) や Can't reach the API server — check your internet or DNS (ENOTFOUND) のように失敗の種類を先に示します。括弧の中のコードで原因の見当がつくので、§2 の表で対応する確認先を見てください。
Q. 初回起動で「Unable to connect to Anthropic services」と出て終了します。
A. サインインの前に api.anthropic.com と platform.claude.com への接続を確かめる段階で失敗しています。表示にプロキシの変数名(HTTPS_PROXY など)が出ていれば、その値と、表示されたホストへの接続が許可されているかをネットワーク担当に確認してください。curl -I https://api.anthropic.com で到達確認もできます。ネットワークが開いているのに続く場合、公式は Claude Code が利用できない国・地域である可能性を挙げており、公式の対応国一覧で確かめられます。
Q. 「SSL certificate verification failed」と出ます。
A. 社内の TLS検査プロキシ(Zscaler等)が証明書を差し替えているのが典型です。IT部門から社内ルートCA(PEM)を受け取り、export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem で指定してください。社内CAがOSの証明書ストアに入っていれば、設定なしで動くこともあります。絶対に NODE_TLS_REJECT_UNAUTHORIZED=0 で検証を切らないでください——全通信が傍受リスクに晒されます。
Q. NODE_TLS_REJECT_UNAUTHORIZED=0 にしたら直りました。これで良いですか?
A. ダメです、今すぐ戻してください。これはTLS証明書の検証をプロセス全体で無効化するため、api.anthropic.com を含むすべての通信が中間者攻撃(盗聴・改ざん)に対して無防備になります。資格情報やソースコードの漏洩につながる重大なセキュリティリスクです。正しい解決は NODE_EXTRA_CA_CERTS で社内CAを正しく信頼させることだけです。
Q. ファイアウォールでどのドメインを許可すればいいですか?
A. HTTPS(443)で最低限 api.anthropic.com(API)、claude.ai・claude.com・platform.claude.com(認証)、downloads.claude.ai(インストーラ・更新)、raw.githubusercontent.com(変更履歴)を許可します。運用テレメトリとエラー報告(Datadog)は任意です。具体的なドメイン/IPは改定されうるので、最新は公式のネットワーク設定ページで確認してください。
Q. curl は通るのに Claude Code だけ繋がりません。
A. Claude Code と OS の間に原因があることが多いです。WSL の /etc/resolv.conf が不通のDNSを指している、VPNの残骸(macOSの古い utun 等)、Docker など常駐ツールが通信を横取り、といったケースです。VPNを切って直接接続で試す、常駐ツールを一度止める、DNSを見直す、の順で切り分けてください。なお 5xx 系の一時障害は最大10回まで自動リトライされるため、curl が通るのにエラー表示が出た時点で、リトライは使い切られています。