ネットワーク診断コマンドの使い方
ネットワークの不具合を調べるために端末から実行するコマンドと、その使い方をまとめたテーマ。IP設定・疎通・DNS・経路・TCPポート・Webの応答を順に確認し、障害の範囲を絞ることを目的とする。
イマシルちゃんの解説
「ネットがつながらない!」と思ったとき、いきなり設定を変えてしまうと原因がわからなくなることがあるんだ。
まず自分のIPアドレスとデフォルトゲートウェイを確認して、pingで相手まで届くかを調べよう。
次にnslookupでDNSが名前をIPアドレスに変換できるかを確かめて、traceroute(Windowsではtracert)で途中のルータをたどるの。
Webサイトだけが開けないときは、TCPポートへの接続やHTTPの応答も別に調べられるよ。
コマンドには送信回数や待ち時間を指定するオプションがあるので、目的に合わせて使い分けると原因を少しずつ絞り込めるんだ!
この解説はわかりやすかったですか?
より深い解説
目的からコマンドを選ぶ
| 調べたいこと | 主なコマンド |
|---|---|
| 自分のIPアドレスやDNS設定 | Windows:ipconfig、Linux:ip、macOS:ifconfig |
| 宛先へIPで届くか、往復時間はどの程度か | ping |
| DNSがどのアドレスやレコードを返すか | nslookup、dig |
| 宛先までどのルータを経由するか | Windows:tracert、Linux・macOS:traceroute |
| 宛先への出口や次の転送先 | Windows:route print、Linux:ip route、macOS:route |
| 同じリンクの機器のIPとMACアドレスの対応 | arp -a、Linux:ip neigh |
| 相手のTCPポートへ接続できるか | Windows PowerShell:Test-NetConnection、Linux・macOS:nc |
| 自分の端末が使っているTCP/UDPポート | Windows:netstat、Linux:ss、macOS:lsof |
| Webサーバから返るHTTPの応答 | curl |
| 経路上の応答を繰り返し測る | Windows:pathping |
WindowsのコマンドプロンプトとPowerShellでは実行できる機能が一部異なる。Linux・macOSでも同じ名前のコマンドに異なるオプションがあるため、OS別の例を確認すること。以下のexample.comや1.1.1.1は説明用の宛先である。実際の調査では接続を許可された対象に置き換える。
ping:疎通・往復時間・パケットロス
pingはICMPのエコー要求を送って、応答の有無とRTT(往復時間)を調べるコマンドである。通常のTCPポートが開いているかを調べるものではない。
Windowsの実行例:
ping example.com
ping -n 10 -w 1000 1.1.1.1
ping -4 -n 4 example.com
ping -f -l 1472 1.1.1.1
ping -t 1.1.1.1
| Windowsの指定 | 意味 |
|---|---|
-n 10 | エコー要求を10回送る。指定しなければ通常4回 |
-w 1000 | 1回の応答を最大1,000ms待つ |
-l 1472 | ICMPエコー要求のデータ部分を1,472バイトにする |
-f | IPv4のDF(フラグメント禁止)を設定する |
-4/-6 | 宛先が名前の場合もIPv4/IPv6を明示する |
-t | Ctrl+Cで止めるまで繰り返す |
Linuxの実行例:
ping -c 4 example.com
ping -4 -c 10 -W 1 1.1.1.1
ping -4 -M do -s 1472 1.1.1.1
macOSの実行例:
ping -c 4 example.com
ping -c 10 -s 1400 1.1.1.1
| Linux・macOSの指定 | 意味 |
|---|---|
-c 4 | 4回送って終了する。指定しなければ通常は繰り返し送信する |
-s 1400 | ICMPエコー要求のデータ部分を1,400バイトにする |
-i 2 | 送信間隔を2秒にする |
Linuxの-W 1 | 応答待ちの時間を秒単位で指定する。macOSの-Wとは同じ扱いにしない |
Linuxの-M do | IPv4のパスMTU探索でフラグメント化を許さずに試す |
1,472バイトは、IPv4ヘッダー20バイト+ICMPヘッダー8バイトを加えると合計1,500バイトになる値である(IPオプションなしの場合)。DFを指定した試験はパスMTUの調査に使えるが、応答がなければMTUが原因だと断定できるわけではない。
結果のtime=...msやtime ... msはRTTを示す。タイムアウトは「応答が得られなかった」という意味であり、ファイアウォールによるICMPの遮断や応答制限でも起こる。pingが成功しても、Webサービスの動作が正常だとまでは判断できない。
nslookup・dig:名前解決を調べる
nslookupは指定した名前についてDNSサーバーへ問い合わせるコマンドである。サーバーとレコード種別を明示すると、DNS設定の違いを比較しやすい。
Windows・Linux・macOSで利用できる代表的な例:
nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com 1.1.1.1
| 指定 | 調べられること |
|---|---|
-type=A | IPv4アドレスを示すAレコード |
-type=AAAA | IPv6アドレスを示すAAAAレコード |
-type=MX | メールの配送先に関係するMXレコード |
-type=NS | ドメインの権威DNSサーバーを示すNSレコード |
最後の1.1.1.1 | 問い合わせ先のDNSサーバーを指定する |
対話モードでは次のように設定できる。最初のnslookupを実行したあと、残りの行を順番に入力する。
nslookup
server 1.1.1.1
set type=TXT
set timeout=2
example.com
exit
set timeout=2は応答待ちの初期タイムアウトを2秒にする設定である。Non-authoritative answerという表示は、キャッシュDNSサーバーなどから得た応答であることを示し、それだけで失敗を意味しない。
digはDNSの応答コード、権威情報、問い合わせ時間などを詳しく見たいときに使う。macOSや多くのLinux環境で利用できるが、Linuxでは別途導入が必要な場合があり、Windowsにも標準では用意されていない。
dig example.com A
dig example.com MX
dig @1.1.1.1 example.com AAAA
dig @1.1.1.1 example.com AAAA +short
@1.1.1.1は問い合わせるDNSサーバーを指定する。+shortは答えを簡潔に表示するが、失敗原因の調査では省略し、status: NXDOMAIN(名前が存在しない)やstatus: SERVFAIL(サーバー側で処理に失敗)も確認する。NOERRORでも要求した種類のレコードが存在しない場合がある。
外部のDNSサーバーは社内専用の名前を解決できない場合がある。またnslookupやdigの結果が正常でも、ブラウザやOSが同じ名前解決の経路を使っているとは限らない。
tracert・traceroute:通信の経路を調べる
tracertとtracerouteは、TTL(IPv6ではホップリミット)を小さい値から増やし、途中のルータが返すICMPの時間超過メッセージを手がかりに経路を表示する。
Windowsの実行例:
tracert example.com
tracert /d /h 20 /w 1000 example.com
tracert /6 example.com
Linux・macOSの実行例:
traceroute example.com
traceroute -n -m 20 example.com
Linuxでは試験に使うパケットの種類も変更できる。
traceroute -I -n example.com
traceroute -T -p 443 -n example.com
| 指定 | 意味 |
|---|---|
Windowsの/d、Linux・macOSの-n | 中継ルータのIPアドレスを名前に逆引きせず表示する |
Windowsの/h 20、Linux・macOSの-m 20 | 最大ホップ数を20にする |
Windowsの/w 1000 | 応答を最大1,000ms待つ |
Linuxの-I | 通常のUDPではなくICMPエコー要求を送る |
Linuxの-T -p 443 | TCPの宛先ポート443を使って経路を調べる |
Windowsのtracertは通常ICMPエコー要求を使う。一方、Linux・macOSの一般的なtracerouteは通常UDPを使うため、ファイアウォールによって結果が異なることがある。
表示される*は、その試行で応答が得られなかったことを意味する。途中に*があっても、その先のホップや宛先に到達していれば、そこが通信断の場所だとは判断できない。中継ルータがICMPの応答を制限している場合もある。表示される各ホップのRTTはそのホップからの応答までの時間であり、隣り合う2台の間の遅延をそのまま表す値ではない。
ipconfig・ip・ifconfig:端末のIP設定
調査の最初に、自分のIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバーを確認する。
Windows:
ipconfig
ipconfig /all
ipconfig /displaydns
/allは各アダプターの詳細を表示する。/displaydnsはWindowsのDNSクライアントキャッシュを表示する。
Linux:
ip -br address
ip route
-brはIPアドレスの表示を短くする指定である。ip routeはIPv4の経路表を表示する。DNSサーバーの確認には環境に応じてresolvectl statusなどを使用する。
macOS:
ifconfig
route -n get default
scutil --dns
ifconfigでアドレスとインタフェース状態を、route -n get defaultでデフォルト経路を、scutil --dnsでDNSリゾルバー設定を調べられる。
Windowsのipconfig /flushdnsはDNSキャッシュを消去する操作である。また/releaseや/renewはDHCPのリースを解放・更新し、一時的に通信が切れる可能性がある。調査のための表示コマンドと、状態を変更するコマンドは区別する。
route・ip route:宛先への出口を調べる
自分の端末がどのインタフェースから、どのゲートウェイへ通信を送るかは、ルーティングテーブルによって決まる。
route print
上はWindowsで経路表を表示する例である。
ip route get 1.1.1.1
上はLinuxで、指定した宛先についてカーネルが選ぶ経路と送信元アドレスを表示する。確認のために実際のIPパケットを宛先へ送信する必要はない。
route -n get 1.1.1.1
上はmacOSで指定した宛先の経路を調べる例である。
経路表では宛先プレフィックス、ネクストホップ(次に渡すルータ)、出力インタフェースなどを見る。複数の経路に一致するときはプレフィックス長が最も長い経路が優先される。VPNが有効な端末では通常時と経路が変わる場合もある。
arp・ip neigh:隣接機器のアドレスを調べる
同じリンク上のIPv4アドレスとMACアドレスの対応は、ARPテーブルで確認できる。
Windows・macOS:
arp -a
Linux:
ip neigh show
Linuxのip neighではIPv4のARPとIPv6の近隣探索に関するエントリを扱える。INCOMPLETEやFAILEDが続く場合は隣接先のアドレス解決を疑う。STALEは再確認が必要な状態であり、それだけで故障を意味しない。
Test-NetConnection・nc:TCPポートの接続確認
pingが通っても、WebのTCP/443やSSHのTCP/22が利用可能とは限らない。特定のTCPポートまで接続できるかは別に確認する。
Windows PowerShell:
Test-NetConnection example.com -Port 443
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
TcpTestSucceeded : Trueは、指定したTCPポートへの接続試行に成功したことを示す。-InformationLevel Detailedでは名前解決の結果や使用したインタフェースなどを追加で確認できる。
Linux・macOS(ncが導入されている場合):
nc -vz example.com 443
-zは通常のデータ送受信を行わず接続を確かめる指定、-vは詳細表示である。接続成功はアプリケーションの認証やHTTPの正常性を保証しない。対象の管理者が許可したポートを調べる。
netstat・ss・lsof:自分の端末の待受ポート
「相手につながらない」のではなく「自分のサーバーが待ち受けていない」場合は、端末内のソケットを調べる。
Windows:
netstat -ano
-aは待受中のポートなども含めて表示、-nはアドレス・ポートを数値で表示、-oはPID(プロセスID)を表示する指定である。
Linux:
ss -lntp
-lは待受中、-nは数値表示、-tはTCP、-pはプロセス情報である。UDPも含める場合はss -tulnpを使用する。
macOS:
lsof -nP -iTCP -sTCP:LISTEN
TCPの待受ソケットと、それを使うプロセスを表示する例である。自分以外のプロセス情報の取得には管理者権限が必要になる場合がある。
curl:HTTPの応答を確認する
Webの不具合では、IP到達性とポート接続だけでなく、HTTPステータスやリダイレクト、TLS接続を確認する。
Linux・macOSでの例:
curl -I https://example.com
curl -L -I https://example.com
curl -v --connect-timeout 5 --max-time 15 https://example.com
| 指定 | 意味 |
|---|---|
-I | HEADリクエストでHTTPのレスポンスヘッダーを確認する |
-L | リダイレクト先までたどる |
-v | 接続やTLS、送受信するHTTPヘッダーなどを詳しく表示する |
--connect-timeout 5 | DNS解決や接続確立を含む接続段階の制限時間を5秒にする |
--max-time 15 | コマンド全体の制限時間を15秒にする |
WindowsのPowerShellでは環境によってcurlが別のコマンドの別名になることがある。curl本体を指定したいときはcurl.exe -I https://example.comと入力する。
-IはGETではなくHEADを送るため、HEADを許可していないWebサービスではエラーになる場合がある。HTTP 200が表示されたとしてもページの中身や操作が正常であるとは限らない。-vの結果に認証情報やCookieが含まれることがあるため、ログを共有する前に確認する。
pathping:経路を調べながら応答を集計する
Windowsのpathpingは、経路上のルータを調べたあとで複数回のICMPエコー要求を送り、応答率などを集計する。
pathping /n /q 20 example.com
/nは名前への逆引きを省略し、/q 20は各ホップへの問い合わせ回数を20回にする。集計にはある程度の時間がかかる。
途中のルータがICMPへの応答を制限していると、そのルータの応答率だけが低く見えることがある。中継する通常の通信に同じ割合の損失が起きているとは限らない。
つながらないときの確認順序
実務では、1回のコマンドの成功・失敗で結論を出さず、別の方法で仮説を確かめる。
| 順番 | 確認すること |
|---|---|
| 1 | ipconfig /allやip -br addressでアドレスを確認し、デフォルトゲートウェイが想定どおりか調べる |
| 2 | 自分のデフォルトゲートウェイへpingし、LAN側の到達性を確認する |
| 3 | 許可された外部IPアドレスへpingし、名前解決を介さない通信を試す |
| 4 | nslookupやdigでDNSの応答を調べる。必要なら普段使うDNSサーバーと別のサーバーを比較する |
| 5 | tracert/tracerouteと経路表を確認し、経路や出口の想定違いを調べる |
| 6 | 対象サービスのポートをTest-NetConnection/ncで確認し、WebならcurlでHTTPの応答まで調べる |
例えば「IPアドレス宛ての通信はできるが名前を使うと失敗する」場合、DNSなどの名前解決を重点的に調べる。一方で「pingは成功するがTCP/443への接続だけ失敗する」なら、ファイアウォールの許可ルールや相手の待受状態を調べる。
結果を読み間違えないために
| 表示や状況 | 注意点 |
|---|---|
| pingがタイムアウトする | 宛先が停止しているとは限らない。ICMPが遮断・制限されている可能性がある |
tracerouteの途中が*になる | その先へ転送できない証拠にはならない。途中の機器が返答しない場合もある |
| DNS問い合わせが成功する | TCPポートやWebサービスまで利用可能であることは意味しない |
| TCPの接続試行が成功する | TLS・認証・HTTPの処理まで成功したわけではない |
| 端末の設定変更後に一時的に直る | 根本原因が解消したとは限らない。変更前後の設定と時刻を記録する |
午後での問われ方
| 問われ方 | 判断のポイント |
|---|---|
| pingは通るがアプリケーションに接続できない | ICMPとTCP/UDPの違い、ポート単位の通信制御、サービスの待受状態を区別する |
| 名前で指定したときだけ接続できない | DNSの問い合わせ先・応答内容と、端末が実際に使う名前解決の設定を確認する |
| 経路が想定と違う | 経路表、プレフィックス長、ゲートウェイ、VPNや複数インタフェースの影響を確認する |
| 一部のホップの応答だけ遅い | 中継機器によるICMP応答の優先度や制限を考慮し、実際の転送遅延と区別する |