ネットワーク障害が発生したとき、原因を素早く特定し解決するためには、適切なトラブルシューティングコマンドを使いこなす必要があります。「インターネットに接続できない」「Webサイトが表示されない」といった問題に直面したとき、闇雲に設定を変更するのではなく、コマンドを使って問題の所在を切り分けることが重要です。

本記事では、ネットワークトラブルシューティングに役立つコマンドについて以下の内容を解説します。

  • 接続性確認のためのping、traceroute/tracertコマンド
  • DNS名前解決を調査するnslookup、digコマンド
  • ネットワーク接続状態を確認するnetstat、ssコマンド
  • HTTP通信をテストするcurl、wgetコマンド
  • パケットキャプチャを行うtcpdumpコマンド
  • トラブルシューティングの体系的な手順

この記事を読むことで、ネットワーク障害の原因を特定するためのコマンド操作ができるようになります。

前提条件

本記事を理解するために、以下の知識があることを前提としています。

実行環境

本記事で使用するコマンドは以下の環境で動作確認を行っています。

項目 環境
Linux Ubuntu 22.04/24.04、Rocky Linux 9
macOS macOS 14（Sonoma）以降
Windows Windows 10/11（PowerShell/コマンドプロンプト）
必要なツール ping、traceroute/tracert、nslookup、dig、netstat、ss、curl、tcpdump
権限 一部のコマンド（tcpdumpなど）で管理者権限が必要

Linux/macOSでは標準でほとんどのコマンドが利用可能です。Windowsでも主要なコマンドは標準搭載されていますが、digやtcpdump相当の機能を使う場合は追加ツールが必要な場合があります。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

  1. ネットワーク障害の原因を体系的に切り分けできる
  2. pingとtracerouteで接続性とルーティングを診断できる
  3. nslookup/digでDNS名前解決の問題を調査できる
  4. netstat/ssで接続状態とポートの使用状況を確認できる
  5. curlでHTTP通信のトラブルを診断できる
  6. tcpdumpでパケットレベルの問題を調査できる

トラブルシューティングの基本アプローチ

ネットワークトラブルシューティングでは、OSI参照モデルの下位層から上位層へ順に確認していく方法が効果的です。物理層・データリンク層に問題があれば、上位層の確認は意味がありません。

以下の図は、トラブルシューティングの体系的なアプローチを示しています。

flowchart TD
    Start[障害発生] --> L1[物理層・データリンク層の確認<br/>ケーブル接続、リンク状態]
    L1 --> L1Check{問題あり?}
    L1Check -->|Yes| L1Fix[物理的な接続を修正]
    L1Check -->|No| L2[ネットワーク層の確認<br/>IPアドレス、ルーティング]
    
    L2 --> L2Check{問題あり?}
    L2Check -->|Yes| L2Fix[IP設定、ルーティングを修正]
    L2Check -->|No| L3[トランスポート層の確認<br/>ポート、ファイアウォール]
    
    L3 --> L3Check{問題あり?}
    L3Check -->|Yes| L3Fix[ファイアウォール、ポート設定を修正]
    L3Check -->|No| L4[アプリケーション層の確認<br/>DNS、HTTP、サービス設定]
    
    L4 --> L4Check{問題あり?}
    L4Check -->|Yes| L4Fix[アプリケーション設定を修正]
    L4Check -->|No| End[原因特定・解決]

各層で使用する主要なコマンドは以下のとおりです。

確認項目 主要コマンド 確認内容
物理層・データリンク層 ip link、ifconfig インターフェース状態、リンク状態
ネットワーク層 ping、traceroute、ip route 接続性、ルーティング経路
トランスポート層 netstat、ss、telnet ポート状態、接続状況
アプリケーション層 nslookup、dig、curl DNS解決、HTTP通信
全体調査 tcpdump、wireshark パケットキャプチャ

pingコマンドによる接続性確認

pingは、ネットワークトラブルシューティングで最初に使用する最も基本的なコマンドです。ICMPエコー要求パケットを送信し、対象ホストからの応答を確認することで、ネットワーク層での接続性を確認できます。

基本的な使い方

1
2
3
4
5
6
7
8

# 基本的なping（LinuxとmacOSでは継続的に送信）
ping example.com

# 回数を指定してping（Linux/macOS）
ping -c 4 example.com

