auth.anthropic.comのDNS解決失敗でログインできないときの切り分け
企業DNSやプロキシでauth.anthropic.comが解決できずOAuthログインがタイムアウトする症状の原因と、公式ドキュメントに基づく切り分け手順をまとめます。
claude loginを実行するとOAuth error: timeout of 15000ms exceededで止まり、nslookupで調べるとauth.anthropic.comが存在しないドメインとして返ってくる。この症状は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 domainapi.anthropic.comは同じ環境で正常に解決できていたという報告も複数あり、企業ファイアウォールによる意図的なブロックというより、特定ホスト名の名前解決だけが失敗する現象でした。Issueの投稿自体には根本原因の断定はなく、Anthropic側からの公式な原因説明も見当たりません。
v2.1.227前後でエラーメッセージの見え方はどう変わったか
このIssueが厄介だったのは、DNSが即座にNXDOMAINを返しているにもかかわらず、CLI側の表示がtimeout of 15000ms exceededという汎用的なタイムアウトメッセージだった点です。ユーザーは自分でnslookupを実行して初めて、原因がDNSだと気づけました。
公式のエラーリファレンスによると、この状況はv2.1.227で変わっています。それ以前は接続エラーの種類によらずUnable to connect to APIに続けてエラーコードだけが表示されていました。v2.1.227以降はCan't reach the API server — check your internet or DNS (ENOTFOUND)のように、DNS起因であることがメッセージ本文からも読み取れる形式になりました。
つまり同じ症状に今遭遇した場合、表示されるメッセージを見るだけで「DNSの問題らしい」と判断できる可能性が高くなっています。まずclaude --versionでバージョンを確認し、古いままならclaude updateで更新してから症状を再現させると、切り分けの精度が上がります。ENOTFOUNDが表示されたときの一般的な対処は「Unable to connect to API」エラーの解決手順にまとめています。
自分で切り分ける手順
公式のトラブルシューティング手順は、Claude Code自体を疑う前にシェルから直接疎通を確認することを勧めています。同じ端末から次のコマンドを実行し、DNS解決とHTTPS接続のどちらで失敗しているかを分けて確認します。
nslookup auth.anthropic.com
nslookup platform.claude.com
curl -I https://platform.claude.comWindowsのPowerShellでは組み込みエイリアスのInvoke-WebRequestがcurlとして呼ばれます。curl.exe -I https://platform.claude.comのように明示して実行します。nslookupが失敗するのにcurlが成功する、あるいはその逆になる場合は、OSのDNSキャッシュや/etc/resolv.confの到達不能なネームサーバーを疑います。WSLはホスト側の壊れたリゾルバをそのまま引き継ぐことがあるため、Windowsとは別に確認が必要です。
古い失敗結果がキャッシュに残っている可能性もあるため、念のためOSのDNSキャッシュを一度クリアしてから再試行するという選択肢もあります。キャッシュを消すだけの操作なので、既存の設定を変えることはありません。
- macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Windows(管理者権限のターミナル):
ipconfig /flushdns - systemd-resolvedを使うLinux:
sudo resolvectl flush-caches
Docker Desktopのようなコンテナランタイムは、動作中に通信を横取りすることがあります。コンテナ環境やdevcontainer上で発生している場合は、いったんDockerを終了してから同じコマンドで再現するかどうかも切り分けの材料になります。
企業プロキシ配下であれば、HTTPS_PROXYが設定されているか、その値が正しいプロキシを指しているかも合わせて確認します。プロキシ側にホスト名解決を任せたい環境向けにはCLAUDE_CODE_PROXY_RESOLVES_HOSTS=1というopt-inの環境変数が用意されており、設定するとクライアント側ではなくプロキシ側がDNS解決を行うようになります。詳しい環境変数の一覧と設定場所はクラウド環境のネットワークアクセス設定にまとめています。
設定が読み込まれているかどうかは、対話セッションで/statusを実行するとその場で確認できます。
/status/statusの「Proxy」の行には有効なプロキシURLが表示されます。パースできない値はここで「invalid」と示され、無視されます。
あわせてclaude doctorを実行すると、インストール状態や設定ファイルの妥当性を読み取り専用で診断できます。ネットワーク到達性そのものは確認しませんが、設定ファイルの読み込みエラーがあればここで警告として表示されます。
claude doctordevcontainerやSSH経由、WSL2でClaude Codeを使っている場合は、もう一つ確認材料があります。v2.1.126(2026年5月1日)では、低速回線・プロキシ経由・IPv6専用のdevcontainer・ブラウザコールバックがlocalhostに届かない環境でのOAuthログインタイムアウトがまとめて修正されました。あわせて、ブラウザコールバックが使えないときに認証コードを端末へ直接貼り付けてログインする経路も追加されています。今回のDNS解決失敗そのものを名指しした修正ではありませんが、これらの環境で症状が出ている場合はまずこのバージョン以降かを確認する価値があります。
現在の認証ドメインはauth.anthropic.comではない
企業のファイアウォール担当者に許可を依頼するとき、古い情報のままauth.anthropic.comだけを申請してしまうと、実際に必要なドメインが漏れることになります。現在の公式ネットワーク要件ドキュメントが挙げる認証関連のドメインは次の3つで、auth.anthropic.comという名前は含まれていません。
| ドメイン | 用途 |
|---|---|
claude.ai | 用途claude.aiアカウントの認証 |
claude.com | 用途claude.aiサインイン時に開くページ(claude.aiへリダイレクト) |
platform.claude.com | 用途Anthropic Consoleアカウントの認証。claude.aiアカウントのOAuthトークン交換・更新・失効もこのホストが担う |
このドキュメントはIssueが報告された後もAnthropicが更新を続けているページで、時点によって要求ドメインが変わり得ます。今auth.anthropic.comのDNS解決に失敗しているとしても、それが現行の認証フローで実際に必要なホスト名だとは限りません。まず上の3ドメインとapi.anthropic.comをnslookupで確認し、そちらが解決できているなら、ログイン自体は現在の経路で成立する可能性があります。許可ドメインの一覧と各ドメインの用途はClaude Codeプロキシ設定にもまとめていますが、ドメインの追加・変更自体は公式のネットワーク要件ページ側で随時行われるため、ファイアウォールやプロキシの許可リストを見直す際の最終確認はそちらで行うと安心です。
初回セットアップでは、サインイン画面を出す前にapi.anthropic.comとplatform.claude.comへ届くかを確認します。forceLoginGatewayUrlをmanaged settingsで設定している組織では、起動した時点からClaude appsゲートウェイ経由のセッションとして扱われ、残っているclaude.aiログインやAPIキーは使われません。ゲートウェイ経由でログインする運用では、DNSの切り分けより先にforceLoginGatewayUrlの設定が意図通りか確認したほうが早く原因にたどり着けます。
報告されている回避策と注意点
Issueのコメント欄には複数の応急処置が並んでいますが、リスクの大きさに差があります。この中でシステム側の設定ファイルを書き換えずに済むのはclaude install stableで安定版に切り替える方法で、複数のユーザーがこれでログインできたと報告しています。
claude install stableOAuthでのログインだけがDNSの影響を受けている状況であれば、ANTHROPIC_API_KEY環境変数によるAPIキー認証に一時的に切り替える方法もあります。APIキーでのリクエストはapi.anthropic.comだけに到達すればよく、platform.claude.comやclaude.aiへの到達性は必須ではなくなります。ただしAnthropic ConsoleでAPIキーを新規発行する操作自体にはplatform.claude.comへのアクセスが要るため、同じ経路がすでに塞がれている場合はこの回避策も根本的な解決にはなりません。Issueの投稿者自身も、この方法が全員に使えるわけではないと補足しています。ログイン方式ごとに何を認証し何が不要になるかはClaude Codeログイン方法3種の使い分けで比較しています。
一方、cli.js内のハードコードされたタイムアウト値(timeout:15000)をsedやSet-Contentで直接書き換える回避策も広く共有されていました。これはタイムアウトを45秒に延ばすだけの変更で、DNSが解決できない状態そのものは直りません。コメントの中では、この方法はnpmインストール環境が前提であり、現在は非推奨のインストール方法であるため誰にでも当てはまるわけではないという指摘も出ています。書き換えた内容はアップデートのたびに失われる点にも注意が必要です。
さらにリスクが高いのが、OSのhostsファイルにauth.anthropic.comと特定のIPアドレスを直接書き込む方法です。公式のIPアドレス一覧ページは、AnthropicのIPアドレスが「予告なく変更されることはない」運用を明言していますが、これは変更が絶対に起きないという意味ではなく、変更時に通知されるという運用ポリシーです。hostsファイルに固定したIPは、その通知が出ても自動では追従しません。恒久的な設定にはせず、切り分けのための一時的な確認に留めるのが安全です。
まとめ
auth.anthropic.comのDNS解決失敗によるOAuthログインタイムアウトは、2026年3月のClaude Code v2.1.72前後で世界各地から報告された既知の症状です。同じエラー文字列に今遭遇した場合は、まずバージョンを更新してからエラーメッセージにDNS由来のコードが含まれるかを確認します。次にnslookupでclaude.ai・claude.com・platform.claude.com・api.anthropic.comが解決できるかを個別に確認します。そのうえで、社内DNSやプロキシの許可リストがこれらの現行ドメインに追従しているかを見直します。cli.jsの書き換えやhostsファイルへのIP固定は一時しのぎとしての報告はあるものの、更新のたびに失われたりIP変更に追従できなかったりする副作用があるため、恒久対応にはしないほうが安全です。