DNS検索が遅い原因と解決方法 — Chrome・Windows・Macで即効改善

DNS検索時間とは？なぜ重要なのか

DNS検索時間とは、デバイスがドメイン名（例：example.com）をIPアドレスに変換するのにかかる時間のことです。これが終わるまで、接続もTLSもダウンロードも始まりません。

キャッシュ済みの答えなら、ルーターのキャッシュからは数ミリ秒、近くのパブリックリゾルバーからは10〜30 ms前後で返ります。リゾルバーが一度も見たことのない名前は、ドメイン自身のネームサーバーに問い合わせるため、数十ミリ秒以上かかります。たくさんのドメインからファイルを読み込むページは、新しいドメインごとにこの時間を払うことになります。

DNS検索が遅くなる原因

デバイスやネットワークでDNS検索が遅くなる、よくある原因は次のとおりです。

• 遅い・混雑したリゾルバー — ISPやルーターのDNSサーバーの応答が遅い状態です。特にキャッシュにない名前で目立ちます。（まったく応答しない場合は、DNSサーバーが応答しない場合の対処法をご覧ください。）
• 距離 — ネットワーク上で遠いリゾルバーは、検索のたびに往復の時間が加わります。
• キャッシュに答えがないリゾルバー — 近くの誰も最近調べていない名前は、ドメイン自身のネームサーバーから取ってこなければなりません。
• 長いCNAMEチェーン（サイト運営者向け） — リゾルバーがたどるエイリアスが増えるたびに、検索が1回増えることがあります。
• とても短いTTL（サイト運営者向け） — 答えがすぐに期限切れになり、リゾルバーがドメインのサーバーへ何度も問い合わせます。
• VPNやプロキシ — 検索が、自分から遠いリゾルバーに送られることがあります。
• Wi-Fiや混雑したルーターでのパケット損失 — 失われたDNSパケットは再送まで待たされ、1秒以上の遅れになることもあります。

現在のDNS検索時間を測定する方法

修正する前に、現在のDNS速度を測定して、修正後と比較できるようにしましょう。DNS検索時間を確認する3つの簡単な方法を紹介します。

方法1：dig コマンドを使用（Mac/Linux）

dig コマンドは、DNSクエリ時間をミリ秒単位で正確に表示します：

# Query your current DNS server
dig google.com

# Look for "Query time" at the bottom:
# ;; Query time: 24 msec

# Test a specific DNS server
dig @1.1.1.1 google.com
dig @8.8.8.8 google.com
dig @9.9.9.9 google.com

方法2：nslookup を使用（Windows）

nslookup はクエリ時間を表示しませんが、PowerShellなら近い値が得られます。-Server と -Type A を付けて数回実行し、中央値を比べましょう。

# Approximate lookup time in PowerShell (times the whole command)
Measure-Command { Resolve-DnsName example.com -Type A } | Select-Object TotalMilliseconds

# Against a specific DNS server (skips Windows' own cache)
Measure-Command { Resolve-DnsName example.com -Type A -Server 1.1.1.1 } | Select-Object TotalMilliseconds

方法3：Chrome DevToolsを使用

Chromeはすべてのネットワークリクエストに対してDNS検索時間を表示します：

任意のウェブサイトを開き → F12 を押してDevToolsを開き → Network タブに移動 → 任意のリクエストをクリック → Timing セクションを確認します。DNS Lookup の行に、そのドメインのDNS解決にかかった正確な時間が表示されます。

DNS検索時間が常に100msを超えている場合、DNSサーバーが遅い状態です。以下の修正方法が役立ちます。

解決策1：より高速なDNSサーバーに切り替える

測定の結果、今のリゾルバーが遅いなら、切り替えが最も大きな改善になります。選ぶのは、世界平均が最良のものではなく、あなたの回線で最速のものです。各プラットフォームでの変更手順は次のとおりです。

WindowsでDNSを変更する

