Windows 11でDHCPのMTU(オプション26)が反映されない原因と対処法【PPPoE/1492対応】

PPPoE や一部のブロードバンド環境では MTU を 1492 に落とす必要がありますが、Windows 11 は DHCP サーバーから配布された MTU（オプション 26）を採用してくれません。その結果、フラグメントや通信エラーに悩まされている方も多いはずです。本記事では「なぜそうなるのか」「どう設定すればよいのか」「複数台をどう運用するか」まで、Windows 11 特有の挙動に踏み込んで解説します。

Windows 11 が DHCP オプション 26 の MTU を無視する理由

まず押さえておきたい前提は次の通りです。

Windows クライアントは標準仕様として DHCP オプション 26（Interface MTU）を参照しません。
Windows 11 側に「DHCP で通知された MTU を採用する」といったトグル設定は存在しません。
そのため、MTU の制御はクライアント OS 側で明示的に行う必要があります。

Linux や一部の組み込み OS では、DHCP オプション 26 を解釈してインターフェイス MTUを自動調整する実装もありますが、Windows は設計思想として「ネットワークスタックの主要パラメータは OS 管理」となっています。DHCP はあくまで IP アドレスや DNS など一部のパラメータだけに限定して解釈する方針です。

項目	Windows 11 の挙動
DHCP オプション 3（デフォルトゲートウェイ）	採用する
DHCP オプション 6（DNS サーバー）	採用する
DHCP オプション 26（Interface MTU）	無視する（デフォルトの 1500 を維持）

この仕様は Windows 10 世代から一貫しており、Windows 11 になっても変わっていません。そのため、PPPoE 環境などで MTU 1492 を DHCP から配布しても、Windows 11 クライアント側は 1500 のまま動作してしまいます。

MTU・MSS・PPPoE の関係を整理する

なぜ MTU を 1492 に合わせないと困るのか、改めて整理しておきます。

MTU（Maximum Transmission Unit）：1 パケットあたりの最大フレーム長（レイヤ 3 基準）。
MSS（Maximum Segment Size）：TCP が 1 セグメントに載せる最大のデータ長（レイヤ 4）。基本的に MTU から IP/TCP ヘッダを差し引いた値になります。
PPPoE：イーサネットフレームに PPPoE ヘッダ分のオーバーヘッドが乗るため、実効 MTU が 1500 → 1492 に小さくなることが多い方式です。

回線/方式	一般的な MTU	備考
IPv4 + PPPoE（フレッツ光, ADSL など）	1492	PPPoE ヘッダ分 8 バイト分が削られる
IPv4 + IPoE (v6 プラス/DS-Lite など)	1500（または ISP 指定値）	PPPoEヘッダがないため 1500 のケースが多い
企業 VPN（IPsec トンネルなど）	1400 前後	カプセル化のオーバーヘッドでさらに小さくなる

Windows 11 の NIC が 1500 のまま、下流のブロードバンドルーター側が 1492 の MTU だった場合、

フラグメント（断片化）の発生
一部機器や FW による「ICMP フラグメント不要メッセージ」のブロック
結果として特定サイトだけ表示が遅い・タイムアウトする

といった現象が起きやすくなります。これを避けるためには、クライアント側の MTU を回線側に合わせて 1492 に落としておくのが確実な対策です。

現在の MTU を確認する方法

PowerShell で確認する

管理者権限で PowerShell を開き、次のコマンドを実行します。

Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, NlMtuBytes

主な列の意味は以下の通りです。

列	内容
InterfaceAlias	「イーサネット」「Wi-Fi」などのインターフェイス名
AddressFamily	IPv4 / IPv6 の別
NlMtuBytes	そのアドレスファミリに対する MTU 値（バイト）

netsh で確認する（IPv4）

コマンドプロンプト（管理者）で次のコマンドを実行します。

netsh interface ipv4 show subinterfaces

