Windows Server ネットワーク トラブルシューティング：ping・tracert・WinMTR・iperf3 で遅延とロスを調査
Windows サーバー上の Web サイトが一部の地域からだけ遅い、リモートデスクトップが頻繁に切断される、ゲームやアプリケーションで遅延が大きいといった場合、原因はサーバー自体ではなく、ネットワーク経路のどこかにあることがほとんどです。Windows には優れた診断ツールが標準で用意されており、足りない部分はいくつかの無料ツールで補えます。この記事では、ping、tracert、pathping、Test-NetConnection、WinMTR、iperf3 の使い方、結果を誤解せずに読み取る方法、そしてサポートへ問い合わせる際に伝えるべき情報を解説します。
ステップ1：ping で疎通と遅延を確認
# 50 pings to the server; watch the average time and the "Lost" count
ping -n 50 203.0.113.10
# Continuous ping (Ctrl+C to stop) while you reproduce the problem
ping -t 203.0.113.10
# IPv6 or a hostname
ping -6 -n 20 example.com応答時間が安定していてパケットロスが 0% なら、その時点の経路は正常です。数 % のロスがある場合や、応答時間が数百ミリ秒単位で跳ね上がる場合は、混雑が考えられます。なお、ping をブロックしているサーバーやファイアウォールもあるため、応答がなくても必ずしもサーバーがダウンしているとは限りません。ステップ3のポートテストもあわせて行ってください。
ステップ2：tracert と pathping で経路を確認
# Hop-by-hop route without DNS lookups (faster)
tracert -d 203.0.113.10
# tracert + loss statistics for every hop (100 probes per hop, takes a few minutes)
pathping -n -q 100 203.0.113.10結果は注意して読んでください。多くのルーターは、自分宛ての応答の優先度を意図的に下げています。途中のホップでロスや大きな遅延が見られても、それが後続のホップや最終的な宛先まで続いていなければ問題ではありません。あるホップから始まって最後まで続いているロスだけが、問題の発生箇所を示しています。
ステップ3：Test-NetConnection で特定のポートをテスト
ping ではサーバーに到達できることを、ポートテストではサービスに到達できることを確認できます。ネットワークの問題なのか、ファイアウォールやアプリケーションの問題なのかを切り分ける最も手早い方法です。
# Is Remote Desktop / a website / SSH reachable?
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
# Built-in traceroute
Test-NetConnection 203.0.113.10 -TraceRoute
# On the server: is the service actually listening?
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 80,443,3389 | Select-Object LocalAddress, LocalPort, OwningProcessTcpTestSucceeded : True と表示されれば、ポートはエンドツーエンドで開いています。ping は通るのにポートテストが失敗する場合は、Windows ファイアウォール（Windows ファイアウォールでポートを開放する方法を参照）と、サービスが起動しているかを確認してください。
ステップ4：WinMTR で経路を継続的に監視
MTR は ping と traceroute を組み合わせて各ホップを継続的に計測するツールで、断続的に発生する問題を捉えるのに最適です。Windows では WinMTR（無料・オープンソース）を使います。サーバーの IP を入力して Start をクリックし、少なくとも 2～3 分（できれば問題が起きている最中に）実行してから、Copy text to clipboard で結果を保存します。読み方は pathping と同じで、問題になるのは最後のホップまで続くロスだけです。Linux マシンを使える場合はLinux での mtr・traceroute・iperf3 の使い方も参照してください。
ステップ5：iperf3 で帯域幅を測定
遅延のテストではスループットはわかりません。iperf3 は 2 台のマシン間の実際の速度を測定します。Windows 版の iperf3 をダウンロードして展開し、サーバー側ではファイアウォールで一時的にポートを開放します。
# On the server: allow the test port, then start the iperf3 server
New-NetFirewallRule -DisplayName "iperf3 test" -Direction Inbound -Protocol TCP -LocalPort 5201 -Action Allow
.\iperf3.exe -s
# On the client: upload test, then download test (-R), 4 parallel streams, 20 seconds
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20 -R
# Afterwards, remove the temporary rule
Remove-NetFirewallRule -DisplayName "iperf3 test"長距離の通信では遅延の影響で、単一ストリームの速度がポート速度より遅くなることがよくあります。帯域幅が制限されていると判断する前に、-P 4 や -P 8 での結果と比較してください。
ステップ6：DNS、ルーティング、MTU を確認
# DNS: compare your resolver with a public one, and clear the local cache
Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
ipconfig /flushdns
# IP configuration and routing table on the server
ipconfig /all
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 10
# MTU: the largest packet that passes without fragmentation (1472 + 28 = 1500)
ping -f -l 1472 203.0.113.10
ping -f -l 1400 203.0.113.101472 で「Packet needs to be fragmented but DF set」（パケットの断片化が必要ですが、DF が設定されています）と表示されて失敗し、それより小さいサイズでは成功する場合は、経路上のどこかでより小さい MTU が使われています。その結果、小さなリクエストは成功するのに、ページの表示やダウンロードが途中で止まることがあります。
ステップ7：サポートに送る情報
経路の問題を迅速に解決するため、チケットには次の情報を含めてください。
- サーバーの IP、お客様のグローバル IP（「IP アドレス確認」サイトなどで確認できます）、お客様の所在地（都市）とご利用の ISP。
- お客様側からサーバーへの WinMTR または pathping の結果。可能であればサーバーからお客様の IP への結果も。
- 問題が発生した時刻（タイムゾーンも明記）と、常に発生するのか特定の時間帯だけなのか。
- 速度の問題の場合は、双方向の iperf3 の結果。
IMIDC テクニカルサポートへのチケットの送信方法もあわせてご覧ください。
よくある質問
tracert で一部のホップに「Request timed out」（要求がタイムアウトしました）と表示される
それらのルーターが traceroute のプローブに応答しないだけです。後続のホップと宛先が正常に応答していれば、経路に問題はありません。
深夜は速いのに、夕方から夜にかけて遅くなる
ピーク時間帯に国際回線やお客様の ISP で発生する典型的な混雑です。両方の時間帯にテストを行い、その結果をチケットに添えてください。ピーク時間帯の品質がより良い経路（例えば中国向けのプレミアム回線）が解決策になる場合があります。
ping は通るのにリモートデスクトップに接続できない
ネットワーク経路は正常で、ポートがブロックされているか、サービスが応答していません。リモートデスクトップのトラブルシューティングの手順に従って確認してください。
上記の手順で解決しない場合は、サポートチケットを送信して IMIDC の 24 時間 365 日対応テクニカルサポートへご連絡ください。サーバー IP、お客様のグローバル IP と所在地、WinMTR・pathping・iperf3 の結果を添えていただくと、より迅速に調査できます。