MTUとは？最大転送単位の仕組み・1500とジャンボフレーム・PMTUD/MSS調整と測定手順を実装者向けに解説

MTU（Maximum Transmission Unit＝最大転送単位）は、ネットワークの1回の送信で運べるデータ本体の上限バイト数を指します。イーサネットの標準は1500バイトで、この値はVPNやトンネルを挟むと縮みます。経路の途中で不整合を起こすと、pingは通るのに大きな通信だけが止まる、という厄介な障害の引き金です。この記事では、標準1500バイトがどこから来たのか、IP層でのフラグメンテーションとDFビットの関係、PPPoE・VPN・VXLANでMTUが縮む理由とオーバーヘッドの数え方、PMTUD（経路MTU探索）が失敗するICMPブラックホール、TCP MSSクランプによる回避、ジャンボフレーム9000バイトを使ってよい条件、そしてpingでMTUを実測してトラブルを切り分ける手順までを、設計・運用する実装者の判断基準で整理します。

まとめ：MTU設計で先に押さえる結論

MTUは「1フレームに載るデータ本体の上限」で、イーサネットの標準値1500バイトが事実上の基準になっています。設計で効いてくるのは、この1500を上げる（ジャンボフレーム）か、経路の事情に合わせて下げるか、という2方向の判断です。

判断の勘所は3つに絞れます。第一に、インターネットや複数拠点をまたぐ経路では標準1500を基準にし、むやみに大きくしない。第二に、VPN・PPPoE・VXLANなどヘッダを追加する経路では、そのオーバーヘッド分だけ内側のMTU（またはTCP MSS）を下げて不整合を防ぐ。第三に、ジャンボフレーム（9000バイト前後）は経路上の全機器を同じ値で揃えられる自社閉域（ストレージ間・仮想化基盤間）に限定して投入する。MTUの不整合は「小さい通信は成功し、大きい通信だけ止まる」という形で表面化するため、症状からMTUを疑えるかどうかが切り分け速度を決めます。オンプレとクラウドをVPNやトンネルでつなぐ構成でMTU設計に踏み込みたい場合は、インフラ構築（AWS/GCP/Azure）の相談窓口で経路全体を含めて検討するのが近道です。

MTUの定義とイーサネット1500の由来・IP層フラグメンテーションの仕組み

MTUを調整判断に使うには、まず「何の上限か」と「上限を超えたときネットワークが何をするか」を押さえる必要があります。ここを飛ばすと、後半のPMTUDやMSSの話が丸暗記になります。

MTUの定義とペイロード・MSS・フレームサイズの計算上の関係

MTUは、IPパケット（IPヘッダを含むデータ本体）としてリンク層が1回で運べる最大バイト数を指します。イーサネットで標準MTUが1500の場合、この1500はIPヘッダとその中身を合わせた上限で、実際のフレームはこれにイーサネットヘッダ14バイトとFCS4バイトが加わり、全体では最大1518バイトです。TCP通信では、この1500からIPヘッダ20バイトとTCPヘッダ20バイト（IPv4の基本形）を引いた1460バイトが、1セグメントで運べるアプリデータの上限で、これをMSS（最大セグメントサイズ）と呼びます。MTUを調整すると連動してMSSも変わる、という対応を先に握っておくと、後述のMSSクランプが理解しやすくなります。

標準1500バイトがイーサネットフレームのペイロード幅に由来する理由

1500バイトという値は、初期のイーサネット規格がフレーム長の上限として定めたペイロード幅に由来します。当時の伝送品質と衝突検出の都合から、大きすぎず小さすぎない値として決められたもので、その後LANの主役がイーサネットで固まったため、1500が事実上の共通基準として残りました。フレームの構造そのものはイーサネットの規格とフレーム転送の仕組みで扱っていますが、MTUを触るうえでは「1500はイーサネット由来の上限であり、経路の他の技術（PPPoEやトンネル）はこの内側を削って使う」という関係を押さえれば十分です。

