auth.anthropic.comのDNS解決失敗と「Can't reach the API server」の切り分け

Can't reach the API server — check your internet or DNS (ENOTFOUND)は、ホスト名の名前解決に失敗したという意味です。FailedToOpenSocketが付くときは接続そのものが張れておらず、原因はインターネット未接続・VPN・社内プロキシの設定漏れなどです。同じ端末でnslookup api.anthropic.comとcurl -I https://api.anthropic.comを実行すれば、DNSかその先の経路かを切り分けられます。

ログインするとOAuth error: timeout of 15000ms exceededで止まり、nslookupで調べるとauth.anthropic.comが存在しないドメインとして返ってくる。Issueの再現手順はclaude loginでした。現在のCLIでは/loginかclaude auth loginを使います。この症状はClaude Code v2.1.72(2026年3月)の時期に世界各地から報告されました。原因の切り分け方と、現在の公式ドキュメントが案内する認証ドメインをまとめます。

auth.anthropic.comのDNS解決失敗とはどんな症状か

症状は「ブラウザでのOAuth承認画面までは進むのに、CLI側がタイムアウトで失敗する」という形で現れます。api.anthropic.comへはcurlもAPIリクエストも通るため、一見するとネットワーク全体は生きているように見えます。

Issueに集まった報告を見ると、マレーシア・タイ・韓国・ペルー・トルコなど発生地域は一つの国や一つの企業ネットワークに限りません。共通していたのは、auth.anthropic.comだけを個別にnslookupすると、ローカルDNSでもGoogle Public DNS(8.8.8.8)でもNon-existent domain(NXDOMAIN)が返ってくる点です。

nslookup auth.anthropic.com
*** can't find auth.anthropic.com: Non-existent domain
 
nslookup auth.anthropic.com 8.8.8.8
*** dns.google can't find auth.anthropic.com: Non-existent domain

api.anthropic.comは同じ環境で正常に解決できていたという報告も複数あり、企業ファイアウォールによる意図的なブロックというより、特定ホスト名の名前解決だけが失敗する現象でした。このIssueは2026年3月11日に立ち、今もopenのままです。投稿には根本原因の断定がありません。4月6日にAnthropic側が対応中だとステータスページを示し、翌7日には解決したと思われる旨をコメントしています。

v2.1.227前後でエラーメッセージの見え方はどう変わったか

このIssueが厄介だったのは、DNSが即座にNXDOMAINを返しているにもかかわらず、CLI側の表示がtimeout of 15000ms exceededという汎用的なタイムアウトメッセージだった点です。ユーザーは自分でnslookupを実行して初めて、原因がDNSだと気づけました。

エラーリファレンスでは、API接続の失敗の表示がv2.1.227で変わっています。それ以前は接続エラーの種類によらずUnable to connect to APIに続けてエラーコードだけが表示されていました。v2.1.227以降はCan't reach the API server — check your internet or DNS (ENOTFOUND)のように、DNS起因であることがメッセージ本文からも読み取れる形式になりました。

つまりAPI接続が失敗する場合は、メッセージだけで「DNSかネットワーク経路の問題らしい」と判断できます。ただしOAuthログインのタイムアウト文言がこの形式に変わったという記載は、エラーリファレンスにもchangelogにもありません。ログインでtimeout of 15000ms exceededが出たときは、メッセージに頼らずnslookupで確かめます。ENOTFOUNDが表示されたときの一般的な対処は「Unable to connect to API」エラーの解決手順にまとめています。

Can't reach the API serverと出たときの原因と対処

このメッセージは、接続エラーのコードがENOTFOUNDかFailedToOpenSocketのときに表示されます。エラーリファレンスが挙げる原因は、インターネット未接続、api.anthropic.comを遮断するVPN、設定されていない社内プロキシです。

同じシェルでcurl -I https://api.anthropic.comを実行し、通らなければ原因は端末側かネットワーク側にあります。PowerShellではcurlがInvoke-WebRequestの別名なので、curl.exe -I https://api.anthropic.comと書きます。社内プロキシ配下なら起動前にHTTPS_PROXYを設定します。LLMゲートウェイやリレーを使う場合はANTHROPIC_BASE_URLをそのアドレスにします。断続的な失敗は自動で再試行されるため、続くときだけ調べれば足ります。

メッセージの出ないログイン側のタイムアウトは、次の節の手順でauth.anthropic.comなどを個別に引いて確かめます。

自分で切り分ける手順

