目次

会社のPCやVPN越しで Claude Code を使おうとして、こんなエラーで繋がらなかった経験はないだろうか：

Unable to connect to API. Check your internet connection
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
  Check your proxy or corporate SSL certificates
fetch failed

これらは 「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 で“そもそも届くか”を確認するのが切り分けの起点だ。

CLAUDE CODE · NETWORK / PROXY

サーバまで“届いていない”

— どこで止まったかで、直し方が決まる

💻
Claude Code
→✗
社内プロキシ / TLS検査 / FW
ここで遮断されやすい
→
☁️
api.anthropic.com
プロキシ
HTTPS_PROXY
TLS証明書
NODE_EXTRA_CA_CERTS
FW許可
api.anthropic.com 他

まず curl -I https://api.anthropic.com で到達できるかを確認。
止まる場所（プロキシ／TLS／FW）が分かれば、当てる設定が決まる。

1. このエラーは何を言っているのか

Unable to connect to API や fetch failed、ECONNREFUSED / ETIMEDOUT は、「リクエストが Anthropic のサーバまで届かなかった」＝TCP/TLS/DNS のどこかで失敗したという意味だ。ここが他のエラーと決定的に違う点：認証（401/403）・サーバ（529/500）・レート（429）は“サーバに届いた上での”応答だが、ネットワーク系は そもそも届いていない。

企業ネットワークで詰まる典型は3層に分かれる。① プロキシ——直接外に出られず、社内プロキシ経由が必須なのに未設定。② TLS検査（証明書）——Zscaler 等の検査プロキシが証明書を差し替えるため、社内ルートCAを信頼させる必要がある。③ ファイアウォール——必要なドメインが許可されていない。まずやるべきは curl -I https://api.anthropic.com で“到達できるか”を確かめること——これで「ネットワークの問題か、それ以外か」が一発で切り分けられる。

3 LAYERS

どこで止まったか＝当てる設定

① プロキシ未設定
ECONNREFUSED/ETIMEDOUT/fetch failed。社内プロキシ経由が必要 → HTTPS_PROXY を設定。
② TLS検査で証明書エラー
SSL certificate verification failed/self-signed → 社内CAを NODE_EXTRA_CA_CERTS に。検証無効化はNG。
③ FWでドメイン遮断
必要ドメインが未許可 → api.anthropic.com 等を許可（§4）。
④ DNS / VPN / 社内ツール
Could not resolve host/ENOTFOUND。DNS不通・VPN残骸・Dockerが横取り等。

curl -I https://api.anthropic.com が通れば、問題はClaude Codeとネットワークの間に絞れる。

2. プロキシの設定（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 をそこへ向ける構成が公式の推奨だ。また MCP サーバを使う場合、各サーバの env に HTTPS_PROXY と NODE_EXTRA_CA_CERTS を明示する必要がある（親から継承されない）。これらの変数は settings.json の env ブロックにも書ける。

3. TLS・社内CA証明書（最重要・安全に）

企業ネットワークで最も多いのが TLS検査プロキシ（Zscaler・Netskope・Palo Alto 等）が証明書を差し替えることによる証明書エラーだ。unable to get local issuer certificate や SELF_SIGNED_CERT_IN_CHAIN が典型。

まず前提として、近年の 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。

4. ファイアウォールの許可ドメイン

ファイアウォールで宛先を制限している場合、HTTPS（443）で次のドメインを許可する（公式のネットワーク要件より）。

ドメイン用途
api.anthropic.comClaude API リクエスト（必須）
claude.aiclaude.ai アカウント認証
platform.claude.comConsole アカウント認証
downloads.claude.aiインストーラ・自動更新・プラグイン
raw.githubusercontent.comリリースノート・マーケットプレイス

テレメトリ（statsig.anthropic.com）やエラー報告（*.sentry.io）は任意で、無効化もできる（必須の許可リストには含めなくてよい）。npm 等で自前管理する場合は downloads.claude.ai が不要なこともある。具体的なドメインやIP範囲は改定されうるため、最新は公式のネットワーク設定ページで確認すること。

5. 切り分けワークフロー

「繋がらない」ときは、上から順に。最初の curl でほぼ方向が決まる。

DIAGNOSE

上から順に切り分ける

1
curl -I https://api.anthropic.com（Windowsは curl.exe）で到達確認。通れば問題は手元側に絞れる。
2
/doctor（起動しないなら claude doctor）とプロキシ環境変数を確認。
3
証明書エラーなら NODE_EXTRA_CA_CERTS、プロキシ未設定なら HTTPS_PROXY を当てる。
4
直接接続（VPN/プロキシを切る）で試し、プロキシが原因かを確定。IT部門にURLとCAを確認。
5
curl は通るのに Claude Code が失敗するなら、DNS（WSLの resolv.conf）・VPN残骸・Docker等の横取りを疑う。

鉄則：「まず到達確認（curl）→ 止まった層に設定を当てる」。
証明書は NODE_EXTRA_CA_CERTS で。検証無効化は決してしない。

6. 紛らわしいエラーとの区別

「止まった」は、ネットワーク以外のこともある。「サーバに届いたか」で大きく分かれる。

症状正体主な対処
Unable to connect / fetch failed / 証明書エラー本記事＝ネットワーク（サーバに届いていない）HTTPS_PROXY / NODE_EXTRA_CA_CERTS / FW許可
401 / 403 / Invalid API key認証（届いたが資格情報の問題）認証・ログインエラー
529 / 500サーバ側（届いたがサーバが過負荷・内部エラー）529/500エラー
429 Request rejectedレート制限（届いたが流量超過）流量を落とす・待つ

覚え方：ネットワーク系は「サーバに届いていない」（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検査・ファイアウォールが主因になりやすい。

対処は ① プロキシ越しなら 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. 「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・platform.claude.com（認証）、downloads.claude.ai（インストーラ・更新）、raw.githubusercontent.com を許可します。テレメトリ（statsig）やエラー報告（sentry）は任意です。具体的なドメイン/IPは改定されうるので、最新は公式のネットワーク設定ページで確認してください。

Q. curl は通るのに Claude Code だけ繋がりません。
A. Claude Code と OS の間に原因があることが多いです。WSL の /etc/resolv.conf が不通のDNSを指している、VPNの残骸（macOSの古い utun 等）、Docker など常駐ツールが通信を横取り、といったケースです。VPNを切って直接接続で試す、常駐ツールを一度止める、DNSを見直す、の順で切り分けてください。なお 5xx 系の一時障害は最大10回まで自動リトライされるため、curl が通るのにエラー表示が出た時点で、リトライは使い切られています。