MTUを超えたときのIPフラグメンテーションとDFビットの働き

送りたいIPパケットが経路のMTUを超えると、ルーターはパケットを複数の断片に分割して送ります。これがIPフラグメンテーションで、フラグメンテーションはIP（ネットワーク層）で起きる処理です。層でいうとどこの話かはOSI参照モデルの7階層と各層の役割で位置づけると混乱しません。分割は一見便利ですが、断片が1つでも欠けると全体が再送になり、受信側の再構成負荷も増えるため、性能面では避けたい処理です。そこでIPヘッダにはDF（Don’t Fragment）ビットがあり、これを立てると「分割禁止」を宣言できます。DFを立てたパケットが途中のMTUを超えると、ルーターは分割せずに破棄し、送信元へ「これ以上は運べない」と通知します。この通知の仕組みが、次章で扱うPMTUDの土台です。IPv6ではそもそも途中ルーターでの分割を行わず、送信元が経路MTUに合わせる方式に一本化されています。

経路MTUが縮む理由とPMTUD・MSSクランプによるオーバーヘッド対策

実務でMTUが問題になるのは、単一のLANではなく、VPNやトンネルを挟んで複数の経路をまたぐときです。ここで「なぜ縮むのか」と「縮んだ経路をどう成立させるか」を分けて整理します。

PPPoE・VPN・VXLANでMTUが縮むオーバーヘッドの数え方

MTUが縮むのは、元のパケットの外側に新しいヘッダを付け足す技術が経路に入るからです。付けた分だけ、内側で使える幅が減ります。代表例のオーバーヘッド量は次のとおりで、いずれも元の1500から差し引いて内側の実効MTUを見積もります。

IPsecの増加量は暗号化方式やカプセル化の形式で変動するため、正確な値は使用する構成で実測して決めます。ここでVLANのタグVLAN（IEEE 802.1Q）の仕組みも関わり、802.1Qのタグは4バイトを追加するため、タグVLANやQ-in-Qを重ねる経路でも同様に実効幅が削られます。オーバーヘッドは足し算で積み上がる、という点が設計の起点です。

PMTUD（経路MTU探索）の仕組みとICMPブラックホールという失敗

PMTUD（Path MTU Discovery）は、送信元が経路上の最小MTUを自動で見つける仕組みです。DFビットを立てたパケットを送り、途中でMTUを超えて破棄されたら、ルーターがICMPの「フラグメント要求（Type3 Code4）」を返し、送信元がそのサイズまでパケットを小さくする、という流れで最小MTUに収束します。問題は、途中のファイアウォールやNAT機器がこのICMPを一律に遮断している場合です。送信元は破棄されたことにも縮めるべきサイズにも気づけず、大きいパケットだけが延々と失敗します。これがICMPブラックホールで、小さい通信やpingは通るのに、大きなファイル転送やHTTPSの特定ページだけ固まる、という典型症状を生む状態です。NAT経路をまたぐ通信の挙動はNATとNAPT（IPマスカレード）の仕組みと合わせて見ると、どこでICMPが落ちているかを推測しやすくなります。対策の基本は、経路のファイアウォールでType3 Code4のICMPだけは通す設定にすることです。

TCP MSSクランプで縮んだ経路にTCP通信を合わせる方法

PMTUDに頼れない経路でも、TCP通信ならMSSクランプ（MSS clamping）で確実に成立させられます。TCPは接続を確立するときに、双方が「自分はこのMSSまで受け取れる」と広告します。経路の途中のルーターやVPN装置が、このMSS広告値を経路の実効MTUに合わせて書き換える（下げる）のがMSSクランプです。たとえば実効MTUが1400なら、MSSを1360（1400からIP20・TCP20を引いた値）に固定すれば、TCPは最初から小さいセグメントで送るため、フラグメンテーションもDF破棄も起きません。VPNルーターの多くが「MSS clamping」や「MSS調整」という設定項目を備えており、拠点間VPNで大きな通信が不安定なときの第一手はこの設定です。ただしMSSクランプが効くのはTCPだけで、UDPを使う通信（一部のVPNやリアルタイム通信）には効かない点は割り切って設計します。