# 回数を指定してping（Windows）
ping -n 4 example.com

実行結果の見方

以下は、正常な場合のping結果の例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=11.9 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.800/12.025/12.300/0.183 ms

各項目の意味は以下のとおりです。

項目 説明
64 bytes 受信したパケットサイズ
icmp_seq シーケンス番号（パケットの順序）
ttl Time To Live（残りホップ数）
time 往復時間（RTT: Round Trip Time）
packet loss パケット損失率
rtt min/avg/max RTTの最小/平均/最大値

トラブルシューティングのポイント

pingの結果から、以下のような問題を診断できます。

応答がない場合（Request timeout）

1
2
3
4
5

$ ping -c 4 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.

--- 192.168.1.100 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3003ms

応答がない原因として、以下が考えられます。

  • 対象ホストが起動していない
  • ネットワーク経路に問題がある
  • ファイアウォールでICMPがブロックされている
  • 対象ホストのIPアドレスが間違っている

パケット損失がある場合

1
2

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 7 received, 30% packet loss, time 9012ms

部分的なパケット損失は、以下の問題を示唆します。

  • ネットワークの混雑
  • ケーブルの接触不良
  • 無線LANの電波干渉
  • ルーターやスイッチの過負荷

RTTが異常に長い場合

通常、同一LAN内では1ms未満、インターネット経由でも100ms程度が目安です。これを大幅に超える場合は、ネットワークの混雑や遠回りなルーティングが疑われます。

段階的な接続確認

ネットワーク障害を切り分けるため、以下の順序でpingを実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 自分自身（ループバック）への確認
ping 127.0.0.1

# 2. デフォルトゲートウェイへの確認
ping 192.168.1.1

# 3. 外部のDNSサーバーへの確認（IPアドレス指定）
ping 8.8.8.8

# 4. 外部ホストへの確認（ドメイン名指定）
ping google.com

この順序で確認することで、問題の所在を絞り込めます。

確認対象 結果 推測される問題
127.0.0.1 NG TCP/IPスタックの問題
ゲートウェイ NG LAN内の接続、IP設定の問題
8.8.8.8 NG ルーティング、インターネット接続の問題
google.com NG DNS名前解決の問題

traceroute/tracertによる経路確認

traceroute（Windowsではtracert）は、パケットが宛先に到達するまでの経路（ホップ）を表示するコマンドです。ネットワーク層の問題がどこで発生しているかを特定するのに役立ちます。

基本的な使い方

1
2
3
4
5

# Linux/macOS
traceroute example.com

# Windows
tracert example.com

実行結果の見方

以下は、tracerouteの実行結果の例です。

1
2
3
4
5
6
7
8

$ traceroute google.com
traceroute to google.com (142.250.196.110), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.234 ms  1.123 ms  1.089 ms
 2  10.0.0.1 (10.0.0.1)  5.678 ms  5.543 ms  5.432 ms
 3  203.0.113.1 (203.0.113.1)  10.123 ms  10.234 ms  10.345 ms
 4  * * *
 5  209.85.243.180 (209.85.243.180)  12.456 ms  12.567 ms  12.678 ms
 6  142.250.196.110 (142.250.196.110)  11.789 ms  11.890 ms  11.901 ms

各列の意味は以下のとおりです。

列 説明
1番目 ホップ番号
2番目 ルーターのホスト名またはIPアドレス
3-5番目 3回の測定によるRTT

トラブルシューティングのポイント

アスタリスク（* * *）が表示される場合

1
2
3

 4  * * *
 5  * * *
 6  * * *

アスタリスクは応答がないことを示します。これは以下の理由で発生します。

  • ルーターがICMPに応答しないよう設定されている（セキュリティ目的で一般的）
  • パケットがドロップされている
  • ファイアウォールでブロックされている

途中でアスタリスクが続き、最終的に宛先に到達する場合は、セキュリティ設定による応答拒否であることが多く、問題ではありません。

特定のホップで遅延が増加する場合

1
2
3

 3  10.0.0.1 (10.0.0.1)  10.123 ms  10.234 ms  10.345 ms
 4  203.0.113.1 (203.0.113.1)  150.456 ms  155.567 ms  160.678 ms
 5  209.85.243.180 (209.85.243.180)  155.789 ms  160.890 ms  165.901 ms

