Linuxでtcpdumpを初めて使ってネットワーク問題を解決した話｜パケットを「見る」という発想が変えた障害調査の視野

「ネットワーク障害が起きているのに、ログを見ても何も出ていない。pingは通っているのに、なぜかサービスに繋がらない。どこを調べればいいか全く分からない。」

Linuxを触り始めた頃に、こういう状況で完全に手が止まった経験は誰にでもあると思います。私がSE時代（2001年～2006年）に最初の数年間でぶつかり続けた壁が、まさにこれでした。ログに出ないトラブルへの対処法を、当時の私は一切持っていなかったのです。

この記事では、20年以上Linuxサーバーを運用してきた経験をもとに、tcpdumpの実務的な使い方と「パケットを直接見る」という発想が障害調査をどう変えるかを解説します。

ネットワーク障害で「見えない壁」にぶつかり続けた新人時代の話

SE時代に入社して最初の2年間、私はネットワーク関連の障害が起きるたびに途方に暮れていました。

「/var/log/messagesにはエラーが何も出ていないのに、Webアプリがサーバーに接続できない。」
「pingは通っているのに、ポート80番への接続が断続的に失敗する。」

こういうケースで、私にできることはサービスを再起動するか先輩に助けを求めるかの2択しかありませんでした。「ログに出ない問題」に対する診断の手段を、当時の私はまったく持っていなかったのです。

転機が来たのは入社3年目のことでした。Apacheサーバーへの接続が断続的に失敗するという障害が発生し、私がいくらログを追っても原因が特定できずにいた時、ベテランの先輩エンジニアがこう言いました。

「tcpdumpで見てみろ。ログに出ないものでも、パケットは正直だ。」

その言葉の意味が最初はよく分かりませんでした。しかし先輩がtcpdumpを実行した瞬間、画面にリアルタイムでパケットが流れ始めたのを見て、私は衝撃を受けました。サーバーに届いているパケット、送り返しているパケット、そしてどこで通信が止まっているかが、目に見える形で表示されたのです。

「これまで見えていなかった世界が、突然見えるようになった。」

そういう感覚でした。障害調査の道具として、ログと並ぶもうひとつの武器を手に入れた瞬間でした。

tcpdumpとは何か——ログには残らない通信を「直接見る」ツール

tcpdumpは、ネットワークインターフェース（NIC）を流れるパケットをリアルタイムでキャプチャ（捕捉）して表示するコマンドです。「パケットアナライザ」や「スニファ」とも呼ばれます。1988年に開発されて以来、現在も現場の最前線で使われ続けているツールです。

ログと何が違うのか、という点をまず整理しておきます。

・ログ（/var/log）：アプリケーションやOSが「記録しようとした」情報だけが残る。記録する仕組みが動いていなければ何も残らない
・tcpdump：NICを通過した全パケットを捕捉する。アプリケーションの動作に関係なく、通信の実態を記録できる

つまり、「Apacheのログには何も出ていないのに接続が失敗する」ような状況でも、tcpdumpにはパケットの実態が見えます。クライアントからSYNパケットが届いているか、サーバーがSYN-ACKを返しているか、そもそもパケットが到達しているかを「現物」で確認できるのです。

セミナーで3,100名以上を指導してきた中で気づくのですが、ネットワーク障害の調査が苦手なエンジニアの多くは「ログを読む」ところで止まっています。tcpdumpを知った瞬間、「ログが正常でも接続が失敗する」という状況への対処力が一段上がります。

実務で使うtcpdumpの基本コマンド

tcpdumpの基本を押さえます。実際にコマンドラインで使えるレベルを目標にしてください。

動作確認環境：RHEL 9.4 / Ubuntu 24.04 LTSで実機確認済み。実行にはsudo（またはroot）が必要です。
主要オプションをまとめます。

・-i インターフェース名：キャプチャ対象のNICを指定。-i anyで全NIC対象
・-n：IPアドレスとポート番号を数値で表示。名前解決しないので応答速度が上がり見やすくなる
・-v / -vv / -vvv：表示の詳細度。-vvvが最も詳細なパケット情報を表示
・-c 件数：取得するパケット数の上限を指定。本番サーバーで暴走しないよう必ず付ける
・-w ファイル名：パケットをpcap形式のファイルに保存
・-r ファイル名：保存したpcapファイルを読み込み表示

特に -n オプションは必ず付ける習慣をつけてください。名前解決が入ると出力が遅くなり、リアルタイムの障害調査ではかえって状況が把握しにくくなります。

tcpdumpの出力を読む——フラグとフローの見方

tcpdumpコマンドを実行すると、以下のような出力が流れます。実際にSE時代の検証サーバーで取得したパケットに近い形で示します。
この出力の読み方を説明します。

最初の3行は TCPの3ウェイハンドシェイクです。

・Flags [S]：SYN。クライアントが接続を開始する。この行でクライアントからパケットが届いているか確認できる
・Flags [S.]：SYN-ACK。サーバーが接続要求に応答している。この行が見えなければサーバー側に問題がある
・Flags [.]：ACK。クライアントが応答を確認。ここまで来れば接続が確立している
・Flags [P.]：PUSH + ACK。実際のデータ（HTTPリクエスト）を送信している

もし「SYNは届いているのにSYN-ACKが返ってこない」なら、サーバー側のサービスが起動していないか、ファイアウォールでポートがブロックされているかのどちらかです。この切り分けが、tcpdumpを見ることで数秒で判断できるようになります。

末尾の「0 packets dropped by kernel」も重要な指標です。パケットのドロップが多発している場合は、高負荷などによって取り溢しが起きていることを示します。

tcpdumpが「動かない」「パケットが見えない」時のエラー対処法