出力の「MTU」列に 1500 などの値が表示されます。ここが 1492 に変わっていれば、IPv4 の MTU 固定ができていると判断できます。

対処法 1：PowerShell で MTU を固定する（推奨）

もっとも扱いやすく、Windows 11 らしい方法が PowerShell による設定です。

有効な NIC を一括で 1492 に設定する

PPPoE 回線しか使わない PC などでは、単純に「有効な NIC は全部 1492」で問題ないことも多いです。

# 有効な NIC の MTU を一括で 1492 に変更
Get-NetAdapter |
  Where-Object Status -eq Up |
  Set-NetIPInterface -NlMtuBytes 1492

このコマンドは IPv4 / IPv6 両方の MTU に同じ値を設定します（環境によっては AddressFamily を絞り込むことも可能です）。

特定のインターフェイスだけ MTU を変更する

有線だけ、Wi-Fi だけといった指定をしたい場合は InterfaceAlias を用います。

# 有線 LAN の MTU を 1492 に
Set-NetIPInterface -InterfaceAlias "Ethernet" -NlMtuBytes 1492

# Wi-Fi の MTU を 1492 に
Set-NetIPInterface -InterfaceAlias "Wi-Fi" -NlMtuBytes 1492

インターフェイス名は日本語環境だと「イーサネット」などになります。Get-NetAdapter で事前に確認しておきましょう。

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status

なお、古い情報では -NlMtu パラメータの例も見かけますが、Windows 10 / 11 の Set-NetIPInterface では通常 -NlMtuBytes を使用します。

実行手順（具体例）

スタートボタンを右クリックし、「Windows Terminal（管理者）」または「PowerShell（管理者）」を開く。
現在の MTU を確認する。 Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, NlMtuBytes
対象のインターフェイス名を確認する。 Get-NetAdapter | Select-Object Name, Status
MTU を 1492 に設定する。 Set-NetIPInterface -InterfaceAlias "イーサネット" -NlMtuBytes 1492
再度 MTU を確認し、値が 1492 になっていることを確認する。

よくあるエラーと対処

症状	原因/対処
アクセスが拒否されました	管理者権限で PowerShell を開いていない可能性があります。「管理者として実行」で開き直してください。
指定されたインターフェイスが見つかりません	InterfaceAlias の表記ゆれ（「Ethernet」と「イーサネット」など）が考えられます。`Get-NetAdapter` の出力からコピーペーストするのが安全です。
一部の仮想 NIC にも MTU が設定されてしまう	一括設定コマンドを使った場合、Hyper-V や VPN クライアントの仮想 NIC も含まれます。必要に応じて `InterfaceDescription` などでフィルタリングしてください。

対処法 2：netsh で IPv4 の MTU を固定する

従来のコマンドラインツール netsh を使った設定方法です。スクリプト資産が netsh ベースである場合などに有効です。

インターフェイス名を確認する

netsh interface ipv4 show subinterfaces

ここで表示される「インターフェイス」列の名称を後で使用します。

MTU を 1492 に設定する

例として、インターフェイス名が「イーサネット」の場合：

netsh interface ipv4 set subinterface "イーサネット" mtu=1492 store=persistent

mtu=1492：設定したい MTU 値。
store=persistent：再起動後も設定を維持するオプション。

netsh の注意点として、この設定は IPv4 の MTU に対してのみ有効であり、IPv6 側は別途 PowerShell で制御する必要がある点に留意してください。

対処法 3：レジストリで MTU を固定する（上級者向け）

どうしてもスクリプトが実行できない環境や、詳細な制御が必要な場合の最終手段としてレジストリ編集があります。誤操作で OS が起動しなくなるリスクもあるため、事前バックアップが必須です。

対象インターフェイスの GUID を調べる

PowerShell で NIC の GUID を確認します。

Get-NetAdapter | Select-Object Name, InterfaceGuid

ここで得た InterfaceGuid をメモしておきます。

レジストリを編集する

