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

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

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

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

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

もうひとつ、以前より判断が難しくなった点があります。クラウドを挟む構成では、同じ社内の通信でも「VPC内は9001まで、インターネットゲートウェイ経由は1500まで」のように、経路ごとに上限が分かれます（2026年8月時点のAWS公式ドキュメント）。つまり「サーバーのNICを9000にした」だけでは設計として成立せず、経路の種類ごとに上限を数え直す作業が必要になりました。オンプレとクラウドを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（最大セグメントサイズ）と呼びます。

ここで実測すると数字が合わない場面に出くわします。TCPはオプション領域を使うため、タイムスタンプ（RFC 1323系のTCP Timestamps）が有効な一般的なLinux環境では、オプション12バイト分が引かれて実効セグメントが1448バイトになります。パケットキャプチャで1460ではなく1448が並んでいても異常ではありません。MTUとMSSは連動して動く、という対応を先に握っておくと、後述のMSSクランプが理解しやすくなります。TCPとIPがそれぞれどの層で何を担うかはTCP/IPの4階層モデルと各層の役割で整理しておくと、MSSの話とMTUの話を混同せずに済みます。

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

1500バイトという値は、初期のイーサネット規格がフレーム長の上限として定めたペイロード幅に由来します。当時の伝送品質と衝突検出の都合から、大きすぎず小さすぎない値として決められたもので、その後LANの主役がイーサネットで固まったため、1500が事実上の共通基準として残りました。フレーム長を大きくすればヘッダ比率は下がりますが、1フレームの伝送時間が延びる分、当時の共有メディアでは衝突時の再送コストが跳ね上がる、という制約がありました。

フレームの構造そのものはイーサネットの規格とフレーム転送の仕組みで扱っていますが、MTUを触るうえでは「1500はイーサネット由来の上限であり、経路の他の技術（PPPoEやトンネル）はこの内側を削って使う」という関係を押さえれば十分です。逆に言えば、1500より大きい値を使いたいときは、経路上のイーサネット機器すべてがその拡張に同意している必要がある、ということでもあります。

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

送りたいIPパケットが経路のMTUを超えると、ルーターはパケットを複数の断片に分割して送ります。これがIPフラグメンテーションで、フラグメンテーションはIP（ネットワーク層）で起きる処理です。層でいうとどこの話かはOSI参照モデルの7階層と各層の役割で位置づけると混乱しません。分割は一見便利ですが、断片が1つでも欠けると全体が再送になり、受信側の再構成負荷も増えるため、性能面では避けたい処理です。

そこでIPヘッダにはDF（Don’t Fragment）ビットがあり、これを立てると「分割禁止」を宣言できます。DFを立てたパケットが途中のMTUを超えると、ルーターは分割せずに破棄し、送信元へ「これ以上は運べない」と通知します。この通知の仕組みが、次章で扱うPMTUDの土台です。ファイアウォールやNAT機器の側から見ると、断片化されたパケットは先頭の断片にしかTCPポート番号が載らないため、フィルタリングの判定材料が欠けるという別の困りごとも生みます。分割を避ける設計が好まれる理由は、性能とセキュリティ検査の両方にあるわけです。

IPv4とIPv6で分割の担当が変わる理由と最小MTU1280の意味

IPv4では、経路の途中にあるルーターがDFビットの立っていないパケットを勝手に分割できます。IPv6はこの設計を捨て、途中ルーターでの分割を禁止し、送信元が経路MTUに合わせて送る方式へ一本化しました。中継機器の処理負荷を下げ、断片化に起因する不具合を減らす狙いです。

実装上の差はエラー通知にも出ます。IPv4で経路MTUを超えたときに返るのはICMPの「Fragmentation Needed（Type 3 Code 4）」ですが、IPv6ではICMPv6の「Packet Too Big（Type 2）」が返ります。ファイアウォールで通すべきメッセージ種別がIPv4とIPv6で別物になる、という点は設定漏れの温床です。加えてIPv6は、すべてのリンクが1280バイト以上のMTUを持つことを要件としており、この1280が下限として保証されています。経路MTUが判然としないIPv6環境では、送信元が1280に落として送る挙動を前提に切り分けると、原因の切り分けが早くなります。

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

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

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

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

IPsecの増加量は暗号化方式やカプセル化の形式で変動するため、正確な値は使用する構成で実測して決めます。WireGuardの側は実装が既定値として1420を設定する例が多く、これはIPv4で60バイト、IPv6で80バイトの外側ヘッダを見込んだ数字です。ここでVLANのタグVLAN（IEEE 802.1Q）の仕組みも関わり、802.1Qのタグは4バイトを追加するため、タグVLANやQ-in-Qを重ねる経路でも同様に実効幅が削られます。

