「DNSサーバーは応答していません」の直し方｜Windows 11で回線・名前解決・アプリを切り分ける

トラブル・設定

2026.10.26

「DNSサーバーは応答していません」の直し方｜Windows 11で回線・名前解決・アプリを切り分ける

本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。

WINDOWS 11 / DNS TROUBLESHOOT

「DNSサーバーは応答していません」の直し方
回線・名前解決・アプリを分けて確認

Wi-Fi接続済みでもIP取得やDNSへの問い合わせに失敗することがあります。IP・ゲートウェイを確認してから、同じ名前でDNSの応答を比較します。

Windows 11変更前の設定を記録結果別に対処を選ぶ

Wi-Fiには接続できているのに、ブラウザーやSteamが開かず「DNSサーバーは応答していません」と表示される。DNSはドメイン名からIPアドレスなどを調べる仕組みですが、この表示だけでDNSサーバーの故障とは決められません。

最初にPCのIPアドレス・ゲートウェイ・他端末の通信を確かめ、次に設定中のDNSへ同じ名前を問い合わせます。IP取得失敗、問い合わせのタイムアウト、特定の名前のエラー、特定アプリの失敗で、対処する場所が変わります。

8.8.8.8への変更は、通信経路とDNSの応答を比べてから検討する選択肢です。会社・学校・VPNの管理下では管理者に相談し、家庭でも変更前の値を記録してください。ゲーム中のPingや回線帯域の改善を期待して、DNS変更を繰り返す必要はありません。

診断全サイト・特定サイト・Steamだけのどれかを確認する

普段使う別のサイトと別のアプリを開きます。スマートフォンでも同じWi-Fiにつなぎ、モバイルデータ通信へ切り替わっていないか確かめて比較してください。別端末も使えないなら共通経路、PCだけ使えないなら端末側を調べる手がかりになります。

次の表は原因を確定するものではなく、調べる順番です。変更は1つずつ行い、同じサイト・アプリで再試行します。

観察した結果	先に調べる対象	次の行動
IPv4が169.254から始まる	自動取得時のDHCP・ルーターとの接続	DNS変更を保留し、IP取得とゲートウェイを確認
同じWi-Fiの複数端末で使えない	ルーター・上流回線・共通DNS	回線事業者の障害情報と機器の状態を確認
設定中DNSへの問い合わせがタイムアウト	DNS設定・到達経路・通信制御	記録したDNSごとに同じ名前を問い合わせる
特定の名前だけエラー	名前の誤記・対象ドメイン・DNSの応答	別の名前と比較し、エラー文を保存
名前解決は成功、ブラウザーだけ失敗	セキュアDNS・プロキシ・アプリ側	別ブラウザーと比較し、変更済み設定を確認
ブラウザーは使えるがSteamだけ失敗	Steam側の障害・クライアント接続	エラー表示と失敗する機能を記録

Steamだけ接続できない場合は、Steamの接続障害を切り分ける手順へ進めます。ストアは開けてもダウンロードで専用エラーが出るなら、Content Servers Unreachableの診断が次の確認先です。

記録使用中アダプターのIP・ゲートウェイ・DNSを控える

スタートで「コマンドプロンプト」を検索して開き、次を実行します。設定を表示する操作です。

ipconfig /all

Wi-Fiなら無線、有線ならEthernetのうち、実際に使用中のアダプター欄を読みます。VPN・仮想アダプター・切断中の項目を混同しないでください。

IPv4・IPv6アドレスと、DHCP有効の表示。
デフォルトゲートウェイ。家庭では通常、外へ通信する際の出口です。
DNSサーバー。複数行あれば順番も控えます。ルーターのアドレスが表示される構成もあります。
接続方式と確認時刻。

自動取得のIPv4が169.254.x.xなら、ルーターなどからIPv4アドレスを取得できていない可能性があります。DNS変更より先に、ケーブル・Wi-Fi接続先・ルーターとの接続を確認します。IPv6も含む通信全体の可否は、このIPv4の数字だけでは決まりません。

設定を記録したらPC・ルーターを条件別に再起動する