公式のトラブルシューティング手順は、Claude Code自体を疑う前にシェルから直接疎通を確認することを勧めています。同じ端末で、次の順に失敗の層を絞り込みます。

実行するコマンドは次のとおりです。

nslookup auth.anthropic.com
nslookup platform.claude.com
curl -I https://platform.claude.com

WindowsのPowerShellでは組み込みエイリアスのInvoke-WebRequestがcurlとして呼ばれます。curl.exe -I https://platform.claude.comのように明示して実行します。Issueのコメントには、Ubuntu WSLで同じ症状が続いたという報告があり、WSLの中でもWindowsとは別にnslookupを実行して確かめます。

古い失敗結果がキャッシュに残っている可能性もあるため、念のためOSのDNSキャッシュを一度クリアしてから再試行するという選択肢もあります。キャッシュを消すだけの操作なので、既存の設定を変えることはありません。

• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Windows(管理者権限のターミナル): ipconfig /flushdns
• systemd-resolvedを使うLinux: sudo resolvectl flush-caches

企業プロキシ配下であれば、HTTPS_PROXYが設定されているか、その値が正しいプロキシを指しているかも合わせて確認します。プロキシ側にホスト名解決を任せたい環境向けにはCLAUDE_CODE_PROXY_RESOLVES_HOSTS=1というopt-inの環境変数が用意されており、設定するとクライアント側ではなくプロキシ側がDNS解決を行うようになります。詳しい環境変数の一覧と設定場所はクラウド環境のネットワークアクセス設定にまとめています。

設定が読み込まれているかどうかは、対話セッションで/statusを実行するとその場で確認できます。

/status

/statusはStatusタブにバージョン・モデル・アカウント・接続状況を出します。「Proxy」の行には有効なプロキシURLが表示され、パースできない値は「invalid」と示されて無視されます。

claude doctorはインストール状態の診断コマンドです。--helpには「現在のディレクトリの設定ファイルを信頼確認なしで読む」と書かれています。ネットワークの切り分けより、設定ファイルやインストール方法の異常を見る用途です。

claude doctor

devcontainerやSSH経由、WSL2でClaude Codeを使っている場合は、もう一つ確認材料があります。v2.1.126(2026年5月1日)では、低速回線・プロキシ経由・IPv6専用のdevcontainer・ブラウザコールバックがlocalhostに届かない環境でのOAuthログインタイムアウトがまとめて修正されました。あわせて、ブラウザコールバックが使えないときに認証コードを端末へ直接貼り付けてログインする経路も追加されています。今回のDNS解決失敗そのものを名指しした修正ではありませんが、これらの環境で症状が出ている場合はまずこのバージョン以降かを確認する価値があります。

ログイン画面の前で止まるのか、承認後に止まるのか

同じ「ログインできない」でも、止まる場所で見る先が変わります。Issueの症状はブラウザで承認したあとにCLIが待ち続ける形でした。一方、初回セットアップにはサインイン画面より前に走る疎通確認があり、そこで止まると別のメッセージが出ます。

この疎通確認が見に行く2つのホストに、auth.anthropic.comは含まれません。確認のプロキシ経路はAPIリクエストと同じで、v2.1.222より前は別のプロキシ方式でタイムアウトがなく、https://スキームのプロキシURLではChecking connectivity...のまま止まる場合がありました。

現在の認証ドメインはauth.anthropic.comではない

企業のファイアウォール担当者に許可を依頼するとき、古い情報のままauth.anthropic.comだけを申請してしまうと、実際に必要なドメインが漏れることになります。現在の公式ネットワーク要件ドキュメントが挙げる認証関連のドメインは次の3つで、auth.anthropic.comという名前は含まれていません。

このドキュメントはIssueが報告された後もAnthropicが更新を続けているページで、時点によって要求ドメインが変わり得ます。今auth.anthropic.comのDNS解決に失敗しているとしても、それが現行の認証フローで実際に必要なホスト名だとは限りません。まず上の3ドメインとapi.anthropic.comをnslookupで確認し、そちらが解決できているなら、ログイン自体は現在の経路で成立する可能性があります。コメントには、auth.anthropic.comがNXDOMAINのままでもログインできたという報告もあります。許可ドメインの一覧と各ドメインの用途はClaude Codeプロキシ設定にもまとめていますが、ドメインの追加・変更自体は公式のネットワーク要件ページ側で随時行われるため、ファイアウォールやプロキシの許可リストを見直す際の最終確認はそちらで行うと安心です。