4番目のホップで急激に遅延が増加しています。ただし、これが問題かどうかは以下のポイントで判断します。

  • 以降のホップでも遅延が継続する場合: そのルーターでボトルネックが発生している
  • そのホップだけ遅延が大きい場合: ルーターがICMP応答を低優先で処理しているだけで、実際の通信には影響がない可能性がある

TCPを使用したtraceroute

一部のルーターはICMPをブロックしていますが、TCPの特定ポート宛のパケットは通過させる場合があります。

1
2
3
4

# TCP SYNを使用したtraceroute（Linux、要root権限）
sudo traceroute -T -p 80 example.com

# Windowsでは標準のtracertのみ利用可能

nslookup/digによるDNS診断

DNSの名前解決に問題がある場合、nslookupまたはdigコマンドを使用して原因を調査します。digはより詳細な情報を取得でき、DNS管理者やエンジニアに広く利用されています。

nslookupの基本的な使い方

nslookupはWindows、Linux、macOSすべてで利用可能です。

1
2
3
4
5
6
7
8

# 基本的な名前解決
nslookup example.com

# 特定のDNSサーバーを指定
nslookup example.com 8.8.8.8

# レコードタイプを指定
nslookup -type=MX example.com

nslookupの実行結果の見方

1
2
3
4
5
6
7
8
9

$ nslookup google.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.196.110
Name:   google.com
Address: 2404:6800:4004:820::200e
項目 説明
Server クエリを送信したDNSサーバー
Non-authoritative answer キャッシュからの応答（権威サーバーからの直接応答ではない）
Address 解決されたIPアドレス（IPv4とIPv6）

digコマンドの基本的な使い方

digはnslookupより詳細な情報を取得でき、DNS関連のトラブルシューティングに適しています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 基本的な名前解決
dig example.com

# 特定のレコードタイプを指定
dig example.com MX
dig example.com TXT
dig example.com AAAA

# 特定のDNSサーバーを指定
dig @8.8.8.8 example.com

# 短縮表示
dig +short example.com

# 詳細なトレース
dig +trace example.com

digの実行結果の見方

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

$ dig google.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       142.250.196.110

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Jan 07 10:00:00 JST 2026
;; MSG SIZE  rcvd: 55

重要な項目は以下のとおりです。

セクション 説明
status クエリの結果（NOERROR=成功、NXDOMAIN=存在しない、SERVFAIL=サーバーエラー）
QUESTION SECTION 送信したクエリ
ANSWER SECTION 応答結果（レコード名、TTL、レコードタイプ、値）
Query time クエリにかかった時間
SERVER 応答したDNSサーバー

トラブルシューティングのポイント

NXDOMAINが返される場合

1
2
3

$ dig nonexistent-domain-12345.com

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54321

NXDOMAINはドメインが存在しないことを示します。ドメイン名のスペルミスや、ドメインの有効期限切れが考えられます。

SERVFAILが返される場合

1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 67890

SERVFAILはDNSサーバーがクエリを処理できなかったことを示します。DNSサーバーの設定問題やネットワーク障害が原因です。別のDNSサーバーを指定して確認します。

1
2
3
4
5

# Google Public DNSで確認
dig @8.8.8.8 example.com

# Cloudflare DNSで確認
dig @1.1.1.1 example.com

DNSキャッシュのクリア

DNSキャッシュが原因で古い情報が返される場合は、キャッシュをクリアします。

1
2
3
4
5
6
7
8

# Linux（systemd-resolved）
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows（コマンドプロンプト/PowerShell）
ipconfig /flushdns

netstat/ssによる接続状態確認

netstatおよびss（Socket Statistics）コマンドは、現在のネットワーク接続状態、待ち受けポート、ルーティングテーブルなどを確認するのに使用します。ssはnetstatの後継であり、大規模なシステムでより高速に動作します。

基本的な使い方

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# すべての接続を表示（Linux）
netstat -a
ss -a

# TCPの待ち受けポートを表示（Linux）
netstat -tlnp
ss -tlnp

# UDPの待ち受けポートを表示（Linux）
netstat -ulnp
ss -ulnp

# すべての接続を表示（Windows）
netstat -an

# プロセス情報付きで表示（Windows、管理者権限が必要）
netstat -anb

