ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例

ネットワークがおかしいときは、まず ipconfig /all で設定を見て、症状に合わせて次の操作を選びます。

flowchart TD
    A[つながらない] --> B[ipconfig /all<br>で設定を見る]
    B -->|169.254| C[release<br>と renew]
    B -->|名前だけ失敗| D[flushdns]
    B -->|一部だけ止まる| E[ping で<br>MTUを測る]

やりたいことごとのコマンドは次のとおりです。

確認環境：Ubuntu 24.04.4・Linux カーネル 6.18・iproute2 6.1.0・iputils 20240117（ping・tracepath）・net-tools（ifconfig）・tcpdump 4.99.4・iptables 1.8.10・nftables 1.0.9・curl 8.5.0・Python 3.11.15。Linux の network namespace（1台の中に独立したネットワークを作る仕組み）で「PC・ルーター2台・サーバー」をつなぎ、真ん中の区間だけ MTU を 1400 にして、ping・tracepath・HTTP の動きを実際に確かめています。Windows の ipconfig・ping・netsh・PowerShell は Microsoft Learn、Mac の ipconfig は Apple のオープンソース（bootp）の ipconfig(8)、DNS キャッシュの消し方は Apple サポート、Linux の resolvectl・networkctl は systemd のマニュアル、MTU の仕様は RFC 791・1191・8200・9293、クラウドの値は AWS の公式ドキュメントで確かめました（確認日 2026年10月18日）。

ipconfigコマンドとは

ipconfig は、Windows の IP 設定（IP アドレス・サブネットマスク・デフォルトゲートウェイ・DNS サーバーなど）を表示し、DHCP のアドレスと DNS キャッシュを操作するコマンドです。 コマンドプロンプトか PowerShell で実行します。

Microsoft Learn には、ipconfig は「IP アドレスを自動で取得する設定のコンピューターでいちばん役に立つ」とあります。DHCP（アドレスを自動で配る仕組み）、APIPA（DHCP が取れないときに自分で 169.254.x.x を付ける仕組み）、代替構成のどれで値が決まったのかを確かめられるためです。

ipconfigのオプション一覧

Microsoft Learn の ipconfig のページにある書式とオプションです。

ipconfig [/allcompartments] [/all] [/renew [<adapter>]] [/release [<adapter>]] [/renew6 [<adapter>]] [/release6 [<adapter>]] [/flushdns] [/displaydns] [/registerdns] [/showclassid <adapter>] [/setclassid <adapter> [<classID>]]

ドキュメントに書かれている注意点です。

• アダプター名に空白があるときは " で囲みます。 例：ipconfig /renew "Wi-Fi 2"。
• アダプター名には * が使えます。 Local* は「Local で始まる名前」、*Con* は「Con を含む名前」のアダプターすべてです。
• /release は、自動取得のアダプターの TCP/IP を止めます。 /renew するまで、そのアダプターは通信できません。
• /renew・/showclassid・/setclassid は、自動取得（DHCP）のアダプターでだけ使えます。 手動で IP を設定したアダプターには効きません。

PowerShell には同じ情報を返すコマンドレットがあります。

ipconfig /allの出力の見方

ipconfig /all は、最初にコンピューター全体の情報、続いてアダプター（有線 LAN・Wi-Fi・VPN など）ごとの情報を出します。日本語版の Windows では、各行は次のような形です（アドレスは例です）。

Windows IP 構成

   ホスト名. . . . . . . . . . . . . . . .: PC01
   プライマリ DNS サフィックス . . . . . . :
   ノード タイプ . . . . . . . . . . . . .: ハイブリッド
   IP ルーティング有効 . . . . . . . . . .: いいえ
   WINS プロキシ有効 . . . . . . . . . . .: いいえ

