Rakuten WiFi Pocket 5GはDNS変更で速くなる？公開DNSとDoHを実測

広告：本記事にはアフィリエイト広告が含まれます。

2026年10月31日更新：暗号化DNS（DoH）を新たに18回試験し、Google9/9回、Cloudflare8/9回成功。DoHの結果と暗号化表示の注意点へ。以下の通常DNS45回の結果は10月30日の測定値として残しています。

新規実測：2026年10月30日 16:12〜16:13（日本時間）／楽天最強プラン／Rakuten WiFi Pocket 5G／Windows PC・2.4GHz

DNSをCloudflareやGoogleに変更すれば、楽天のポケットWi-Fiは速くなるのか。今回はPCとルーターの設定を変えず、問い合わせ先だけを試験プログラム内で指定して比較した。3つのホスト名を5回ずつ調べたDNS応答時間の中央値は、ルーターの既定IPv4 DNSが6.9ms、Cloudflareが354.4ms、Googleが440.1ms。45回の問い合わせはすべて成功した。この環境では、公開DNSを指定した方が短時間で名前解決できるという結果にはならなかった。

ただし、これは繰り返し問い合わせた際のDNS応答の比較だ。DNSや端末のキャッシュ、上流への問い合わせを同じ状態にそろえた試験ではなく、回線のMbpsやブラウザーの表示速度が改善するかを直接測ったものではない。

2026年10月31日追記：楽天WiFiで暗号化DNS（DoH）は使える？

今回のPCでは、GoogleのDoHは9/9回、Cloudflareは8/9回、Aレコードの回答取得まで成功した。Cloudflareの1回はHTTP応答を受け取れず、約5.20秒でタイムアウトした。DoH通信が成立する例は確認できたが、常時成功や高速化を保証する結果ではない。

前述の2024年9月15日の知恵袋の相談には、DNSの設定画面で暗号化・非暗号化の表示が食い違うという疑問もある。相談の機種は特定できず、設定画面の状態も今回再現していない。その疑問に関連して、現在のPocket 5G経由で明示的なDoH問い合わせを送れるかを追加検証した。

新しい実測の条件

2026年10月31日12:19:01〜12:19:59（日本時間、秒未満切り捨て）に、同じWindows 11 ProのPCで実施。楽天最強プラン＋Rakuten WiFi Pocket 5Gへ2.4GHz・802.11nで接続し、測定前後のSSIDとIPv4・IPv6の既定経路で対象ルーター経由であることを確認した。リンク速度は送受信144.4Mbps、信号表示94%、RSSIは−30dBm。これらはPCとルーターの無線区間の値で、携帯基地局の電波強度ではない。携帯回線が4Gか5Gかは確認していない。

問い合わせ名はexample.com、cloudflare.com、network.mobile.rakuten.co.jpの3つ。各社へ各3回、合計18回のAレコード問い合わせを順番に送信した。宛先の順番を入れ替え、各要求を新しいcurlプロセスで実行。IPv4・HTTP/1.1のGETを使い、接続タイムアウト5秒、全体の上限10秒、再試行なし、証明書検証ありとした。Windows・Chrome・ルーターのDNS設定は変更していない。

成功17件はHTTP 200かつapplication/dns-messageの応答だった。DNS本文も解析し、応答フラグ、問い合わせ名・種類・クラスの一致、RCODE=0、切り詰めなし、1件以上のAレコードを確認した。HTTP 200だけでDNS成功と判定していない。Cloudflareのexample.comへの第1回はcurl終了コード28、応答本文0byte、HTTPステータス未取得だった。後続の同じ問い合わせは2回とも成功したが、失敗の原因は特定できない。

curlが記録した合計は要求2,725byte、応答ヘッダー6,481byte、DNS応答本文2,057byte。TLS・TCP/IPのヘッダーや再送、DoHサーバー名の事前名前解決、他のバックグラウンド通信は含まないため、楽天側の課金データ量や回線全体の使用量ではない。

DNSの暗号化、Wi-Fiの暗号化、通信速度は別の確認が必要

DoHはDNSメッセージをHTTPSで運ぶ方式だ。今回のGETはDNSメッセージをBase64URLでURLへ入れるRFC 8484の形式を使用し、各社の公式エンドポイントへ送った。RFC 8484、Cloudflare公式仕様、Google公式仕様で確認できる。