forceLoginGatewayUrlをmanaged settingsで設定している組織では、上の疎通確認自体が省かれ、サインイン画面は「Cloud gateway」から始まります。ゲートウェイ経由でログインする運用では、DNSの切り分けより先にforceLoginGatewayUrlの設定が意図通りか確認したほうが早く原因にたどり着けます。

v2.1.287でログイン状態とコマンドの引数を見る

ログイン前後の状態は、ネットワークに出ずに手元で確かめられます。まっさらな設定ディレクトリでclaude auth statusを実行すると、次のように返ります(v2.1.287で確認。パスは省略)。

claude auth status

{
  "loggedIn": false,
  "authMethod": "none",
  "apiProvider": "firstParty",
  "analyticsDisabled": false,
  "configDirectory": "...",
  "projectsDirectory": "..."
}

loggedInがfalseのままなら、認証情報がそもそも保存されていません。/loginの途中で止まったのか、別の設定ディレクトリを見ているのかを分ける材料になります。JSONには、CLIが使う設定ディレクトリを示すconfigDirectoryも含まれます(v2.1.268以降)。

claude auth login --helpには、ログイン先を選ぶ2つのフラグが並びます。

• --claudeai: Claude subscriptionで認証します(既定)
• --console: Anthropic Console(API usage billing)で認証します

--consoleに切り替えても、platform.claude.comへの到達は要ります。ネットワーク要件では、Console認証はこのホストが担い、claude.aiアカウントのOAuthトークン交換や更新もこのホストに向かうためです。platform.claude.comの解決に失敗している環境では、フラグを替えてもDNSの問題は避けられません。

報告されている回避策と注意点

Issueのコメント欄には複数の応急処置が並んでいますが、リスクの大きさに差があります。この中でシステム側の設定ファイルを書き換えずに済むのはclaude install stableで安定版に切り替える方法で、複数のユーザーがこれでログインできたと報告しています。

claude install stable

OAuthでのログインだけがDNSの影響を受けている状況であれば、ANTHROPIC_API_KEY環境変数によるAPIキー認証に一時的に切り替える方法もあります。APIキーを使うリクエストの宛先はapi.anthropic.comです。ただしConsoleアカウントの認証はplatform.claude.comが担います。Issueの投稿者自身も、この方法が全員に使えるわけではないと補足しています。ブラウザ経由のログインが使えない場合の別経路として、エラーリファレンスは次の手順も挙げています。ログインが通る別のマシンでclaude setup-tokenを実行し、出力されたトークンをCLAUDE_CODE_OAUTH_TOKENとしてこの端末に設定する方法です(claude.aiサブスクリプション向け。OAuthコールバック用のポートを開けない場合の対処として書かれています)。ログイン方式ごとに何を認証し何が不要になるかはClaude Codeログイン方法3種の使い分けで比較しています。

一方、cli.js内のハードコードされたタイムアウト値(timeout:15000)をsedやSet-Contentで直接書き換える回避策も広く共有されていました。これはタイムアウトを45秒に延ばすだけの変更で、DNSが解決できない状態そのものは直りません。コメントで多いのはnpm版のcli.jsを書き換える例ですが、バイナリ版でバイナリそのものをsedやperlで置換したという報告もあります。現行のnpmパッケージも同じネイティブバイナリを入れる構成で、cli.jsは前提になりません。どの方法でも、書き換えた内容はアップデートのたびに失われます。

さらにリスクが高いのが、OSのhostsファイルにauth.anthropic.comと特定のIPアドレスを直接書き込む方法です。公式のIPアドレス一覧ページは、固定IPアドレスが「予告なく変更されることはない」と述べています。変更がないという意味ではなく、変更時には事前の告知があるという建て付けです。hostsファイルに固定したIPは、その告知が出ても自動では追従しません。恒久的な設定にはせず、切り分けのための一時的な確認に留めるのが安全です。

まとめ

止まる場所が分かれ目です。ブラウザの承認後にtimeout of 15000ms exceededで止まるなら、メッセージを当てにせずnslookupでclaude.ai・claude.com・platform.claude.com・api.anthropic.comを個別に引き、解決できないホストを社内DNSや許可リストで直します。サインイン画面の前で止まるなら、見る先はapi.anthropic.comとplatform.claude.comへの疎通です。

cli.jsの書き換えやhostsファイルへのIP固定は、更新のたびに失われたり、IP変更に追従できなかったりします。切り分けのための一時的な確認に留めるのが安全です。