regedit を起動する（Win + R → regedit）。
次のキーに移動する。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
配下のキーの中から、先ほど控えた GUID と一致するものを探す。
右ペインで右クリック → 新規 → DWORD（32 ビット）値を作成し、名前を MTU にする。
MTU をダブルクリックし、「10 進数」を選択して 1492 と入力する。
PC を再起動する。

値を削除するか 0 に戻すと、デフォルト値（通常 1500）で動作するようになります。

複数 PC や動的切り替えが必要な場合の運用例

自宅や小規模オフィスなどで複数台の Windows 11 を運用している場合、1 台ずつ手で設定するのは現実的ではありません。また、ノート PC が「PPPoE 回線の自宅」と「1500 が通る社内 LAN」を行き来するケースもあります。このような場合は、スクリプトによる自動化が有効です。

グループポリシー（GPO）のスタートアップスクリプトで配布

ドメイン参加済み PC であれば、GPO のコンピュータのスタートアップスクリプトとして PowerShell を配布するのが定番です。

# 例：Ethernet の MTU を 1492 に固定するスクリプト
$if = Get-NetAdapter | Where-Object { $_.Status -eq "Up" -and $_.Name -like "Ethernet*" }
if ($if) {
    $if | ForEach-Object {
        Set-NetIPInterface -InterfaceAlias $_.Name -NlMtuBytes 1492
    }
}

これをドメインコントローラの共有フォルダに配置し、GPO からスタートアップスクリプトとして登録すれば、起動時に自動で MTU が設定されます。

タスクスケジューラで「ネットワーク接続時」にトリガー

スタンドアロン PC やワークグループ環境では、タスクスケジューラを使って「ネットワークに接続された時」にスクリプトを実行する方法があります。

トリガー：イベントログ（Microsoft-Windows-NetworkProfile/Operational）を監視
条件：「ネットワーク接続プロファイルが有効になった」イベントに反応
操作：PowerShell スクリプトを管理者権限で実行

これにより、LAN ケーブル接続や Wi-Fi 接続のたびに MTU 固定スクリプトを走らせることができます。

接続先ネットワークごとに MTU を切り替えるスクリプト例

自宅の PPPoE 回線では 1492、会社や外出先では 1500 といった切り替えも PowerShell で実現可能です。

$profile = Get-NetConnectionProfile

if ($profile.Name -like "*自宅SSID*") {
    # 自宅 Wi-Fi では MTU 1492
    Set-NetIPInterface -InterfaceAlias "Wi-Fi" -NlMtuBytes 1492
}
else {
    # それ以外のネットワークでは 1500
    Set-NetIPInterface -InterfaceAlias "Wi-Fi" -NlMtuBytes 1500
}

SSID の代わりに InterfaceAlias や NetworkCategory（Private / Public / DomainAuthenticated）などで条件分岐しても良いでしょう。

方式	メリット	デメリット
固定 1492（全ネットワーク共通）	設定が単純。PPPoE 回線では確実に安定。	1500 が使える高速 LAN でも 1492 となり、ごくわずかに効率が落ちる。
ネットワーク別切り替え	PPPoE と社内 LAN の両方で最適化できる。	スクリプトがやや複雑。プロファイル名が変わるとメンテが必要。

TCP 受信ウィンドウオートチューニングとの違い

検索していると「netsh interface tcp set global autotuning=disabled で改善した」といった情報が目に入ることがありますが、TCP 受信ウィンドウのオートチューニングは MTU 問題とは別物です。

オートチューニング：TCP 受信ウィンドウサイズ（バッファ量）を自動調整する仕組み
MTU：1 パケットあたりの最大サイズ

両者は参照する層が異なり、MTU のフラグメント問題は基本的にオートチューニングの有効/無効とは関係ありません。むしろ、現在の Windows ではオートチューニングを無効化すると高速回線でスループットが落ちるリスクもあるため、むやみに変更しないことを推奨します。