イーサネット アダプター イーサネット:

   接続固有の DNS サフィックス . . . . . .:
   説明. . . . . . . . . . . . . . . . . .: （ネットワークアダプターの製品名）
   物理アドレス. . . . . . . . . . . . . .: 00-11-22-33-44-55
   DHCP 有効 . . . . . . . . . . . . . . .: はい
   自動構成有効. . . . . . . . . . . . . .: はい
   リンクローカル IPv6 アドレス. . . . . .: fe80::1234:5678:9abc:def0%12(優先)
   IPv4 アドレス . . . . . . . . . . . . .: 192.168.1.10(優先)
   サブネット マスク . . . . . . . . . . .: 255.255.255.0
   リース取得. . . . . . . . . . . . . . .: 2026年10月18日 9:00:00
   リースの有効期限. . . . . . . . . . . .: 2026年10月19日 9:00:00
   デフォルト ゲートウェイ . . . . . . . .: 192.168.1.1
   DHCP サーバー . . . . . . . . . . . . .: 192.168.1.1
   DNS サーバー. . . . . . . . . . . . . .: 192.168.1.1
   NetBIOS over TCP/IP . . . . . . . . . .: 有効

各行の意味と、見るときの要点です。英語版の表示名は Microsoft Learn の出力例の表記です。

Microsoft Learn（Windows 2000 Server の資料）には、IP アドレスが重複しているとサブネットマスクが 0.0.0.0 と表示される、とあります。

結果をファイルに保存する・一部だけ見る

問い合わせや比較のために、出力をファイルに残せます。findstr で欲しい行だけを取り出すこともできます。

ipconfig /all > C:\temp\ipconfig_all.txt
ipconfig | findstr IPv4

ipconfig /release・/renewでIPアドレスを取り直す

DHCP からアドレスを取り直す手順です。コマンドプロンプトで、次の順に実行します。

ipconfig /release
ipconfig /renew

アダプターを1つに絞るときは、ipconfig で表示された名前を付けます。

ipconfig /release "Wi-Fi"
ipconfig /renew "Wi-Fi"

リモートデスクトップで操作している相手のパソコンで /release を実行すると、その時点で接続が切れます。 /renew を自分では送れなくなるため、遠隔で取り直すなら ipconfig /release && ipconfig /renew を1行で続けて実行する形がよく使われます。

Linux・Mac で同じことをするコマンドは、後の「Linux・Macで同じことをするコマンド」の表にあります。

ipconfig /flushdns・/displaydnsでDNSキャッシュを消す

Windows は、一度引いた名前と IP の組を「DNS クライアントのキャッシュ」に覚えています。Microsoft Learn には、/displaydns が表示するキャッシュには hosts ファイルから読み込んだ行と、最近名前解決した結果の両方が入っている、とあります。

ipconfig /displaydns | findstr "example.com"
ipconfig /flushdns

/flushdns を使う場面は次のとおりです。

DNS サーバーが実際に何を返しているかは nslookup で確かめられます。関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

Linux・Macで同じことをするコマンド

Linux には ipconfig は無く、iproute2 の ip コマンドが中心です。Mac にも ipconfig という名前のコマンドがありますが、Windows とは中身が違い、DHCP の情報の表示と設定に使います（Apple の ipconfig(8)）。

補足です。

• resolvectl は systemd-resolved を使っている Linux（Ubuntu の標準など）で使えます。マニュアルには flush-caches は「ローカルに持っているすべての DNS キャッシュを消す」とあります。
• networkctl renew は systemd-networkd が管理するインターフェイスで「DHCP サーバーから受け取ったアドレスなどを更新する」コマンドです。NetworkManager の環境では nmcli connection down 接続名 のあと nmcli connection up 接続名 で取り直します。
• Mac の DNS キャッシュ：Apple サポートの「Reset the DNS cache in OS X」では、OS X v10.10.4 以降は sudo killall -HUP mDNSResponder です。
• Mac の ipconfig getifaddr は「そのインターフェイスに付いた最初のネットワークサービスの IP アドレス」を1行で出します。