数え方で事故になりやすいのは、オーバーヘッドが1段だとは限らない点です。PPPoEの回線でIPsec VPNを張り、その中をVXLANで運ぶ、といった多段構成では、8＋90＋50のように足し算で積み上がって内側は1350前後まで落ちます。設計時は「経路の途中で何回カプセル化されるか」を先に数え、その合計を1500から引くのが手順になります。

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

PMTUD（Path MTU Discovery）は、送信元が経路上の最小MTUを自動で見つける仕組みです。DFビットを立てたパケットを送り、途中でMTUを超えて破棄されたら、ルーターがICMPの「フラグメント要求（Type3 Code4）」を返し、送信元がそのサイズまでパケットを小さくする、という流れで最小MTUに収束します。

問題は、途中のファイアウォールやNAT機器がこのICMPを一律に遮断している場合です。送信元は破棄されたことにも縮めるべきサイズにも気づけず、大きいパケットだけが延々と失敗します。これがICMPブラックホールで、小さい通信やpingは通るのに、大きなファイル転送やHTTPSの特定ページだけ固まる、という典型症状を生む状態です。クラウド側でも、セキュリティグループやネットワークACLでICMPを落としているとPMTUDの応答が届かない、という注意がAWSの公式ドキュメントに明記されています（2026年8月時点）。NAT経路をまたぐ通信の挙動はNATとNAPT（IPマスカレード）の仕組みと合わせて見ると、どこでICMPが落ちているかを推測しやすくなります。対策の基本は、経路のファイアウォールでType3 Code4のICMP（IPv6ならICMPv6 Type2）だけは通す設定にすることです。

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で大きな通信が不安定なときの第一手はこの設定になります。Linuxのルーターであれば、nftablesやiptablesのTCPMSSターゲットで、SYNパケットのMSSを経路MTUに合わせて書き換える設定を入れる形です。

割り切っておくべき限界もあります。MSSクランプが効くのはTCPの3ウェイハンドシェイクを覗ける経路だけで、IPsecで暗号化された内側のTCPヘッダには手が届きません。トンネルの外側でクランプしても内側には効かない、という順序の問題が起きるため、設定はトンネルの内側インターフェースに入れる、という原則を守ります。UDPを使う通信に効かない点は、次の項で扱います。

QUICなどUDP通信でMSSクランプが効かない経路への備え

HTTP/3が土台に据えるQUICはUDPの上で動くため、TCP MSSの広告値そのものが存在せず、MSSクランプという手段が使えません。代わりにQUICは、初期パケットを1200バイト前後という控えめなサイズに固定し、通信が成立してから徐々にサイズを探る設計を採っています。プロトコルの詳細はQUICの仕組みとTCPとの違いで扱っていますが、MTU設計の観点では「UDP系の新しいプロトコルは、経路MTUを自分で探る責任を持っている」と理解しておけば足ります。

この自力探索の仕組みがPLPMTUD（Packetization Layer Path MTU Discovery、RFC 8899）です。ICMPの応答に頼らず、少しずつ大きい探索パケットを送って「届いたかどうか」で経路MTUを判定するため、ICMPブラックホールの経路でも収束します。Linuxカーネルにも同種の仕組みが備わっており、TCPでもICMPが返らない環境で使われます。運用側の備えとしては、UDPベースの通信で大きなデータだけ詰まる症状が出たら、MSSクランプではなくアプリ側の最大データグラムサイズ設定と、経路の実効MTUの実測から当たるのが順序です。

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

ジャンボフレームは標準1500を9000バイト前後まで拡張する設定で、1パケットあたりのヘッダ処理回数を減らせるため、大容量転送でCPU負荷と実効スループットを改善できます。効果が明確なのは、ストレージのiSCSIやNFS、バックアップ、仮想化基盤のノード間通信といった、経路が閉じていて大きな連続転送が発生する場面です。

採用してよいのは「経路上のNIC・スイッチ・相手ホストまで全てを同じ9000で揃えられる自社閉域」に限ります。逆に、インターネットや外部と通信する経路、機器のMTU設定を統一できない混在環境では、1台でも1500のままの機器が混じった瞬間に不整合を起こすため、ジャンボフレームは見送り、標準1500を維持するのが基本になります。