オプションの意味

オプション 説明
-t TCPのみ表示
-u UDPのみ表示
-l 待ち受け（LISTEN）状態のみ表示
-n ポート番号を数値で表示（名前解決しない）
-p プロセスIDとプロセス名を表示（要root権限）
-a すべての接続を表示

実行結果の見方

1
2
3
4
5

$ ss -tlnp
State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
LISTEN   0        511      0.0.0.0:80            0.0.0.0:*           users:(("nginx",pid=1234,fd=6))
LISTEN   0        128      0.0.0.0:22            0.0.0.0:*           users:(("sshd",pid=567,fd=3))
LISTEN   0        511      127.0.0.1:3306        0.0.0.0:*           users:(("mysqld",pid=890,fd=21))
列 説明
State 接続状態（LISTEN、ESTABLISHED、TIME_WAITなど）
Local Address:Port ローカルのIPアドレスとポート番号
Peer Address:Port 接続先のIPアドレスとポート番号
Process プロセス情報

Local Addressの意味は以下のとおりです。

  • 0.0.0.0:80: すべてのインターフェースでポート80を待ち受け
  • 127.0.0.1:3306: ローカルホストのみでポート3306を待ち受け
  • 192.168.1.10:443: 特定のIPアドレスでのみ待ち受け

トラブルシューティングのポイント

特定のポートが使用されているか確認

1
2
3
4
5

# ポート80を使用しているプロセスを確認（Linux）
ss -tlnp | grep :80

# ポート80を使用しているプロセスを確認（Windows）
netstat -ano | findstr :80

接続状態の確認

1
2
3
4
5

$ ss -tn
State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port
ESTAB    0        0        192.168.1.10:22      192.168.1.100:52341
ESTAB    0        36       192.168.1.10:22      192.168.1.101:60123
TIME-WAIT 0       0        192.168.1.10:80      203.0.113.50:45678
状態 説明
LISTEN 接続待ち受け中
ESTABLISHED 接続確立済み
TIME_WAIT 接続終了処理中（正常）
CLOSE_WAIT 相手から切断要求を受け取り、自分の終了処理待ち
SYN_SENT 接続要求送信済み、応答待ち

TIME_WAITが大量にある場合

TIME_WAITが大量に蓄積している場合、短時間に多数の接続が行われていることを示します。Webサーバーなどで大量のリクエストを処理している場合は正常ですが、ポート枯渇の原因になることがあります。

curlによるHTTP通信テスト

curlは、HTTPやHTTPS通信のテストに最適なコマンドラインツールです。Webサーバーへの接続性確認、レスポンスヘッダの確認、APIのテストなどに幅広く使用されます。

基本的な使い方

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# GETリクエストを送信
curl https://example.com

# ヘッダ情報のみ取得
curl -I https://example.com

# ヘッダ情報とボディを取得
curl -i https://example.com

# 詳細な通信情報を表示
curl -v https://example.com

# リダイレクトを追従
curl -L https://example.com

# タイムアウトを設定
curl --connect-timeout 5 https://example.com

実行結果の見方（詳細モード）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

$ curl -v https://example.com
*   Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> GET / HTTP/2
> Host: example.com
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/2 200
< content-type: text/html; charset=UTF-8
< date: Tue, 07 Jan 2026 01:00:00 GMT
< content-length: 1256
<

出力の記号の意味は以下のとおりです。

記号 説明
* 接続情報、TLSハンドシェイクなど
> 送信したリクエストヘッダ
< 受信したレスポンスヘッダ

トラブルシューティングのポイント

接続タイムアウト

1
2
3
4
5

$ curl -v --connect-timeout 5 https://example.com
*   Trying 93.184.216.34:443...
* Connection timed out after 5001 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5001 milliseconds

接続タイムアウトは、対象サーバーに到達できないか、ファイアウォールでブロックされていることを示します。

SSL/TLS証明書エラー

1
2

$ curl https://expired-cert.example.com
curl: (60) SSL certificate problem: certificate has expired

証明書エラーの場合、証明書の有効期限切れ、ホスト名の不一致、信頼されていない認証局などが原因です。開発環境でテストする場合は-kオプションで証明書検証をスキップできます（本番環境では使用しないでください）。

1
2