IPv6 環境での MTU 制御について

DHCP オプション 26 は IPv4 のオプションであり、IPv6 の MTU には一切影響しません。IPv6 では主に次の 2 つの要素で MTU が決まります。

ルーター広告（RA）の MTU オプション：ルーター側が「このリンクで使う MTU はこれ」と通知する仕組み。
クライアント側のインターフェイス MTU 設定：Windows なら Set-NetIPInterface -AddressFamily IPv6 などで制御可能。

Windows 11 では IPv6 の MTU も Get-NetIPInterface で確認できます。PPPoE を IPv6 トンネルで利用している場合などは、IPv4 と IPv6 の両方で MTU が適切に設定されているか確認しましょう。

# IPv6 の MTU だけを確認
Get-NetIPInterface -AddressFamily IPv6 |
  Select-Object InterfaceAlias, NlMtuBytes

ルーター側での代替策：TCP MSS クランプ

クライアント側の MTU をすぐに変更できない環境では、ルーター側で TCP MSS クランプを有効化することで症状が大幅に和らぐ場合があります。

MTU 1492 の回線であれば、MSS を 1452（=1492 – 40）にクランプ。
ルーターが通過する TCP SYN パケットの MSS オプションを書き換え、下流の回線 MTU に合わせる。

対策	効果範囲	注意点
クライアント MTU を 1492 に設定	TCP / UDP / ICMP など全てのプロトコルに有効	クライアント側での作業が必要
TCP MSS クランプ	TCP 通信のみ（HTTP, HTTPS, SMTP 等）	UDP ベースのゲームや VPN には効かない

したがって、MSS クランプはあくまで「TCP の実害を軽減する応急処置」であり、根本的にはクライアント MTU を回線に合わせるのが最も堅実だと言えます。

MTU 設定の検証方法（パス MTU の確認）

設定変更の前後で、実際に MTU が効いているかどうかを確認することが大切です。ここでは IPv4 での代表的な方法を紹介します。

ping の「断片化禁止」オプションで確認（IPv4）

IPv4 では、ping コマンドに -f（フラグメント禁止）と -l（ペイロードサイズ指定）を付けることで、実効 MTU の境界を確認できます。

MTU が 1492 の場合、IP ヘッダ 20 バイト + ICMP ヘッダ 8 バイトを差し引いた 1464 バイトが最大ペイロードなので、次のように試験します。

ping -f -l 1464 8.8.8.8

成功（応答が返る） → 少なくとも 1492 の MTU で通っている目安。
「パケットの断片化が必要ですが DF が設定されています」等のメッセージ → MTU より大きいサイズになっている。

1464 で失敗した場合は、数値を小さくしながら境界を探します。

想定 MTU	試すべき ping ペイロードサイズ
1492	1464 (= 1492 – 28)
1480	1452 (= 1480 – 28)
1400	1372 (= 1400 – 28)

設定前後での比較ポイント

MTU 1500 のまま：ping のペイロードを 1472 などにすると、途中の PPPoE 区間でフラグメントが必要になり、ルーターや FW によっては失敗することがある。
MTU 1492 に変更後：ping のペイロードを 1464 にした場合に安定して応答が返るようになる。

ブラウザの体感速度だけで判断するのではなく、このような「再現性のあるテスト」を挟むことで、設定変更の有効性を客観的に評価できます。

設定を元に戻す（標準 MTU 1500 へ）

もし MTU 1492 の設定によって別の問題が出た場合は、元の 1500 に戻すことも簡単です。

PowerShell で元に戻す

Set-NetIPInterface -InterfaceAlias "イーサネット" -NlMtuBytes 1500

一括で戻したい場合は次のようなスクリプトも利用できます。

Get-NetAdapter | Where-Object Status -eq Up |
    Set-NetIPInterface -NlMtuBytes 1500

netsh で元に戻す（IPv4）

netsh interface ipv4 set subinterface "イーサネット" mtu=1500 store=persistent