• 設定を開く → ネットワークとインターネット → Wi-Fi → 既知のネットワークの管理 → 使用中のネットワーク（有線の場合は、イーサネット → 使用中のネットワーク）
• DNS サーバーの割り当ての横にある編集をクリックして、手動に切り替える
• IPv4で、優先 DNS を 1.1.1.1、代替 DNS を 1.0.0.1 に設定する。IPv6では 2606:4700:4700::1111 と 2606:4700:4700::1001
• 保存をクリックして、dig またはPowerShellでもう一度測る
• Windows 10の設定にはDNS専用の項目がありません。Win + Rを押して ncpa.cpl を実行し、アダプターを右クリック → プロパティ → インターネット プロトコル バージョン 4 (TCP/IPv4) → プロパティ → 次の DNS サーバーのアドレスを使う、の順に開きます

macOSでDNSを変更する

• システム設定を開く → ネットワーク → Wi-Fi（またはアクティブな接続）
• 接続しているネットワークの横の詳細をクリック
• サイドバーのDNSをクリック
• 既存のエントリを削除して、1.1.1.1 と 1.0.0.1 を追加（IPv6を使うなら 2606:4700:4700::1111 も）
• OKをクリック

LinuxでDNSを変更する

systemd-resolvedを使うディストリビューション（たとえばUbuntuやFedoraのデスクトップ）では、NetworkManagerで接続ごとにDNSを設定するか、resolvectl で次の再接続まで設定します。/etc/systemd/resolved.conf に DNS= を足すだけでは足りません。そのサーバーは、ネットワークが配るサーバーと並べて問い合わせられるためです。

# NetworkManager: replace "Home Wi-Fi" with your connection name (nmcli con show)
nmcli con mod "Home Wi-Fi" ipv4.dns "1.1.1.1 1.0.0.1" ipv4.ignore-auto-dns yes \
  ipv6.dns "2606:4700:4700::1111 2606:4700:4700::1001" ipv6.ignore-auto-dns yes
nmcli con up "Home Wi-Fi"

# systemd-resolved, until the next reconnect (replace wlan0 with your interface)
sudo resolvectl dns wlan0 1.1.1.1 1.0.0.1
resolvectl status wlan0

解決策2：DNSキャッシュをフラッシュする

キャッシュに残った失敗や古い答えは、期限が切れるまで遅れの原因になります。フラッシュすると保存済みの答えがすべて消え、次の検索は新しく送られます（詳しい手順：DNSをフラッシュする方法）。

お使いのOSに合ったコマンドを実行してください。

# Windows (Command Prompt)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Verify cache is empty (Windows)
ipconfig /displaydns

解決策3：ブラウザのDNSプリフェッチを有効にする

ブラウザは、必要になる前に名前を調べておくことができます。Firefoxはページがリンクしているドメインを解決し、Chromeは（ページのプリロードがオンなら）次に開きそうなページを解決して接続まで進めます。サイトも、使うドメインに dns-prefetch のヒントを付けられます。Chromeは、すべてのリンクのドメインを自分から先読みすることはもうありません。自動で行うのは、通常のhttp:ページだけです。

これらの設定は初期状態でオンですが、オフになっていることがあります。確認の手順は次のとおりです。

ChromeのDNSプリフェッチ設定

Chromeでは、DNSプリフェッチはページのプリロードの一部です。

• Chromeを開く → 設定 → パフォーマンス → ページをプリロードする
• オンにする（標準のプリロードが初期設定です）
• これで、次に開きそうなページの名前解決と接続、場合によっては読み込みまで、Chromeが先に進めてくれます

FirefoxのDNSプリフェッチ設定

FirefoxはDNSプリフェッチをサポートしていますが、意図せず無効になっている場合があります：

• アドレスバーに about:config と入力してEnterを押す
• 検索する：network.dns.disablePrefetch
• false になっていることを確認（false ＝ プリフェッチ有効。初期値です）
• もう1つ確認：network.dns.disablePrefetchFromHTTPS が false（初期値）なら、HTTPSのページでもプリフェッチされます

解決策4：ChromeのDNSキャッシュをクリアする（古い答えが残るときだけ）

Chromeは、OSとは別に自分のDNSキャッシュを持っています。このキャッシュが検索を遅くすることはなく、クリアしても速度が長く変わるわけではありません。ただ、あるサイトについてChromeが古い答えや失敗した答えを持っているときは、OSのキャッシュだけをフラッシュしても、そのサイトはChromeでは直りません。

ChromeのDNSキャッシュをクリアする手順は次のとおりです。