PCだけで症状が出る場合は作業を保存し、アプリを閉じて「スタート」→電源アイコン→「再起動」を選びます。再起動後、同じサイト・アプリと同じ名前への問い合わせを試してください。

家庭の同じネットワークで複数端末に症状が出る場合は、回線事業者の障害情報を確認したうえで、ルーターやモデムの再起動を検討します。他の利用者の通信も一時的に切れるため、利用中の人へ確認し、機種の公式マニュアルにある再起動の手順・電源を戻す順番に従ってください。リセットボタンによる初期化とは別の操作です。管理ネットワークの機器は管理者に任せます。

機器の起動と接続が落ち着いたら、IP・ゲートウェイ・DNSを読み直し、同じ名前・サイト・アプリで再確認します。改善しなければ、以降の問い合わせ結果を記録して対処を分けます。

ゲートウェイへのPingは補助材料にする

ゲートウェイのIPv4を記録できた場合は、その数字を指定してPingを試せます。次はゲートウェイが192.168.1.1だった場合の入力例です。自分の表示値へ置き換えます。

ping 192.168.1.1

応答があれば、その時点で相手とのICMP通信ができた手がかりになります。ただし応答を返さない機器や通信制御もあります。ゲートウェイや外部IPへのPing失敗だけで回線断と確定せず、他端末・機器の状態・DNSの応答と合わせて判断します。

共有する記録から識別情報を除く

ipconfigにはホスト名・物理アドレス・社内ドメインなどが含まれます。公開掲示板へ全文を貼らず、必要な箇所を抜き出して識別情報を隠してください。サポートには安全な窓口で送ります。

名前解決nslookupで同じ名前と同じDNSを比較する

nslookupはDNSへの問い合わせ結果を調べるコマンドです。第2引数を省略すると既定のDNSを使用します。次は入力例です。

nslookup www.microsoft.com.

次に、控えたDNSのIPを第2引数へ指定します。DNSが192.168.1.1だった場合は次の形です。名前の最後のピリオドも含め、比較中は同じ名前を使ってください。

nslookup www.microsoft.com. 192.168.1.1

複数DNSが設定されていれば、それぞれのIPを指定して再試行します。表示冒頭の問い合わせ先サーバーのAddressと、回答欄に返る問い合わせ名のAddressは別物です。サーバーのIPが表示されただけで、目的の名前が解決できたとは判断しません。

表示・応答の違い	読み取れること	次の確認
問い合わせ名の回答にIPが返る	そのDNSが、その名前の問い合わせに回答した	開けないサイトの実際のホスト名でも確認
DNS request timed out	待機・再試行しても応答が得られなかった	問い合わせ先・到達経路・通信制御を確認
Nonexistent domain	名前が存在しない旨の回答	綴り・ホスト名を確認し、別の名前と比較
Server failure	DNSが問い合わせを処理できなかった	同じ名前を別DNSと比較し、結果を相談先へ渡す
No records	指定した種類のレコードがない旨の回答	問い合わせ名とレコードの種類を確認

タイムアウトはサーバー本体の故障に加え、到達できないアドレスの設定や途中の遮断でも起きます。存在しない名前への回答を受け取った場合は「何も応答しない」とは区別します。別サイトの名前は解決でき、特定の名前だけ失敗するなら、その名前と対象サービスを先に調べてください。

開けないURLを調べるときは、https://や/以降のパスを除いたホスト名を入力します。サービスはログイン用・画像用など複数の名前を使う場合があり、トップページの名前が解決できても全機能の通信成功を意味しません。

8.8.8.8は設定を書き換えずに比較できる

自分が管理する家庭の回線で、外部DNSへの問い合わせが許可されている場合に限り、Google Public DNSへ同じ名前を問い合わせて比較できます。次のコマンドはPCのDNS設定を変更しません。

nslookup www.microsoft.com. 8.8.8.8

設定中DNSは失敗し、8.8.8.8は回答するなら、設定中DNSやそこまでの経路を調べる材料になります。両方失敗しても2台の故障と即断せず、回線や通信制御を確認します。会社・学校・VPNで使う内部名を、比較のために公開DNSへ送らないでください。