レジストリの場合

対象インターフェイスのキーから MTU 値を削除する。
または値を 0 にする。
その後 Windows を再起動する。

よくある質問（FAQ）

Q. DHCP オプション 26 を設定しておけば、今後の Windows アップデートで勝手に効くようになりますか？

A. 現時点の仕様では、Windows クライアントはオプション 26 を参照しません。将来のバージョンで変更される可能性はゼロではありませんが、公式にアナウンスされない限り「そのうち効くようになる」ことを前提に設計するのは危険です。現状は PowerShell / netsh / レジストリなどでクライアント側を明示的に設定するのが前提と考えた方が安全です。

Q. MTU を小さくしすぎるとどうなりますか？

A. 極端に小さい MTU はヘッダの割合が増えるため、理論上はスループットの低下につながります。例えば MTU 576 などにすると、1 パケットあたりのデータ効率が悪くなり、CPU やルーターの負荷も増える可能性があります。PPPoE 環境であれば、まずは 1492 から始め、どうしても必要な場合のみ 1480 などに調整するのが現実的です。

Q. VPN（IPsec, SSL-VPN）も利用しています。どの値に合わせるべきですか？

A. VPN ではさらにカプセル化オーバーヘッドが乗るため、実効 MTU は 1400 前後まで下がることが多いです。VPN を常時利用する端末であれば、VPN 経由の MTU を優先して設定するか、ルーター側で VPN トンネル専用の MSS クランプを設定する方法がよく用いられます。いずれにしても、実際の経路ごとに ping テストでパス MTU を計測するのが確実です。

Q. TCP 受信ウィンドウのオートチューニングを無効化したら治ったように見えます。

A. 副次的な影響で症状が変化することはありますが、根本原因である MTU/フラグメント問題が解決したわけではありません。オートチューニングは別のチューニング項目であり、将来的なトラブルの原因にもなり得ます。まずは MTU を適切に設定し、それでも解消しない場合に他のチューニングを検討する流れをおすすめします。

Q. Windows Server でも同じ問題が起こりますか？

A. DHCP オプション 26 の扱いに関しては、クライアント OS と同様に Windows Server でも「MTU を自動的には採用しない」挙動です。サーバー OS では特に、DNS やファイルサーバーなど基幹サービスへの影響が大きくなるため、MTU の設計・検証はより慎重に行う必要があります。

運用上のベストプラクティスまとめ

最後に、Windows 11 環境で「DHCP に頼らず MTU をきちんと制御する」ためのベストプラクティスをまとめます。

PPPoE/ADSL など MTU 1492 が前提の回線では、クライアント MTU を 1492 にそろえる。
単一回線・単一セグメントの小規模環境では、PowerShell で一括 1492 固定がもっとも簡単。
社内 LAN や VPN など異なる MTU を持つ複数ネットワークを利用する場合は、接続プロファイルに応じて MTU を切り替えるスクリプトを用意する。
DHCP オプション 26 は Windows クライアントには効かないため、「設定しているから安心」と考えず、クライアント側の MTU 実測を必ず行う。
ルーター側の TCP MSS クランプは有効だが万能ではない。UDP や ICMP を含めて安定させたいなら、やはりクライアント MTU の調整が重要。
変更前後で ping -f -l を用いたパス MTU テストを実施し、数値として効果を確認する。
複数 PC を管理する場合は、GPO や構成管理ツール（Intune 等）でスクリプトを一括配布する運用にしておく。

Windows 11 は DHCP オプション 26 を採用しない設計である以上、「DHCP から MTU 1492 を配っているのにクライアントが従ってくれない」という状態は自然な挙動です。本記事で紹介したように、PowerShell や netsh を使って OS 側で MTU を明示的に制御することで、PPPoE 環境における断片化や通信エラーの多くは解消できます。ネットワーク構成に応じた最適な MTU 戦略を設計し、安定した通信環境を構築していきましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。