ネットワーク障害の調査方法：OSI層別の切り分け手順とLinuxコマンド実践ガイド

障害調査はパニックではなく「手順」で勝つ

「本番環境でネットワーク障害が起きた」という連絡が入ったとき、冷静に動けるかどうかはエンジニアとしての実力差が出る瞬間です。経験の少ないエンジニアは手当たり次第にコマンドを叩いてしまいがちですが、ベテランは必ず「どの層で何が起きているか」を順を追って確認します。

ネットワーク障害の調査に必要なのは、高価なツールではなく体系的な思考の枠組みと、基本コマンドの確実な使いこなしです。OSI参照モデルを思考の地図として使いながら、物理層から順番に上に向かって絞り込む——この手順を身体に染み込ませることが、障害解決の最短ルートになります。

この記事では、Linuxサーバーを前提に、実際の障害調査で使うコマンドを層ごとに整理し、典型的なシナリオへの適用方法まで解説します。

ステップ1：まず「症状」を正確に言語化する

コマンドを叩く前に、障害の症状を正確に把握することが重要です。「つながらない」という報告を鵜呑みにして作業を始めると、実は一部のユーザーだけの問題だったり、特定のポートだけの問題だったりして、調査の方向を誤ります。

確認すべき質問は次の通りです。

• いつから発生しているか（時刻を特定するとログ検索が効率化する）
• 誰が/どの端末から発生しているか（全員か、特定ユーザーだけか）
• どのサービスにアクセスできないか（全サービスか、特定のIPやポートか）
• どのような症状か（タイムアウト、接続拒否、名前解決失敗、遅延など）
• 最近変更はあったか（デプロイ、設定変更、機器の交換など）

「タイムアウト」と「Connection Refused」はまったく異なる原因を示します。タイムアウトはパケットが届いていないかフィルタされている可能性が高く、Connection Refusedはサービスが起動していないか待ち受けていないことを示します。この区別ができるだけで、調査の初動が大きく変わります。

ステップ2：物理層・データリンク層の確認（第1〜2層）

最初に確認するのは、物理的な接続とリンク状態です。クラウド環境や仮想化環境では物理ケーブルの確認はできませんが、インターフェースの状態確認は同様に行います。

# インターフェースの状態確認
ip link show
# または
ip a

# 期待する出力例（正常時）
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
#   UP と LOWER_UP が両方あれば物理・論理ともに正常

UPはOSがインターフェースを有効化していること、LOWER_UPは物理的にリンクが確立していることを示します。どちらか一方でも欠けていれば、ここが問題の起点です。

次にARPテーブルを確認して、同一セグメントのゲートウェイに対してMACアドレスが解決できているかを確認します。

# ARPテーブルの確認
ip neigh show
# または
arp -n

# ゲートウェイのMACアドレスが表示されれば第2層は正常
# "FAILED" や "(incomplete)" が出ていれば第2層に問題あり

ステップ3：ネットワーク層の確認（第3層）

物理・リンク層に問題がなければ、IPレベルの到達性を確認します。

# デフォルトゲートウェイへのping
ip route show default           # ゲートウェイIPの確認
ping -c 4 192.168.1.1           # ゲートウェイへの到達性

# 外部への到達性（IPアドレス直打ちでDNSを排除）
ping -c 4 8.8.8.8

# ルーティングテーブルの確認
ip route show

ゲートウェイへのpingは通るが外部への通信ができない場合、ルーターより先の問題（ISP、上流ルーター、NATの設定など）に絞り込めます。pingが通らない場合はルーティングテーブルや静的ルートの設定ミスを疑います。

経路追跡で問題箇所を特定するにはtraceroute（Linuxではtraceroute、Windowsではtracert）が有効です。

# traceroute（UDPベース）
traceroute 8.8.8.8

# TCPで特定ポートへのtraceroute（ファイアウォール環境で有効）
traceroute -T -p 443 example.com

# より詳細なMTR（リアルタイム更新）
mtr --report 8.8.8.8

tracerouteの出力でアスタリスク（* * *）が続く箇所がパケットが届いていないホップです。ただしICMPを返さないルーターも多いため、アスタリスクが必ずしも問題箇所とは限りません。その先のホップで応答が戻っていれば、アスタリスクの箇所はICMPを返さないだけの正常なルーターです。

ステップ4：トランスポート層の確認（第4層）

IPレベルの到達性があるにもかかわらずサービスにアクセスできない場合、TCPポートレベルの問題を確認します。

# 特定ポートへのTCP接続確認
# (telnetがない環境ではncを使う)
nc -zv 192.168.1.100 80         # ポート80への接続テスト
nc -zv example.com 443          # ポート443への接続テスト

# サーバー側：待ち受けているポートの確認
ss -tlnp                        # TCP待ち受けポートの一覧
# または
netstat -tlnp

# ファイアウォールルールの確認（Linux）
iptables -L -n -v

ss -tlnpの出力で、期待するポートがLISTEN状態になければ、サービスが起動していないか、バインドアドレスが誤っています。0.0.0.0:80はすべてのIPで待ち受け、127.0.0.1:80はローカルホストのみで待ち受けていることを意味します。外部からアクセスできない原因として後者のパターンは非常によくあるミスです。

ステップ5：アプリケーション層の確認（第7層）

TCPレベルの接続は成功しているのにサービスが正常に返らない場合、アプリケーション層の問題です。

# HTTPレスポンスの詳細確認
curl -v https://example.com

# DNSの名前解決確認
dig example.com
dig @8.8.8.8 example.com        # 特定のDNSサーバーに問い合わせ
nslookup example.com

# SSL/TLS証明書の確認
openssl s_client -connect example.com:443 -servername example.com

curl -vの出力は非常に情報量が多く、DNS解決時間、TCPハンドシェイク、TLSネゴシエーション、HTTPリクエスト/レスポンスヘッダーがすべて確認できます。「どこで止まっているか」がすぐに分かるため、障害調査の必須コマンドです。

digの出力ではANSWER SECTIONに期待するIPアドレスが返っているか、status: NOERRORになっているかを確認します。NXDOMAINであればドメインが存在しない、SERVFAILであればDNSサーバー側の問題です。

パケットキャプチャによる深掘り調査

上記のコマンドで絞り込んでも原因が特定できない場合、パケットキャプチャで実際の通信内容を見ます。

# 特定のホストとの通信をキャプチャ
tcpdump -i eth0 host 192.168.1.100 -w capture.pcap

# 特定ポートの通信をキャプチャ
tcpdump -i eth0 port 443 -nn

# HTTPSの通信でTCPリセット（RST）を探す
tcpdump -i eth0 'tcp[13] & 4 != 0'

キャプチャしたpcapファイルはWiresharkで開くと視覚的に分析できます。TCP Retransmission（再送）が多発していれば輻輳や帯域不足、TCP RST（接続リセット）が頻発していればファイアウォールか不正なルーティングが疑われます。

典型的な障害パターンと原因の対応表

まとめ

ネットワーク障害の調査は、感覚に頼るのではなく「物理層から順番に上へ」という手順で、基本コマンドを組み合わせて確認していくことが鉄則です。ping・traceroute・ss・curl -v・dig——これらは5分あれば習得できますが、使いこなすには実際の障害で繰り返し経験するしかありません。

障害が起きていない平時のうちに、正常な状態のコマンド出力を記録しておくことも重要です。異常な状態と比較する基準値（ベースライン）があるだけで、障害時の判断速度は格段に上がります。今日から、サーバーの正常時のss -tlnpやip routeの出力をWikiやRunbookに残しておく習慣を始めてみてください。