Linux の ip addr の出力は次のとおりです（この記事の実験用の PC 役）。2行目の mtu 1500 がこのインターフェイスの MTU です。

$ ip addr show eth0
20: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fa:32:18:24:38:5f brd ff:ff:ff:ff:ff:ff link-netns s275-r1
    inet 192.168.75.10/24 scope global eth0
       valid_lft forever preferred_lft forever

$ ip route
default via 192.168.75.1 dev eth0 
192.168.75.0/24 dev eth0 proto kernel scope link src 192.168.75.10 

net-tools の ifconfig でも同じ値が見えます。

$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.75.10  netmask 255.255.255.0  broadcast 0.0.0.0
        ether fa:32:18:24:38:5f  txqueuelen 1000  (Ethernet)
        RX packets 285  bytes 1909352 (1.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 307  bytes 114923 (114.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ip コマンドのほかの使い方は、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。ip route の読み方とゲートウェイの決まり方は、関連記事「デフォルトゲートウェイとは｜調べ方・設定・決め方をLinuxで実演」で扱っています。

MTUとは（MTU・MSS・フラグメント）

MTU（Maximum Transmission Unit）は、1つのリンク（線や無線の1区間）で、1回に運べる IP パケットの最大のバイト数です。 一般的なイーサネットは 1500 バイトです。これより大きいデータは、複数のパケットに分けて送ります。

MTU と MSS の関係

RFC 9293（TCP）は、MSS オプションで送る値は「実際の MTU から、IP と TCP の固定ヘッダーを引いたもの」としています。IPv4 は IP 20 バイト・TCP 20 バイトなので MSS = MTU − 40、IPv6 は IP ヘッダーが 40 バイトなので MSS = MTU − 60 です。

RFC 9293 は、相手の MSS が分からないときの既定値を IPv4 で 536（576 − 40）、IPv6 で 1220（1280 − 60）としています。

主な MTU の値と出典

フラグメントが起きると何が困るか

経路の途中で MTU が小さくなると、IPv4 では次のどちらかが起きます。

• DF ビットが無いパケット：ルーターが分割して送ります。届きますが、分割と組み立ての手間が増え、1つでも欠けると全体が無駄になります。
• DF ビットが付いたパケット：ルーターは分割せずに捨て、送り主に「分割が必要だが DF が付いている（MTU はいくつ）」という ICMP を返します。

Linux の既定（net.ipv4.ip_no_pmtu_disc = 0）では、TCP は DF ビットを付けて送ります。 送り主は返ってきた ICMP を見て、パケットを小さくし直します。これが次の Path MTU Discovery です。

IPv6 では、ルーターは分割しません。RFC 8200 には「IPv6 の分割は送り主だけが行い、経路の途中のルーターは行わない」とあり、大きすぎるパケットは捨てて ICMPv6 の Packet Too Big を返します。

Path MTU Discovery（経路MTU探索）の仕組み

Path MTU Discovery（PMTUD）は、DF ビットを付けて送り、途中のルーターから返る ICMP を手がかりに、経路の MTU を見つける仕組みです。 IPv4 は RFC 1191、IPv6 は RFC 8201 で決められています。

flowchart TD
    A[送り主が1500で送る<br>DFビット付き] --> B{途中の区間の<br>MTUは1400}
    B -->|大きすぎる| C[ルーターが捨てて<br>ICMPを返す mtu=1400]
    C --> D[送り主が1400に<br>覚え直して再送]
    D --> E[宛先に届く]

RFC 1191 の決まりの要点です。

• 送り主は最初、自分の最初のリンクの MTU を経路の MTU とみなします。
• 途中で捨てたルーターは、ICMP の「Next-Hop MTU」の欄に、次の区間の MTU を入れて返します。
• 送り主は、小さくした値を覚えておき、10分おいてから大きい値をもう一度試すことを勧めています。

Linux は、覚えた経路の MTU を 600 秒保持します。 カーネルの設定 net.ipv4.route.mtu_expires の既定値が 600 で、この記事の実験でも ip route get に cache expires 594sec mtu 1400 と出ました（次の節）。

ICMP が届かないと PMTUD は働かない

PMTUD は「ルーターが ICMP を返し、それが送り主まで届く」ことが前提です。ファイアウォールが ICMP をすべて捨てていると、送り主は大きいパケットが消えている理由を知れず、送り直しても同じ大きさで送り続けます。これを PMTU ブラックホールと呼びます。

AWS のドキュメントは、セキュリティグループで ICMP を許可していても、ネットワーク ACL が ICMP を拒否していると PMTUD の応答が届かないことがある、としています。また AWS Site-to-Site VPN は Path MTU Discovery に対応していないと書かれています。

MTUの確認方法と上限の測り方（Windows・Mac・Linux）

インターフェイスの MTU を見る

ping で経路の MTU の上限を測る

DF ビットを付けて、データの大きさを変えながら ping を送ると、経路の MTU が分かります。 ping のデータの大きさは「MTU − 28」（IP ヘッダー 20 + ICMP ヘッダー 8）です。MTU 1500 なら 1472 が上限です。

Microsoft Learn には、Windows の -f は「DF フラグを 1 にして送る（IPv4 のみ）」もので「パス MTU の問題の調査に役立つ」、-l の既定は 32 バイト、最大は 65,500 とあります。大きすぎるときの Windows の表示は、Cisco Meraki のドキュメントでは「Packet needs to be fragmented but DF set.」です。

Linux の -M には4つの値があります（ping のマニュアル）。

実験の構成：真ん中だけ MTU 1400

Linux の network namespace で、次の4台をつなぎました。PC とサーバーは自分の MTU が 1500 なので、途中に 1400 の区間があることを知りません。

flowchart TD
    PC[PC 192.168.75.10<br>MTU 1500] --> R1[ルーター1<br>192.168.75.1]
    R1 -->|この区間だけ MTU 1400| R2[ルーター2<br>10.75.1.2]
    R2 --> SV[サーバー 10.75.2.10<br>MTU 1500]

真ん中の区間は、ルーター側で ip link set eth1 mtu 1400 のように設定しました。

22: eth1@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default qlen 1000

結果1：1472 は通らず、ルーターが mtu = 1400 を返した

PC からサーバーへ、DF を付けて 1472 バイト（パケット 1500 バイト）の ping を送りました。

$ ping -c 3 -M do -s 1472 10.75.2.10
PING 10.75.2.10 (10.75.2.10) 1472(1500) bytes of data.
From 192.168.75.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400

--- 10.75.2.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2050ms

読み取れることは次の3つです。

• 1回目は、ルーター1（192.168.75.1）が「Frag needed and DF set (mtu = 1400)」を返しました。 1400 の区間の手前にいるルーターです。
• 2回目からは、PC が送る前に local error: message too long, mtu=1400 で止めました。 ICMP を受け取って、経路の MTU を覚えたためです。
• このとき PC の経路表には、覚えた値が期限つきで入っていました。

$ ip route get 10.75.2.10
10.75.2.10 via 192.168.75.1 dev eth0 src 192.168.75.10 uid 0 
    cache expires 594sec mtu 1400 

同じとき、PC で tcpdump を取ると、ルーターから返った ICMP は次のように見えました。

IP 192.168.75.10 > 10.75.2.10: ICMP echo request, id 24868, seq 1, length 1480
IP 192.168.75.1 > 192.168.75.10: ICMP 10.75.2.10 unreachable - need to frag (mtu 1400), length 556

結果2：1372 は通り、1373 は通らない

覚えた値は ip route flush cache で消せました。消した直後の ip route get は cache だけになり、mtu 1400 の表示が無くなりました。

上限を自動で探す Python スクリプト

ping の大きさを二分探索で変えて、通る最大の大きさを探すスクリプトです。Linux の ping（iputils）を使います。

# mtu_probe.py  使い方: python3 mtu_probe.py 宛先 [上限のMTU]
import subprocess, sys

def ok(host, payload):
    r = subprocess.run(["ping", "-c", "1", "-W", "1", "-M", "do", "-s", str(payload), host],
                       capture_output=True, text=True)
    return r.returncode == 0

host = sys.argv[1]
hi = int(sys.argv[2]) if len(sys.argv) > 2 else 1500
lo, hi = 0, hi - 28            # 28 = IPヘッダー20 + ICMPヘッダー8
ok(host, hi)                   # 1回目でPMTUを覚えさせる（Frag needed を受け取る）
while lo < hi:
    mid = (lo + hi + 1) // 2
    good = ok(host, mid)
    print(f"payload {mid:5d} (packet {mid + 28:5d}):", "OK" if good else "NG")
    if good: lo = mid
    else: hi = mid - 1
print(f"通るいちばん大きい ping のデータ長 = {lo}")
print(f"経路の MTU = {lo + 28}")

$ python3 mtu_probe.py 10.75.2.10
payload   736 (packet   764): OK
payload  1104 (packet  1132): OK
payload  1288 (packet  1316): OK
payload  1380 (packet  1408): NG
payload  1334 (packet  1362): OK
payload  1357 (packet  1385): OK
payload  1368 (packet  1396): OK
payload  1374 (packet  1402): NG
payload  1371 (packet  1399): OK
payload  1372 (packet  1400): OK
payload  1373 (packet  1401): NG
通るいちばん大きい ping のデータ長 = 1372
経路の MTU = 1400

最初の1回を除き、11回の ping で 1400 にたどり着きました。

tracepath で、どこで MTU が小さくなるかを見る

tracepath は、経路をたどりながら、MTU が変わった場所に pmtu を表示するコマンドです。 マニュアルには、traceroute と違って管理者権限が要らない、とあります。

$ tracepath -n 10.75.2.10
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.75.1                                          0.035ms 
 1:  192.168.75.1                                          0.004ms 
 2:  192.168.75.1                                          0.005ms pmtu 1400
 2:  10.75.1.2                                             0.010ms 
 3:  10.75.2.10                                            0.011ms reached
     Resume: pmtu 1400 hops 3 back 3 

traceroute との違い（* * * や !H の意味）は、関連記事「traceroute・tracertの使い方｜見方と * ・!Hの意味を実例で」で扱っています。

DF を付けないとき：途中で2つに分割された

-M dont（DF なし）で 1472 バイトを送ると、ping は通りました。ルーター1の 1400 側で tcpdump を取ると、1つのパケットが 1396 バイトと 124 バイトの2つに分割されていました。

IP (tos 0x0, ttl 63, id 22618, offset 0, flags [+], proto ICMP (1), length 1396)
    192.168.75.10 > 10.75.2.10: ICMP echo request, id 2402, seq 1, length 1376
IP (tos 0x0, ttl 63, id 22618, offset 1376, flags [none], proto ICMP (1), length 124)
    192.168.75.10 > 10.75.2.10: ip-proto-1

flags [+] は「後ろに続きの断片がある」、offset 1376 は「元のデータの 1376 バイト目からの断片」という意味です。同じ id 22618 を持つ断片を、宛先で組み立て直します。

tcpdump の読み方は、関連記事「tcpdumpの使い方｜フィルタ式一覧と出力の読み方」で扱っています。

MTUが合わないと起きること（特定のサイトだけ遅い・VPNで切れる）

MTU の不一致でいちばん分かりにくいのは、「つながるのに、大きいデータだけが届かない」状態です。 接続の確立（TCP の3ウェイハンドシェイク）や短い応答は小さいパケットなので通り、画像やファイルなど大きいパケットだけが消えます。

実験：ICMP を捨てると、大きい HTTP 応答だけ止まった

サーバーで Python の http.server を動かし、9 バイトのファイル（small.txt）と 204,800 バイトのファイル（big.bin）を置きました。PC から curl で取得します。

ICMP が届くときは、どちらも普通に取れました。サーバーは帰り道の MTU 1400 を覚えていました。

status=200 size=204800 time=0.006301s

$ ip route get 192.168.75.10   # サーバー側
192.168.75.10 via 10.75.2.1 dev eth0 src 10.75.2.10 uid 0 
    cache expires 599sec mtu 1400 

次に、ルーターが「分割が必要」の ICMP を出さないようにしました。ファイアウォールが ICMP を捨てている状態の再現です。

# サーバー → PC の向きで 1400 の区間の手前にいる、ルーター2で実行
iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP

ICMP が届かないときの結果です。小さいファイルは取れ、大きいファイルは 15 秒待っても1バイトも届きませんでした。

status=200 size=9 time=0.002508s
curl: (28) Operation timed out after 15002 milliseconds with 0 out of 204800 bytes received
status=200 size=0 time=15.002228s

ステータスは 200 なのに、本文が 0 バイトです。 応答のヘッダーは小さいパケット1つに収まって届き、本文の大きいパケットだけが消えたためです。止まっている間にサーバーで ss -tni を見ると、次のようになっていました（要部）。

0      79640     10.75.2.10:27500 192.168.75.10:45490
     ... rto:3264 backoff:4 ... mss:1448 pmtu:1500 ... cwnd:1 ... bytes_retrans:5792 ... lost:12 ...

ルーター2の ICMP を捨てる規則には、10 パケット・5,760 バイトが当たっていました。ルーターは ICMP を返そうとしていたのに、届かなかったことが分かります。

PC から同じ状態で ping と tracepath を使うと、手がかりになるメッセージが出ませんでした。

$ ping -c 3 -W 1 -M do -s 1472 10.75.2.10
PING 10.75.2.10 (10.75.2.10) 1472(1500) bytes of data.

--- 10.75.2.10 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2054ms

$ tracepath -n -m 5 10.75.2.10
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.75.1                                          0.058ms 
 1:  192.168.75.1                                          0.004ms 
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500 

小さい ping（-s 1372 以下）は通り、1472 だと何も返らないのが、PMTU ブラックホールの見分け方です。

MTU が小さくなる主な理由

MTUの不一致の直し方（MSSクランプ・MTUを下げる・tcp_mtu_probing）

ICMP が届かない状態のまま、3つの直し方を試しました。どれも大きいファイルが取れるようになりました。

いちばん根本の直し方は、途中の機器が「分割が必要」の ICMP（IPv4 はタイプ 3 コード 4、IPv6 は Packet Too Big）を捨てないようにすることです。それができないときに、次の方法を使います。

1. MSS クランプ：ルーターで TCP の大きさを書き換える

MSS クランプは、ルーターが通過する TCP の SYN（接続の申し込み）の MSS を、出ていく側の MTU に合わせて書き換える方法です。 両端が最初から小さいパケットで送るので、ICMP に頼りません。VPN 装置やブロードバンドルーターでよく使われます。

iptables のマニュアルにある書き方です。

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

nftables では次のように書けました（nftables 1.0.9 で確認）。

nft add table inet mssclamp
nft add chain inet mssclamp mssfix '{ type filter hook forward priority mangle; }'
nft add rule inet mssclamp mssfix tcp flags syn tcp option maxseg size set rt mtu

サーバーで SYN を tcpdump で見ると、PC が送った MSS 1460 が、ルーター1を通ったあと 1360 に変わっていました。

# クランプなし
IP 192.168.75.10.54480 > 10.75.2.10.27500: Flags [S], seq 1737697312, win 64240, options [mss 1460,sackOK,TS val 2648542649 ecr 0,nop,wscale 10], length 0
# クランプあり
IP 192.168.75.10.54494 > 10.75.2.10.27500: Flags [S], seq 382440195, win 64240, options [mss 1360,sackOK,TS val 1374047515 ecr 0,nop,wscale 10], length 0

1360 は「出ていく側の MTU 1400 − 40」です。iptables のマニュアルにも、TCPMSS は通常「出ていくインターフェイスの MTU から IPv4 は 40、IPv6 は 60 を引いた値」に制限する、とあります。

MSS クランプが効くのは TCP だけです。 UDP（DNS の大きな応答・QUIC・一部の VPN）には効きません。

iptables の規則の確認・保存の仕方は、関連記事「iptablesの使い方｜ルールの確認・追加・保存」で扱っています。

2. 端末の MTU を下げる

経路の MTU が分かっているなら、端末の MTU をそれに合わせます。PC の MTU を 1400 にすると、PC が SYN で送る MSS も 1360 になり、サーバーは最初から小さく送りました。

Microsoft Learn には、netsh の store=active は「次の起動まで」、persistent は「再起動後も残る」とあります。mtu を省くと、そのリンク本来の MTU になります。

Linux で範囲の外の値を指定すると、次のエラーになりました。

$ ip link set eth0 mtu 60
Error: mtu less than device minimum.
$ ip link set eth0 mtu 70000
Error: mtu greater than device maximum.

端末の MTU を下げると、その端末が「受け取る」量は小さくなりますが、ほかの宛先との通信も小さいパケットになります。 VPN のインターフェイスなど、問題の経路を通るインターフェイスだけを下げるのが目安です。

3. tcp_mtu_probing：送る側が自分で小さくして試す

Linux のカーネルの設定 net.ipv4.tcp_mtu_probing は、TCP が自分でパケットの大きさを変えて経路の MTU を探す機能（RFC 4821 の Packetization Layer PMTUD）です。カーネルのドキュメントの値は次のとおりです。

サーバーで sysctl -w net.ipv4.tcp_mtu_probing=1 にすると、ICMP が届かないままでも 204,800 バイトが届きました。ただし、3回とも 6.5 秒前後かかりました。再送が何回か失敗してから「ブラックホールだ」と判断し、小さくし直すためです。止まりはしませんが、遅いままです。

MTU・ipconfig関連のエラー原文と意味

この記事の実験で出たメッセージと、ドキュメントにあるメッセージです。

よくある質問

Q. ipconfig とは何ですか？ A. Windows の IP アドレス・サブネットマスク・デフォルトゲートウェイ・DNS サーバーを表示し、DHCP のアドレスの取り直しや DNS キャッシュの削除を行うコマンドです。「ipconfigコマンドとは」の節に、できることの表があります。

Q. ipconfig /all で何が分かりますか？ A. 通常の表示に加えて、MAC アドレス（物理アドレス）・DHCP の有無・リースの期限・DHCP サーバー・DNS サーバーが分かります。「ipconfig /allの出力の見方」に各行の意味の表があります。

Q. ipconfig /flushdns はいつ使いますか？ A. サイトの移転後も前のサーバーに行く、一度失敗した名前が引けないまま、といったときに、Windows が覚えている名前解決の結果を消します。PowerShell の Clear-DnsClientCache も同じです。

Q. ipconfig /release と /renew の違いは？ A. /release は DHCP のアドレスを返して設定を捨て、/renew は新しく取り直します。/release の後は /renew するまで通信できません。

Q. Linux や Mac で ipconfig にあたるコマンドは？ A. Linux は ip addr・ip route・resolvectl、Mac は ifconfig と Mac 版の ipconfig（ipconfig getifaddr en0 など）です。「Linux・Macで同じことをするコマンド」に対応表があります。

Q. MTU とは何ですか？ A. 1つのリンクで1回に運べる IP パケットの最大のバイト数です。一般的なイーサネットは 1500、PPPoE は 1492 です。TCP の1回のデータの上限（MSS）は、IPv4 では MTU − 40 になります。

Q. MTU の設定はどうやって確かめますか？ A. Windows は netsh interface ipv4 show subinterfaces、Linux は ip link、Mac は ifconfig en0 です。経路全体の MTU は、DF を付けた ping で大きさを変えて測ります（ping -f -l 1472 宛先 など）。

Q. MTU は大きいほど速いですか？ A. 1回で運べる量が増えるので効率は上がりますが、経路の途中に小さい区間があると、そこで捨てられるか分割されます。経路全体で同じ値に揃えられる範囲（同じ LAN・同じ VPC の中など）で大きくするのが目安です。

まとめ

• ipconfig は Windows の IP 設定を見るコマンド。/all で MAC・DHCP・DNS まで、/release・/renew で取り直し、/flushdns で DNS キャッシュを消す。
• Linux は ip addr・ip route・resolvectl、Mac は ifconfig と Mac 版 ipconfig が対応する。
• MTU は1回に運べるパケットの最大サイズ。MSS は IPv4 で MTU − 40。
• 経路の MTU は、DF を付けた ping（データ長 = MTU − 28）と tracepath で測れる。実験では 1372 が上限で MTU 1400 だった。
• ICMP が捨てられると PMTUD が働かず、ステータス 200 のまま本文が届かない。
• 直し方は、ICMP を通すのが根本。できなければ MSS クランプか MTU を下げる。tcp_mtu_probing=1 は届くが遅い（約 6.5 秒）。

参考・出典

確認日はいずれも 2026年10月18日です。

• Microsoft Learn「ipconfig」：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig
• Microsoft Learn「Check Configuration with IPConfig」（Windows 2000 Server）：https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940116(v=technet.10)
• Microsoft Learn「ping」：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping
• Microsoft Learn「netsh interface」：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-interface
• Microsoft Learn「Get-NetIPConfiguration」：https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipconfiguration
• Microsoft Learn「Clear-DnsClientCache」：https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache
• Apple「ipconfig(8)」（apple-oss-distributions/bootp）：https://raw.githubusercontent.com/apple-oss-distributions/bootp/main/ipconfig.tproj/ipconfig.8
• Apple サポート「Reset the DNS cache in OS X」：https://support.apple.com/en-tm/101481
• systemd「resolvectl」：https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html
• systemd「networkctl」：https://www.freedesktop.org/software/systemd/man/latest/networkctl.html
• Linux man-pages「ping(8)」：https://man7.org/linux/man-pages/man8/ping.8.html
• Linux man-pages「tracepath(8)」：https://man7.org/linux/man-pages/man8/tracepath.8.html
• Linux man-pages「iptables-extensions(8)」（TCPMSS）：https://man7.org/linux/man-pages/man8/iptables-extensions.8.html
• Linux man-pages「wg-quick(8)」：https://man7.org/linux/man-pages/man8/wg-quick.8.html
• Linux カーネル「IP Sysctl」：https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
• RFC 1191 Path MTU Discovery：https://www.rfc-editor.org/rfc/rfc1191
• RFC 8200 Internet Protocol, Version 6 (IPv6) Specification：https://www.rfc-editor.org/rfc/rfc8200
• RFC 9293 Transmission Control Protocol (TCP)：https://www.rfc-editor.org/rfc/rfc9293
• NTT東日本 ビジネス BizDrive「MTU」：https://business.ntt-east.co.jp/content/bizdrive/word/mtu.html
• Cisco Meraki「MTU の問題に関するトラブルシューティング」：https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Translated_Documents/Troubleshooting_and_Support/Troubleshooting%2F%2FTroubleshooting_MTU_Issues_jp
• AWS「Network maximum transmission unit (MTU) for your EC2 instance」：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html
• AWS「Best practices for an AWS Site-to-Site VPN customer gateway device」：https://docs.aws.amazon.com/vpn/latest/s2svpn/cgw-best-practice.html
• AWS「AWS Site-to-Site VPN quotas」：https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。