# 証明書検証をスキップ（開発環境のみ）
curl -k https://self-signed.example.com

HTTPステータスコードの確認

1
2
3
4
5

# ステータスコードのみ取得
curl -s -o /dev/null -w "%{http_code}" https://example.com

# 出力例
200
ステータスコード 意味
200 成功
301/302 リダイレクト
403 アクセス禁止
404 リソースが見つからない
500 サーバー内部エラー
502 Bad Gateway
503 サービス利用不可

tcpdumpによるパケットキャプチャ

tcpdumpは、ネットワークインターフェースを流れるパケットをキャプチャして表示するコマンドです。他のコマンドでは原因を特定できない場合に、パケットレベルで通信内容を確認できます。

基本的な使い方

tcpdumpはroot権限が必要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# すべてのパケットをキャプチャ
sudo tcpdump

# 特定のインターフェースを指定
sudo tcpdump -i eth0

# 特定のホストとの通信をキャプチャ
sudo tcpdump host 192.168.1.100

# 特定のポートの通信をキャプチャ
sudo tcpdump port 80

# TCPのみキャプチャ
sudo tcpdump tcp

# パケットの内容を16進数とASCIIで表示
sudo tcpdump -XX

# ファイルに保存
sudo tcpdump -w capture.pcap

# ファイルから読み込み
sudo tcpdump -r capture.pcap

フィルタの組み合わせ

tcpdumpは複数の条件を組み合わせて使用できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 特定のホストとポートの組み合わせ
sudo tcpdump host 192.168.1.100 and port 443

# 送信元または宛先を指定
sudo tcpdump src host 192.168.1.10
sudo tcpdump dst host 192.168.1.100

# 複数のポートを指定
sudo tcpdump port 80 or port 443

# ポート範囲を指定
sudo tcpdump portrange 8000-9000

実行結果の見方

1
2
3
4
5
6

$ sudo tcpdump -i eth0 port 80 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:00:00.123456 IP 192.168.1.10.52341 > 93.184.216.34.80: Flags [S], seq 1234567890, win 65535, options [mss 1460,sackOK,TS val 123456 ecr 0,nop,wscale 7], length 0
10:00:00.156789 IP 93.184.216.34.80 > 192.168.1.10.52341: Flags [S.], seq 987654321, ack 1234567891, win 65535, options [mss 1460,sackOK,TS val 654321 ecr 123456,nop,wscale 7], length 0
10:00:00.156890 IP 192.168.1.10.52341 > 93.184.216.34.80: Flags [.], ack 1, win 512, options [nop,nop,TS val 123457 ecr 654321], length 0

TCPフラグの意味は以下のとおりです。

フラグ 意味
[S] SYN（接続要求）
[S.] SYN-ACK（接続要求応答）
[.] ACK（確認応答）
[P.] PSH-ACK（データ送信）
[F.] FIN-ACK（接続終了）
[R] RST（接続リセット）

トラブルシューティングのポイント

3ウェイハンドシェイクの確認

正常なTCP接続では、以下の3つのパケットが交換されます。

1. クライアント → サーバー: [S] (SYN)
2. サーバー → クライアント: [S.] (SYN-ACK)
3. クライアント → サーバー: [.] (ACK)

SYNパケットは送信されているがSYN-ACKが返ってこない場合は、サーバーが応答していないか、ファイアウォールでブロックされている可能性があります。

RSTパケットが返される場合

1
2

10:00:00.123456 IP 192.168.1.10.52341 > 192.168.1.100.8080: Flags [S], seq 1234567890, win 65535, length 0
10:00:00.123567 IP 192.168.1.100.8080 > 192.168.1.10.52341: Flags [R.], seq 0, ack 1234567891, win 0, length 0

RSTパケットは、対象ポートでサービスが待ち受けていないか、ファイアウォールによって明示的に拒否されていることを示します。

Windowsでの代替手段

Windowsにはtcpdumpがありませんが、以下の方法でパケットキャプチャが可能です。

1
2
3
4
5
6
7
8

# pktmonを使用したパケットキャプチャ（Windows 10 version 2004以降）
pktmon start --capture

# キャプチャを停止
pktmon stop

# 結果をテキスト形式に変換
pktmon format PktMon.etl -o capture.txt

また、WiresharkをインストールすればGUIでパケットキャプチャと解析が可能です。