キャッシュDNSキャッシュの確認・削除は条件を絞って行う

DNS情報を変更した直後や、失敗した名前の結果が残っている可能性があるときは、WindowsのDNSクライアントキャッシュを確認します。

ipconfig /displaydns

必要に応じて、管理者として開いたコマンドプロンプトで次を実行します。

ipconfig /flushdns

削除されるのはWindowsのDNSクライアントキャッシュです。ルーターや外部DNSのキャッシュ、ブラウザー独自の状態をまとめて初期化する操作ではありません。実行後は失敗していた同じURL・アプリで再試行します。nslookupの結果だけで、Windowsキャッシュ削除の効果を判定しないでください。

/releaseはDHCP設定とIPアドレスを解放し、通信に影響します。/renewは自動取得アダプターのDHCP設定更新、/registerdnsはDNSへの動的登録に使います。キャッシュ削除と目的が違うため、まとめて貼り付けて実行せず、IP取得に問題がある場合は先にその原因を確認します。

アプリ名前解決できるのにブラウザー・Steamが開かないとき

nslookupが成功しても、アプリの接続まで正常とは限りません。Windowsの通常の名前解決はキャッシュやHostsの影響を受け、複数DNSの選び方によってもnslookupと結果が異なる場合があります。

Chromeだけ失敗するならセキュアDNSを確認

Chromeの「設定」→「プライバシーとセキュリティ」→「セキュリティ」で「セキュアDNSを使用する」を確認します。自分でカスタムプロバイダーへ変更してから症状が出た場合は、変更前の設定へ戻し、同じサイトで比較してください。暗号化を変えると問い合わせの保護にも影響するので、無条件にオフにする操作は避けます。

Chromeの自動モードには問題時に非暗号化の検索へ移る動作がありますが、カスタムプロバイダー選択時は同じ動作になりません。ブラウザー独自の問い合わせ先とnslookupを同じとみなさず、別ブラウザーでも同じURLが開くか確かめます。

Windows側でDNS over HTTPSを手動設定した場合も、変更前の暗号化・フォールバック設定を確認します。HTTPSで送信できず、平文へのフォールバックを許可していない設定では、問い合わせを送れない場合があります。

Steamだけ失敗するなら機能とエラー表示を記録

ログイン、ストア表示、ダウンロード、ゲーム内接続のどこで止まるかを分けます。他のアプリが使える場合は、Steamのエラー表示やサービス側の状況を確かめてから、アプリ固有の対処へ進みます。

プロキシ・VPNを直前に変更した場合は履歴も確認します。管理された接続は勝手に解除せず、管理者へ相談してください。Defender・ファイアウォール・IPv6を一括で無効にするより、問い合わせ結果と設定記録から対象を絞るほうが変更箇所を追えます。

復元DNSの自動取得・手動設定を変更前へ戻す

元が自動なら自動へ、元が手動なら記録したアドレスと順番へ戻します。全員が自動取得にすればよいわけではありません。固定IPや社内DNSを使う環境は管理者に確認してください。

Windowsの「設定」→「ネットワークとインターネット」を開きます。Wi-Fiは「ハードウェアのプロパティ」、有線は接続中のEthernetの設定へ進みます。
対象接続の「DNSサーバーの割り当て」の編集を開き、自動・手動、IPv4・IPv6のDNS、暗号化の選択を記録します。画面名はWindowsのバージョンで異なる場合があります。
変更前が自動なら「自動（DHCP）」へ戻します。手動だった場合は元の優先・代替DNSと暗号化設定へ戻します。「IP割り当て」は別設定なので、DNSの復元のために変更しません。
保存後にipconfig /allでDNSを読み直し、同じ名前の問い合わせと失敗していたアプリで再試行します。IPv4だけ変えた場合はIPv6も一緒に変えません。

DNSのみを編集できる項目が見つからない場合や元の設定が分からない場合は、IP・ゲートウェイを推測して入力せず、管理者や回線事業者へ確認します。ルーターの初期化も保留してください。