効果の見積もりも冷静にやるべきです。1500バイトのフレームではヘッダのオーバーヘッド比率がおよそ3％、9000バイトなら0.5％前後まで下がりますが、帯域の節約幅としては数％にとどまります。ジャンボフレームの実利はむしろ、同じデータ量を運ぶのに必要なパケット処理回数が6分の1になる点、つまりCPU割り込みの削減です。NICのオフロード機能（TSO・LROなど）が効いている環境では、この差がさらに縮む場合もあるため、投入前後でスループットとCPU使用率の両方を測って判断します。

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の設定根拠です。なおWindowsのPowerShell環境ではTest-Connection -TargetName 宛先 -MtuSizeでも同じ探索を自動化でき、二分探索を手作業で回す手間を省けます。

tracepathとキャプチャで経路MTUの縮む地点を特定する方法

pingでわかるのは「経路全体の最小値」までで、どのホップで縮んだかまでは判別できません。縮む地点の当たりをつけたいときは、Linuxのtracepath 宛先が便利です。経路をたどりながら、途中でMTUが変わった地点を「pmtu」の表示として出してくれるため、自社ルーターの先なのかキャリア側なのか、責任分界の議論に使える材料になります。

それでも判然としない場合は、パケットキャプチャに切り替えます。tcpdumpやWiresharkで、ICMPのType3 Code4が返ってきているか、TCPのSYNに載ったMSS値がどこで書き換わっているかを直接見ることが、推測を事実に変える方法です。特に「クランプを設定したのに効かない」という相談の多くは、キャプチャを取るとSYNのMSS広告が想定と違う値のまま流れており、設定を入れたインターフェースが経路の向きと合っていない、という単純な原因に着地します。

AWS・Azure・Google Cloudで異なるMTU上限と経路ごとの制約

クラウドを含む構成では、事業者ごとに既定値と上限が違い、同じアカウント内でも経路の種類で上限が分かれます。各社の公開ドキュメントで確認できる値は次のとおりです（2026年8月時点）。

読み取るべき差は3点あります。第一に、Google CloudのVPCは既定値が1460であり、1500ではありません。設定できる範囲は1300から8896までで、オンプレ側の1500と揃えるつもりなら明示的に変更する操作が要ります。第二に、Azureで1500を超えられるのは同一リージョンの仮想ネットワーク内と直接ピアリングした範囲に限られ、値もNICの種類に応じた3900と9000の2通りです。第三に、AWSはVPC内なら9001まで通る一方、インターネットゲートウェイやVPN接続を通る瞬間に1500へ落ちます。

この差が効いてくるのは、オンプレとクラウドをVPNで結ぶハイブリッド構成です。クラウド側で9001を設定していても、VPNトンネルを渡る通信は1500から暗号化ヘッダ分を引いた値まで縮むため、両端の設定を揃えたつもりでも経路の中央がボトルネックになります。専用線サービス（AWSのDirect Connectなど）を使えばジャンボフレームを維持できる経路もあるため、大容量のデータ同期を伴う設計では接続方式の選定段階からMTUを条件に入れておくのが安全です。

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

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

• 外部・複数拠点をまたぐ一般的な経路は、標準1500を基準にし、下手に上げない（互換性が最優先）。
• VPN・トンネルを挟む経路は、実測した実効MTUに合わせて内側MTUを下げるか、TCPならMSSクランプで合わせる。
• 閉じた自社ネットワークで大容量転送が主目的の区間だけ、全機器を揃えられるならジャンボフレーム化を検討する。
• クラウドを含む経路は、事業者の上限表と接続方式（IGW・VPN・専用線）を突き合わせ、区間ごとに別の値を持つ前提で設計する。

設定箇所は、サーバー/PCのNIC、ルーターやスイッチの各インターフェース、VPN装置と、経路上のすべてが対象です。1箇所だけ変えても経路の最小値に律速されるため、「経路全体でどこが最小MTUか」を意識して揃えるのが原則になります。仮想化基盤を挟む場合は、物理NIC・仮想スイッチ・仮想マシンのNICという3層すべてに設定が要る点も見落としがちです。設定変更は再起動で戻る実装があるため、恒久化の手順（Linuxならディストリビューションの設定ファイル、WindowsならSet-NetIPInterface）まで含めて手順書に落としておきます。

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

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

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

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

よくある質問

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

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

1500バイトはイーサネットが定めたフレームのペイロード上限に由来します。イーサネットが有線LANの事実上の標準として広く普及したため、その1500がネットワーク全体の共通基準として残りました。IPパケット（IPヘッダ＋データ）で1500まで、実際のフレームはこれにイーサネットヘッダとFCSが加わって最大1518バイトになります。なおGoogle CloudのVPCのように、既定値を1460に置いている環境もあるため、クラウドでは1500を前提にしない確認が要ります。

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

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

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

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

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

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

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

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

関連記事

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