その他の便利なコマンド

ip/ifconfigによるネットワーク設定確認

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# IPアドレスとインターフェース情報を表示（Linux、推奨）
ip addr show

# 特定のインターフェースの情報
ip addr show eth0

# ルーティングテーブルを表示
ip route show

# macOS/古いLinuxでの代替
ifconfig

arp/ip neighによるARPテーブル確認

1
2
3
4
5
6
7
8

# ARPテーブルを表示（Linux）
ip neigh show

# ARPテーブルを表示（Linux/macOS/Windows）
arp -a

# ARPキャッシュをクリア（Linux）
sudo ip neigh flush all

ARPテーブルを確認することで、同一LAN内のホストとのレイヤー2レベルでの通信問題を診断できます。

telnet/ncによるポート接続テスト

特定のポートに接続できるかテストするには、telnetまたはnc（netcat）を使用します。

1
2
3
4
5
6
7
8

# telnetでポート接続テスト
telnet example.com 80

# ncでポート接続テスト（Linux/macOS）
nc -zv example.com 80

# 接続成功時の出力例
Connection to example.com 80 port [tcp/http] succeeded!

Windowsでは、PowerShellのTest-NetConnectionを使用できます。

1
2

# PowerShellでポート接続テスト
Test-NetConnection -ComputerName example.com -Port 80

mtrによる統合的な経路診断

mtrはpingとtracerouteを組み合わせたツールで、継続的に経路を監視してパケット損失や遅延を可視化します。

1
2
3
4
5

# mtrの実行
mtr example.com

# レポートモード（10回測定して終了）
mtr -r -c 10 example.com

トラブルシューティングのフローチャート

ここまで紹介したコマンドを使用した、体系的なトラブルシューティングの手順をまとめます。

flowchart TD
    Start[通信障害発生] --> Q1{ping 127.0.0.1<br/>は成功?}
    Q1 -->|No| A1[TCP/IPスタックの問題<br/>ネットワーク設定を確認]
    Q1 -->|Yes| Q2{ping ゲートウェイ<br/>は成功?}
    
    Q2 -->|No| A2[LAN内の問題<br/>ケーブル、IP設定を確認]
    Q2 -->|Yes| Q3{ping 8.8.8.8<br/>は成功?}
    
    Q3 -->|No| A3[WAN接続の問題<br/>tracerouteで経路を確認]
    Q3 -->|Yes| Q4{nslookup/dig<br/>は成功?}
    
    Q4 -->|No| A4[DNS問題<br/>DNSサーバー設定を確認]
    Q4 -->|Yes| Q5{curl/telnet<br/>で接続成功?}
    
    Q5 -->|No| A5[アプリケーション層の問題<br/>ポート、ファイアウォールを確認<br/>ssで待ち受け状態を確認]
    Q5 -->|Yes| Q6{サービスは<br/>正常に応答?}
    
    Q6 -->|No| A6[サービス設定の問題<br/>アプリケーションログを確認]
    Q6 -->|Yes| End[問題解決]

各ステップで問題が発見された場合、該当するコマンドでさらに詳細を調査します。

問題箇所 追加調査コマンド
TCP/IPスタック ip addr、ifconfig
LAN内接続 arp -a、ip neigh
WAN接続 traceroute、mtr
DNS dig +trace、nslookup
ポート/ファイアウォール ss -tlnp、iptables -L
パケットレベル tcpdump

まとめ

ネットワークトラブルシューティングでは、問題を体系的に切り分けることが重要です。OSI参照モデルの下位層から順に確認することで、効率的に原因を特定できます。

本記事で紹介したコマンドと用途を改めて整理します。

コマンド 主な用途 確認できる内容
ping 接続性確認 ネットワーク層の疎通、RTT、パケット損失
traceroute/tracert 経路確認 パケットの経由ルーター、遅延箇所
nslookup/dig DNS診断 名前解決、DNSレコード
netstat/ss 接続状態確認 待ち受けポート、確立中の接続
curl HTTP通信テスト HTTPレスポンス、TLS接続
tcpdump パケットキャプチャ パケットレベルの詳細な通信内容

これらのコマンドを使いこなすことで、「なぜ通信できないのか」を論理的に解明し、適切な対処ができるようになります。

参考リンク