• Chromeを開き、アドレスバーに chrome://net-internals/#dns と入力
• 「Clear host cache」をクリックしてChromeの内部DNSエントリをフラッシュ
• 同様に chrome://net-internals/#sockets にアクセスし、「Flush socket pools」をクリックして残留接続を閉じる
• Chromeを再起動して完全に新しいDNS状態にする

解決策5：ルーターでDNSを設定する

ルーターでDNSを変更すると、ネットワーク上のすべてのデバイス（スマートフォン、タブレット、スマートTV、ゲーム機）に高速DNSサーバーが適用されます。個別に設定する必要はありません。

ほとんどのルーターでDNSを変更する方法：

• ルーターの管理ページを開く（通常は 192.168.1.1 または 192.168.0.1）。ルーターログインガイドに、80以上のルーターとプロバイダーのアドレスと初期パスワードをまとめています
• ログイン：ルーターの管理者アカウントを使います（変更していなければ、ルーター本体のラベルを確認）
• DNS設定を探す — 通常はWAN設定、インターネット設定、またはDHCP設定にあります
• プライマリDNSを 1.1.1.1、セカンダリDNSを 1.0.0.1 に変更
• 保存して、ルーターを再起動し、変更を反映させる

解決策6：CNAMEチェーンを削減する（サイト運営者向け）

この対策は、サイト運営者や開発者向けです。エイリアス（CNAME）は、キャッシュにないとき1つにつき検索が1回増えることがあります。リゾルバーは、実際のIPアドレスを持つAまたはAAAAレコードに行き着くまで、チェーンをたどらなければなりません。

典型的なCNAMEチェーンは次のようになります。

www.example.com   CNAME  example.com.cdn.example.net
example.com.cdn.example.net  CNAME  edge-123.cdn.example.net
edge-123.cdn.example.net     A      203.0.113.10

# Each alias may need its own lookup when it isn't cached,
# especially when the names sit on different DNS providers.

ドメイン直下のチェーンを短くするには、CNAMEフラットニング（ALIASレコードとも呼ばれます）を使います。DNSプロバイダーがチェーンを自分でたどり、最終的なIPアドレスを返す仕組みです。Cloudflare（CNAMEフラットニング）とDNSimple（ALIAS）は、どんな宛先でもこれを行えます。Route 53のエイリアスレコードは、AWSのリソースと同じホストゾーン内のレコードに対してだけ使えます。

CNAME Lookupなら、任意の名前についてチェーン全体をたどり、各ホップを表示します。

解決策7：TTL値を増加させる（サイト運営者向け）

TTL（Time to Live）は、DNSリゾルバーがドメインのレコードをキャッシュする時間を決めます。TTLが60秒なら、リゾルバーがネームサーバーに問い合わせるのは、誰かがその名前を尋ねたときに限り、最大で1分に1回です。3600秒（1時間）なら、キャッシュした答えを1時間返し続けます。

TTLを長くすると、リゾルバーは答えを長く保持し、ネームサーバーへの問い合わせが減ります。代わりに、変更が全員に届くまで時間がかかります。

主要パブリックDNSサーバーの比較

主要なパブリックリゾルバーについて、DNSPerfの世界平均（2026年10月4日に確認）と、各社がログについて公表している内容をまとめました。実際の結果は環境によって変わるので、必ず自分で測ってください。

アドレス一覧と設定手順の詳細：Cloudflare DNSサーバーのガイドとGoogle DNSサーバーのガイド。

あなたの環境でどれが最速かは、DNS RobotのDNS スピードテストをブラウザで実行して確かめられます。dig @1.1.1.1 example.com と dig @8.8.8.8 example.com を数回ずつ実行して比べる方法もあります。

DNSが高速化されたことを確認する方法

上記の修正を適用した後、DNS速度を再度測定して改善を確認しましょう。

# Mac/Linux: Compare before and after
dig google.com      # Should show lower query time
dig amazon.com      # Test multiple domains
dig github.com

# Windows PowerShell
Measure-Command { Resolve-DnsName google.com } | Select-Object TotalMilliseconds

# Check Chrome DevTools
# Open any page → F12 → Network tab → look at DNS Lookup timing

新しい数値を最初の測定と比べましょう。ほとんど変わらなければ、元のリゾルバーは原因ではありません。Wi-Fiのパケット損失、VPN、サイト側を調べてください。