測定時のPCとルーターのWi-Fi認証はWPA2-Personal、暗号はCCMPだった。これと、DNS要求をHTTPSで送るかどうかは別の項目だ。今回の成功は試験プログラムが送った17要求の結果であり、Windows全体やChromeの通常閲覧がすべてDoHを使っている証拠にはならない。DoHサーバー名の初回名前解決の暗号化も検証していない。

表の秒数は名前解決に加え、TCP接続・TLS準備・応答受信を含むHTTP要求全体の時間だ。10月30日に測った通常DNSのミリ秒値とは日付も接続処理も違い、単純に倍率比較できない。HTTP接続は要求間で再利用せず、DNS・HTTPキャッシュも統制していない。今回の値からCloudflareとGoogleの恒常的な優劣や、DNS変更によるMbpsの向上は判断しない。

FAQ：表示が「暗号化」なら、PCの通信はすべて暗号化される？

DNSの暗号化表示だけでは、他のアプリも同じDNS経路を使うことや、すべての通信内容が暗号化されることまでは確認できない。今回もOS・ブラウザーの通常DNS経路を採取していないため、相談にある表示の食い違いの原因は未検証だ。

FAQ：今回DoHが成功したら、Chromeでも必ず使える？

Chrome自体の設定と挙動は別途確認が必要だ。Googleの案内では、ChromeのセキュアDNSの自動モードとカスタムプロバイダーでは、失敗時の非暗号化DNSへの扱いが異なる。今回のcurlは失敗時に通常DNSのAレコード照会へ切り替えていない。Chrome公式ヘルプを参照してほしい。

固定した1地点・1台・約1分間の確認で、混雑時間帯、IPv6のDoH、HTTP/2・HTTP/3、DoT、DNSSECの検証は行っていない。転送速度と負荷中の応答は総合実測レビュー、アドレス方式はIPv4・IPv6の実測、ローカルな管理画面の名前解決はweb.settingの検証で条件を分けて記録している。

ネット上の疑問：DNS変更で速度測定の数値も上がる？

Yahoo!知恵袋には、楽天Wi-FiをPCで使い、CloudflareのDNSに変更しても速度測定の違いを判別できなかったという相談がある。2024年の投稿で機種名は特定されておらず、今回の5Gモデルと同一の端末として扱うことはできない。本記事は、その相談にある「DNS変更による高速化」という疑問を、現在の実機で検証するものだ。相談の原文（Yahoo!知恵袋）

名前解決の待ち時間と、接続後にデータを運ぶ速さを区別するため、DNSの応答とHTTPSの最初の応答までの時間を別々に記録した。投稿者の環境で起きた現象や、暗号化表示の食い違いを再現した試験ではない。

既定DNS・Cloudflare・Googleを各15回測定

3種類のホスト名をそれぞれ5回ずつ、1件ずつ順に問い合わせた。ルーターの中央値は短かった一方で、最長は496.1msだった。中央値だけを見て、いつでも同じ時間で返るとは考えない方がよい。

Cloudflareの標準DNSのアドレスは1.1.1.1、Google Public DNSは8.8.8.8を使った。アドレスは各社の一次資料で確認している。Cloudflare公式資料、Google公式資料

ホスト名別のDNS応答時間

各セルは5回の中央値。問い合わせたのはIPv4アドレスを調べるAレコードで、AAAAレコードやDNS over HTTPS（DoH）は測っていない。ルーターや上流DNSのキャッシュは消去せず、同じ名前を繰り返している。ルーターからの短い応答にはキャッシュの影響が考えられるが、キャッシュ命中を記録していないため、その割合は断定できない。

また、DNSによって返るアドレス数は異なっていた。応答時間の差だけから、公開DNSのサービス全体の性能や、実際に選ばれる配信先の転送速度を評価することはできない。

HTTPSではDNS以外の待ち時間もあった

続いて、WindowsのDNS設定をそのまま使い、3つのURLへHTTPSのHEADリクエストを各3回送った。IPv4・HTTP/1.1を指定し、リクエストごとにcurlを起動した。本文の取得やブラウザーの描画は行っていない。

