Rakuten WiFi Pocket 5GのMTUは1500でいい？分割禁止Pingを実測

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

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

Rakuten WiFi Pocket 5Gに接続したWindowsでMTUが1500と表示されていれば、外部にも1500byteのIPv4パケットが通るのか。設定を変えずに、サイズを変えた分割禁止Pingで新しく測定した。ルーター宛ては1500byte相当で5回すべて成功。外部のCloudflareとGoogle宛てでは、1380byte相当が各3回成功し、1byte大きい1381byte相当は各3回ともPacketTooBigだった。

これは今回のIPv4・ICMPで観測した通過サイズの境界であり、PCやルーターを1380に変更すれば速くなるという試験ではない。WindowsのインターフェイスMTU表示は、開始時も終了時も1500だった。

ネット上の疑問：MTUの表示とPingの最大サイズはなぜ違う？

Microsoft Q&Aには、分割禁止Pingで通るデータ長と、Windowsに表示されるMTU1500が一致しないという質問がある。Microsoft Q&Aの質問

楽天回線のMTU・MSSについても、価格.comにはRakuten WiFi Pocket 5Gの初期値に言及した利用者の投稿がある。ただし、投稿の中心は別機種L13の運用であり、メーカーが保証した共通の設定値ではない。本記事では設定値を写すのではなく、このPCから通る範囲を確認した。楽天回線のMTU・MSSに関する投稿

Pingのデータ長とMTUは同じ数値ではない

Windowsのping -lで指定するのはICMP Echoのデータ部分の長さで、IPv4パケット全体の長さではない。-fはIPv4の分割禁止フラグを指定する。本記事の「IPv4合計」は、IPオプションなしのIPv4ヘッダー20byteとICMP Echoヘッダー8byteを加え、データ長＋28byteで整理した。Wi-Fiのフレームや携帯網内部のカプセル化を含めた通信量ではない。Microsoftのping資料、RFC 791、RFC 792

例えばデータ長1472byteはIPv4合計1500byteに相当する。今回はIPv4だけを対象とし、IPv6のヘッダー長や経路MTUをこの足し算で評価していない。

最初の90回：ルーター宛てと外部宛てで結果が分かれた

各サイズを各宛先に5回ずつ、計90回実行した。外部宛ては1.1.1.1と8.8.8.8へのICMP Echoで、DNS問い合わせやWebページの取得ではない。ルーター宛てには1472byteのデータが5回すべて返ったが、外部宛ては1372byte以上でPacketTooBigとなった。

PacketTooBigは応答待ちのタイムアウトとは異なる。今回使った.NETのPingOptionsで分割を禁止すると、経路のMTUに対して大きすぎるデータはこの状態で失敗する。成功として数えたのはEcho応答が正常に返ったSuccessだけで、エラー通知を受信成功に混ぜていない。MicrosoftのPingOptions.DontFragment資料

追加26回：1380byteと1381byteの境界を確認

外部2宛先について、最初に通ったデータ長1200byteと失敗した1372byteの間を二分探索した。各宛先7回の探索でデータ長1352byteの成功と1353byteのPacketTooBigを確認し、その2サイズをさらに交互に3回ずつ再確認した。

この時間帯・この2宛先へのICMP試験では、IPv4合計1380byteが通り、1381byteが通らない境界を観測した。すべてのインターネット接続先、別の時間、別の場所でも同じになると保証する数値ではない。

また、試験の途中でWindowsが経路MTUを学習すると、大きすぎる要求がローカルで即座に拒否されることがある。今回はネットワーク上のパケットをキャプチャしていないため、後続のPacketTooBigがどこで生成されたかをすべて特定したものではない。116回という数はPing APIの実行回数で、116個すべてが外部に送出されたことを示さない。

Windowsで設定を変えずに確認する例

次の例はPingの送信条件を指定するだけで、ネットワークアダプターやルーターのMTUを書き換えない。今回と同じ数値を使う場合も、自分の接続先・環境の結果として読み取ってほしい。

netsh interface ipv4 show subinterfaces
ping -4 -f -l 1472 -n 3 -w 1500 1.1.1.1
ping -4 -f -l 1352 -n 3 -w 1500 1.1.1.1
ping -4 -f -l 1353 -n 3 -w 1500 1.1.1.1

記事の数値はPowerShellから.NETのPingクラスを呼び出して取得した。タイムアウトだけが発生した場合は、大きさが原因とは決められない。ICMPに応答しない接続先や、経路・混雑などの影響も含めて追加の確認が必要になる。

MTUを1380へ変更するべき？

今回の結果だけで、一律に1380へ変更することは勧められない。経路上を通るICMPのサイズ、WindowsのインターフェイスMTU、ルーターの設定値、TCPのMSSは区別する必要がある。今回ルーターの管理画面のMTU・MSS値は確認しておらず、設定変更前後のダウンロード速度やアプリの不具合改善も測っていない。

この検証で得られたのは、PCに表示された1500と外部宛ての分割禁止Pingの通過サイズが一致しなかったという事実だ。普段の通信が遅い原因をMTUだけに限定したり、1380が全ユーザー共通の最適値だと扱ったりはできない。

測定条件と失敗を含めた記録

PCはWindows 11 Pro、無線LANはIntel Dual Band Wireless-AC 8265。2.4GHz・802.11n・チャネル6・リンク速度144.4Mbpsで接続し、開始時の電波表示は97%、RSSIは−34dBmだった。開始・終了時の同一ルーターへの接続と、IPv4・IPv6の既定経路がWi-Fiであることを確認した。携帯回線側の4G・5Gの利用状態は未確認だ。

分割禁止、TTL128、1要求の待機上限1500ms、要求間隔は最低約0.3秒。最初の6サイズ×3宛先×5回に、外部2宛先の探索・再確認26回を加え、計116回実行した。結果はSuccess64回、PacketTooBig52回、タイムアウト0回だった。設定したデータ長の合計は138,517byteだが、実際の回線使用量や課金対象通信量を測った数値ではない。

サイズの順番は最初の試験で昇順・降順を交互にし、先に試す宛先も巡回させた。1台・1か所・約1分半の結果で、他端末やバックグラウンド通信は管理していない。IPv6、TCP転送、USB・5GHz接続、MTU設定変更の効果、ゲームや会議アプリの実動作は今回の検証範囲外だ。

MTU実測のよくある質問

Windowsに1500と表示されるのは間違い？

今回、PCのインターフェイスMTUは開始時・終了時とも1500で、ルーター宛てのIPv4合計1500byteも通った。外部への経路全体で通る上限と、その表示を同じものとして扱わないことが大切だ。

1380byteならインターネット全体で必ず通る？

保証できない。今回確認したのは、同じ場所・時間帯からCloudflareとGoogleの2宛先へ送ったIPv4のICMP Echoだ。別の経路やIPv6、TCPの条件は別に確認する必要がある。

MTU変更で速度が上がることを実証した？

実証していない。今回は設定を変えずに通過サイズだけを測り、変更前後の転送速度は比較していない。

関連する実測記事

速度と負荷時PingはRakuten WiFi Pocket 5G実測レビュー、IP方式別の通信はIPv4・IPv6比較、名前解決の待ち時間はDNS変更の比較実測で確認した。各記事は別の新規測定で、日時と試験条件が異なる。