tcpdumpを初めて使う時に必ずぶつかるトラブルがいくつかあります。私がSE時代にハマったものばかりなので、順番に確認してください。

トラブル1：「tcpdump: You don't have permission to capture on that device」と出る

最も多い失敗です。tcpdumpはNICに直接アクセスするため、root権限が必要です。一般ユーザーで実行するとこのエラーが出ます。必ずsudoを付けるか、rootに切り替えてから実行してください。
トラブル2：コマンドが動いているのにパケットが全く表示されない（0 packets captured）

コマンドが正常に起動しているにも関わらず何も出力されないケースです。原因は以下のいずれかです。

・ポート番号の指定が違う：実際のサービスが使っているポートを確認してください。ss -tlnpコマンドでListenしているポートが分かります
・インターフェースに通信が来ていない：クライアント側から本当にリクエストを送っているか確認してください
・ファイアウォールでパケットがドロップされている：NICに届く前にfirewalldやiptablesで弾かれている可能性があります。firewall-cmd --list-allでルールを確認してください
・ループバックへの接続を見ていない：localhost（127.0.0.1）への接続は lo インターフェースに流れます。sudo tcpdump -i lo -n port 8080のように lo を指定してください

トラブル3：大量のパケットが流れて追いきれない

本番サーバーで実行すると、秒間数百から数千パケット以上が流れることがあります。この場合は絞り込みフィルタを活用してください。

・sudo tcpdump -i ens3 -n port 80 and host 192.168.1.100（ポートとホストを両方絞る）
・sudo tcpdump -i ens3 -n port 80 -c 30（-cで取得数を制限する）
・sudo tcpdump -i ens3 -n port 80 -w /tmp/cap.pcap（-wでファイルに保存してから分析する）

tcpdumpで実際に問題を解決した3つのシナリオ

実務でtcpdumpが特に役立つシナリオを3つ紹介します。いずれも私が現場で経験したパターンです。

1. Apacheへの接続が断続的に失敗するケース

最初に紹介した、SE時代に経験した障害です。

sudo tcpdump -i ens3 -n port 80でキャプチャしながらブラウザからアクセスすると、失敗したタイミングでSYNパケットは届いているのにSYN-ACKが返っていないことが分かりました。Apacheのプロセスはきちんと起動していて、Apacheのエラーログにも何も出ていなかったのに、です。

調べた結果、接続を待ち受けるキュー（バックログ）がオーバーフローしている問題でした。/proc/sys/net/core/somaxconnの値が低く設定されていたのが原因で、ログには何も残っていませんでした。tcpdumpがなければたどり着けなかった結論です。

2. DNS問い合わせが失敗しているかどうかを確認するケース

「名前解決が遅い、または失敗することがある」という報告があった際、sudo tcpdump -i ens3 -n port 53でUDPパケットを確認すると、DNSクエリが飛んでいるのに応答が返ってきていないことが一目で分かりました。

resolv.confの設定は正しく、サーバーのネットワーク設定にも問題はなかったのですが、DNSサーバー側が応答できない状態になっていました。「名前解決が失敗する」という現象から「DNSサーバーが応答していない」という原因まで、tcpdumpを使って30秒で切り分けができました。

3. FTP接続でPASVモードが動かないケース

FTPクライアントが接続できない問題で、sudo tcpdump -i ens3 -n port 21で確認すると、21番ポートへの接続は正常に確立しているのに、PASVモードで返却されたデータ用ポートへの接続がファイアウォールでブロックされていることが分かりました。

「FTPが動かない」という大雑把な問題が「特定のポート範囲がfirewalldでブロックされている」という具体的な原因に絞り込まれた瞬間でした。この3つのケースに共通しているのは、「ログを見ても原因が分からなかった」という点です。tcpdumpはアプリケーション層より下の層で何が起きているかを確認する手段であり、ログに頼れない時の強力な選択肢として機能します。

まとめ

tcpdumpを使えるかどうかは、ネットワーク障害の調査力に直結します。私自身、SE時代にこのコマンドを知ってからは「ログを見て分からなかったら終わり」という発想がなくなりました。

20年以上Linuxサーバーを運用してきた経験から言うと、ネットワーク障害の多くは「見えていなかったから解決できなかった」ものです。tcpdumpを使えるようになるだけで、障害調査の突破口を自分で見つけられるようになります。特に「ログは正常、でも繋がらない」という状況は、現場でよく遭遇します。そういう時に迷わずtcpdumpを立ち上げられるかどうかが、ベテランと初心者の差につながります。

やりたいこと	コマンド
全パケットをキャプチャ（名前解決なし）	sudo tcpdump -i ens3 -n
特定ポートのみ監視（例:80番）	sudo tcpdump -i ens3 -n port 80
特定ホストとの通信のみ監視	sudo tcpdump -i ens3 -n host 192.168.1.100
ポートとホストを両方絞る	sudo tcpdump -i ens3 -n port 80 and host 192.168.1.100
取得パケット数を制限して自動停止	sudo tcpdump -i ens3 -n port 80 -c 30
pcapファイルに保存	sudo tcpdump -i ens3 -n -w /tmp/capture.pcap
保存ファイルを読み込んで確認	tcpdump -r /tmp/capture.pcap -n
インターフェース名を確認	ip link show

・Linuxのポート確認コマンド（ss / lsof）でポートの使用状況を調べる方法
・LinuxのDNS設定をresolv.confとnmcliで正しく変更する方法

---

• 前のページへ：Linuxエンジニアとして初めての転職面接で玉砕した話｜SE時代に学んだ「書類のスキル」と「現場のスキル」の違い
• この記事の属するカテゴリ：Linux学習ガイドへ戻る