Googleの確認用URLは3回ともHTTP 204、楽天モバイルのトップページは3回ともHTTP 200だった。Cloudflareの/cdn-cgi/traceへのHEADリクエストは3回ともHTTP 404で、期待した200は0/3回だった。404もサーバーから受け取った応答だが、正常なページ取得の成功には数えない。今回、404の理由は特定していない。

curlのtime_namelookupは開始から名前解決が完了するまで、time_starttransferは開始から最初の応答を受け取るまでの累積時間を示す。後者には接続準備やサーバー側の待ち時間も含まれる。上の2列を足し算するものではない。curl公式マニュアル

DNS時間と最初の応答までの時間には差があった。ただし、このHTTPS試験は公開DNSへ切り替えた前後の比較ではない。したがって、DNSを変更するとこの秒数がどれだけ縮むかは未検証であり、差のすべてを楽天回線の混雑や電波のせいとも断定できない。

設定を変える前にできる確認

Windowsでは、次のコマンドでDNSへの問い合わせ先だけを指定できる。PC全体のDNS設定を書き換える操作ではない。応答のアドレスが返るかを比べるための例で、このコマンドだけでは回線のMbpsやページ表示時間は測れない。MicrosoftのResolve-DnsName公式資料

Resolve-DnsName www.google.com -Type A -DnsOnly -NoHostsFile
Resolve-DnsName www.google.com -Type A -DnsOnly -NoHostsFile -Server 1.1.1.1
Resolve-DnsName www.google.com -Type A -DnsOnly -NoHostsFile -Server 8.8.8.8

今回の数値は、この確認例のコマンドではなくNode.jsの専用リゾルバーで取得した。Node.jsのdns.resolve4はネットワーク上のDNSへ問い合わせるAPIで、OSの通常の名前解決とは動作が異なる。Windowsのキャッシュを消去したり、セキュリティ機能を無効にしたりはしていない。Node.js公式資料

測定条件と限界

Windows 11 Pro、Intel Dual Band Wireless-AC 8265を使用。2.4GHz・802.11n・チャネル6、リンク速度144.4Mbpsで接続し、開始時の電波表示は93%、RSSIは−33dBmだった。開始時・HTTPS試験前・終了時に同じルーターへの接続と、IPv4・IPv6の既定経路がWi-Fiであることを確認した。携帯回線側が実際に4G・5Gのどちらだったかは未確認だ。

DNSは3ホスト名×3問い合わせ先×5回の計45問い合わせ。リゾルバーの待機設定は2.5秒、試行設定は1回、問い合わせ間は約0.4秒とし、先に試す問い合わせ先を巡回させた。DNSの応答サイズは固定しておらず、本文データを一定MB送受信する試験ではない。エラーは0/45回。HTTPSは計9回、上限20秒、明示的なプロキシを使わず、タイムアウトは0回だった。本文データは取得せず、ヘッダーの応答を記録した。

1台・1か所・約1分の条件で、他端末やPCのバックグラウンド通信は管理していない。長時間の安定性、コールドキャッシュ、IPv6のDNS問い合わせ、DoHの暗号化状態、設定変更後のブラウザーの体感速度、大容量転送は今回の範囲外。以前の記事の速度値を今回の新しい実測として使っていない。

DNS変更についてのよくある質問

楽天Wi-Fiは公開DNSに変更した方が速い？

今回の繰り返し問い合わせでは、ルーターの既定IPv4 DNSの中央値が最も短かった。環境やキャッシュが変われば結果も変わるため、常に同じ順位になるとは言えない。

DNSを変更すればダウンロードのMbpsが上がる？

今回の試験はその効果を確認していない。DNSの応答時間と、接続後の転送速度を同じ指標として扱わず、変更前後の同条件の転送試験が必要だ。

DNSの暗号化とWi-Fiの暗号化は同じ？

対象が異なる。今回のDNS試験ではDoHを使わず、Windowsの暗号化表示の検証も行っていない。表示だけから設定変更の効果を判断しないようにしたい。

関連する実測記事

受信・送信速度と負荷時PingはRakuten WiFi Pocket 5Gの実測レビュー、IPv4・IPv6それぞれの通信はIPv4・IPv6のPC実測比較で検証した。測定日時や手法が異なるため、各記事の条件と併せて確認してほしい。