ジャンボフレーム（MTU 9000）を採用してよい条件と見送る場面

ジャンボフレームは標準1500を9000バイト前後まで拡張する設定で、1パケットあたりのヘッダ処理回数を減らせるため、大容量転送でCPU負荷と実効スループットを改善できます。効果が明確なのは、ストレージのiSCSIやNFS、バックアップ、仮想化基盤のノード間通信といった、経路が閉じていて大きな連続転送が発生する場面です。採用してよいのは「経路上のNIC・スイッチ・相手ホストまで全てを同じ9000で揃えられる自社閉域」に限ります。逆に、インターネットや外部と通信する経路、機器のMTU設定を統一できない混在環境では、1台でも1500のままの機器が混じった瞬間に不整合を起こすため、ジャンボフレームは見送り、標準1500を維持するのが基本です。クラウドでは、AWSのVPC内は9001までのジャンボフレームに対応する一方、インターネットゲートウェイやVPN経由の経路では1500に制限されるなど、経路ごとに上限が分かれます。クラウドとオンプレをまたぐMTU設計は、対応上限が経路で変わる前提で組む必要があります。

MTU値の決め方とpingでの実測手順・不整合トラブルの切り分け

設計値を机上で決めるだけでは足りません。実際の経路MTUを測り、症状からMTU問題を疑える手順にしておくと、原因不明の通信断に振り回されずに済みます。

pingコマンドでDFビットを立てて経路MTUを実測する手順

経路の実効MTUは、DFビットを立てたpingでサイズを変えながら探ると実測できます。分割禁止の状態でサイズを上げ、「通る最大サイズ」を見つけ、ヘッダ分を足し戻してMTUを求めます。

1. Windowsはping -f -l 1472 宛先、Linuxはping -M do -s 1472 宛先で、分割禁止のまま送信する（1472はデータ部＝MTU1500からIP20・ICMP8を引いた値）。
2. 成功すればサイズを上げ、失敗（「パケットの分割が必要」等）すれば下げて、成功する最大のデータ部サイズを二分探索で特定する。
3. 見つけた最大データ部サイズに28バイト（IP20＋ICMP8）を足した値が、その経路の実効MTUになる。

たとえばデータ部1400までしか通らなければ、経路の実効MTUは1428ということになり、VPNやトンネルによる縮みを数値で裏づけられます。この実測値を、MSSクランプや内側MTUの設定根拠にします。

MTUを上げるか下げるかを経路ごとに決める判断基準と設定箇所

MTUをどう決めるかは、経路の性質で言い切れます。以下の優先順位で判断します。

• 外部・複数拠点をまたぐ一般的な経路は、標準1500を基準にし、下手に上げない（互換性が最優先）。
• VPN・トンネルを挟む経路は、実測した実効MTUに合わせて内側MTUを下げるか、TCPならMSSクランプで合わせる。
• 閉じた自社ネットワークで大容量転送が主目的の区間だけ、全機器を揃えられるならジャンボフレーム化を検討する。

設定箇所は、サーバー/PCのNIC、ルーターやスイッチの各インターフェース、VPN装置と、経路上のすべてが対象です。1箇所だけ変えても経路の最小値に律速されるため、「経路全体でどこが最小MTUか」を意識して揃えるのが原則です。

MTU不整合を疑うべき通信症状のパターンと切り分けの実務手順

MTU問題は独特の症状を出すため、パターンを覚えておくと切り分けが速くなります。次の順で確認します。

1. 「小さい通信（pingやSSHログイン）は成功するのに、大きな通信（ファイル転送・特定Webページの表示・DBの大きな結果取得）だけ固まる」症状が出ていないかを確認する。この非対称性が出たらMTUを最優先で疑う。
2. DFビット付きpingで経路の実効MTUを実測し、想定（1500や設定値）と食い違っていないかを見る。
3. 食い違いがあれば、経路上のVPN・PPPoE・トンネルのオーバーヘッドと突き合わせ、縮んでいる箇所を特定する。
4. PMTUDが効いていない疑いがあれば、途中のファイアウォールでICMP Type3 Code4が遮断されていないかを確認し、TCPはMSSクランプで暫定回避する。

この順序を守ると、「アプリやサーバーの不具合」と誤認して延々とアプリ側を調べる遠回りを避けられます。オンプレとクラウドをVPNでつないだ経路でこの切り分けが複雑になる場合は、インフラ構築（AWS/GCP/Azure）として経路全体のMTU・トンネル構成を含めて相談すると、責任分界と設定箇所を一度に整理できます。

よくある質問

MTUに関して実務でよく挙がる疑問を、設計・切り分けの観点から簡潔に答えます。

MTUの標準値が1500なのはなぜですか？

1500バイトはイーサネットが定めたフレームのペイロード上限に由来します。イーサネットが有線LANの事実上の標準として広く普及したため、その1500がネットワーク全体の共通基準として残りました。IPパケット（IPヘッダ＋データ）で1500まで、実際のフレームはこれにイーサネットヘッダとFCSが加わって最大1518バイトになります。

MTUとMSSの違いは何ですか？

MTUはIPパケット全体（IPヘッダを含む）としてリンクが運べる最大バイト数、MSSはそのうちTCPで運べるアプリデータの最大バイト数です。IPv4の基本構成では、MSSはMTUからIPヘッダ20バイトとTCPヘッダ20バイトを引いた値になり、MTU1500ならMSSは1460です。MTUを変えるとMSSも連動して変わります。

MTUを大きくすれば通信は速くなりますか？

常に速くなるわけではありません。ジャンボフレーム（9000前後）はヘッダ処理の回数を減らせるため、閉じた経路での大容量連続転送では効果が出ます。一方、経路上に1台でも標準1500の機器が混ざると不整合で通信が不安定になり、かえって遅くなります。全機器を揃えられる自社閉域に限定して使うのが前提です。

VPNをつないだら大きな通信だけ止まるのはなぜですか？

VPNは元のパケットの外側に暗号化ヘッダを追加するため、内側で使える実効MTUが1400前後まで縮みます。加えて途中のファイアウォールがPMTUD用のICMPを遮断していると、送信元が縮小に気づけず大きな通信だけ失敗します（ICMPブラックホール）。対策は、実効MTUに合わせたTCP MSSクランプの設定と、ICMP Type3 Code4を通す設定です。

経路のMTUを調べるにはどうすればよいですか？

DFビット（分割禁止）を立てたpingで実測します。Windowsはping -f -l サイズ 宛先、Linuxはping -M do -s サイズ 宛先で、通る最大のデータ部サイズを見つけ、そこに28バイト（IPヘッダ20＋ICMP8）を足した値がその経路のMTUです。想定値と食い違えば、VPNやトンネルによる縮みを疑います。

関連記事

• イーサネットとは？IEEE 802.3規格・速度と配線・VLAN/LACP設計まで実装者向けに解説：標準MTU1500の由来であるイーサネットフレームの仕組みを、規格の全体像から確認できます。
• OSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違い：フラグメンテーションが起きるIP（ネットワーク層）の位置づけを、7階層の中で整理できます。
• VLANとは？仕組み・ポートVLAN/タグVLAN・IEEE 802.1QからVLAN間ルーティング設計まで実装者向けに解説：802.1Qタグがオーバーヘッドとして実効MTUを削る点を、VLAN設計と合わせて確認できます。
• NATとは？仕組み・NAPT（IPマスカレード）との違い・静的/動的NATからクラウド実装まで実装者向けに解説：NAT経路でPMTUDのICMPがどこで落ちるかを推測する手がかりになります。