2026年7月23日

wget の通信をパケットキャプチャで調べるコマンド集：tcpdump との組み合わせ方

ネットワーク・接続

wget 自体にはパケットキャプチャの機能はありません。通信の中身を調べたいときは、wget で再現用のリクエストを出しながら、同じマシン（または相手のサーバー）で tcpdump を動かして記録し、wget のデバッグ出力と突き合わせるのが実用的なやり方です。この記事では、その組み合わせ方を、DNS・TCP 接続・TLS ハンドシェイク・HTTP の段階ごとにコマンドで整理します。

パケットキャプチャには、通信の中身（Cookie や認証ヘッダーを含むことがあります）が記録されます。自分が管理するシステムと、許可を得た範囲の通信だけを対象にし、取得したファイルは調査後に削除してください。

まず wget 側でできる確認

キャプチャを始める前に、wget の出力だけで分かることを確認しておくと、見るべきパケットが絞れます。

# 応答ヘッダーを表示し、本文は捨てる
wget -S -O /dev/null https://example.com/

# ダウンロードせず、存在確認だけする
wget --spider -S https://example.com/

# 詳細なデバッグ出力（ビルドによっては無効）
wget -d -O /dev/null https://example.com/

-S（--server-response）は応答ヘッダーを表示します。-d（--debug）は、名前解決の結果、接続先の IP アドレス、送ったリクエストヘッダーなどを表示します。ディストリビューションによってはデバッグ機能なしでビルドされていることがあり、その場合は -d が使えません。

再現用のリクエストは、条件を固定しておくとキャプチャが読みやすくなります。

wget --tries=1 --timeout=10 -4 -O /dev/null https://example.com/

--tries=1 でリトライを止め（既定では失敗時に再試行するため、キャプチャに同じ通信が何度も並びます）、--timeout で待ち時間の上限を決め、-4（--inet4-only）で IPv4 に固定しています。IPv6 の経路を調べたいときは -6 に替えます。

tcpdump でキャプチャする基本形

ターミナルを二つ開き、一方で tcpdump、もう一方で wget を実行します。

# 端末1：対象ホストとの通信をファイルに保存
sudo tcpdump -i any -nn -w wget.pcap host example.com

# 端末2：再現用のリクエストを出す
wget --tries=1 --timeout=10 -4 -O /dev/null https://example.com/

wget が終わったら端末1を Ctrl+C で止めます。主なオプションの意味は次のとおりです。

-i any … すべてのインターフェースで取得（Linux）。特定のインターフェースに絞るなら -i eth0 など
-nn … ホスト名やポート名に変換せず数値で表示（表示時の名前解決による余計な通信を防ぎます）
-w … 画面ではなくファイルに保存。後で Wireshark でも開けます
host example.com … フィルタ式。tcpdump 起動時に一度だけ名前解決されるため、CDN のように IP が変わる相手では取りこぼすことがあります

IP が変わる相手で取りこぼしを避けたい場合は、ホストではなくポートで絞るか、wget -d で表示された接続先 IP を指定します。

sudo tcpdump -i any -nn -w wget.pcap 'port 443 or port 53'

保存したファイルは -r で読み出せます。

tcpdump -nn -r wget.pcap

段階ごとに見る：DNS

名前解決で止まっている疑いがあるときは、DNS の通信だけを見ます。

sudo tcpdump -i any -nn 'port 53'

wget を実行して、問い合わせ（A や AAAA）に応答が返っているか、返ってきた IP が想定どおりかを確認します。応答がない場合は、DNS サーバーへの経路やファイアウォールを疑います。なお、systemd-resolved を使う環境では、wget の問い合わせはまずローカルのスタブリゾルバー（127.0.0.53）へ送られるため、外部 DNS への問い合わせが見えないことがあります。-i any で取得し、ループバックの通信も含めて確認してください。

段階ごとに見る：TCP 接続

「接続できない」「タイムアウトする」ときは、TCP の 3 ウェイハンドシェイクを確認します。

# SYN と RST のパケットだけを表示
sudo tcpdump -i any -nn 'host 203.0.113.10 and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)'

読み方の目安は次のとおりです。

SYN を送っても何も返ってこない … 途中のファイアウォールで破棄されている、または経路の問題
SYN に RST が返る … 相手のホストには届いているが、そのポートで待ち受けていない
SYN、SYN-ACK、ACK がそろっている … TCP 接続は成功。問題は TLS か HTTP の段階

SYN の再送が何度も並ぶのは、応答が返ってきていないサインです。

段階ごとに見る：TLS ハンドシェイク

HTTPS の通信は暗号化されているため、tcpdump では HTTP の中身は読めません。それでも、ハンドシェイクの途中で切れているかどうかは分かります。キャプチャしたファイルを Wireshark で開き、表示フィルタを使うと読みやすくなります。

tls.handshake.type == 1
tls.handshake.extensions_server_name == "example.com"
tls.alert_message

一つ目は Client Hello、二つ目は SNI（接続先のホスト名）での絞り込み、三つ目は TLS のアラートです。Client Hello の直後に接続が切られる、またはアラートが返る場合は、TLS のバージョンや暗号スイートの不一致、SNI の誤りなどを疑います。wget 側のエラーメッセージ（証明書の検証失敗など）とあわせて判断します。

証明書の検証エラーで止まっている場合、--no-check-certificate で通るかを試すと切り分けにはなりますが、本番の処理にこのオプションを残さないでください。証明書の中身を調べるなら openssl s_client のほうが向いています。

段階ごとに見る：HTTP の中身

暗号化されない HTTP で再現できる場合（検証環境や、HTTP のままのヘルスチェック用 URL など）は、中身を直接表示できます。

sudo tcpdump -i any -nn -A 'host 192.0.2.10 and port 80'

-A はパケットの中身を ASCII で表示します。送ったリクエストヘッダー（Host、User-Agent など）と、返ってきたステータス行を確認できます。

HTTPS の中身まで見る必要がある場合、curl は環境変数 SSLKEYLOGFILE で TLS の鍵情報を書き出し、Wireshark で復号できます。wget ではビルドに使われている TLS ライブラリによって対応が異なるため、復号まで必要なら curl で同じリクエストを再現するほうが手早いことが多いです。鍵情報のファイルは通信を復号できる情報なので、調査後に削除してください。

サーバー側で受け取りを確認する

クライアント側のキャプチャで SYN が出ているのに応答がない場合、サーバー側でも同時に取得すると、どこで消えているかが分かります。

# サーバー側：クライアントの IP からの 443 番ポートの通信
sudo tcpdump -i any -nn 'src host 198.51.100.20 and port 443'

サーバーに SYN が届いていなければ、途中の経路やクラウドのセキュリティグループ、ロードバランサーの設定を疑います。届いているのに応答していなければ、サーバーのファイアウォールやアプリケーションの待ち受け設定を確認します。

キャプチャの扱いと注意点

長時間取得するときは、ファイルを分割して容量を抑えます（例：-C 100 -W 5 で 100MB 単位、5 ファイルで回す）
取得した pcap には個人情報や認証情報が含まれることがあります。共有する前に、必要な部分だけを切り出すか、社内の取り扱いルールに従ってください
本番サーバーでの取得は負荷とディスク容量に注意し、フィルタで対象を絞ります
tcpdump のオプションやバージョンによる違いは man tcpdump で確認してください。本記事は一般的な Linux ディストリビューションに含まれる tcpdump と wget を前提にしています（2026年10月現在）

まとめ

wget にはキャプチャ機能がないため、wget で条件を固定したリクエストを出し、tcpdump で記録して突き合わせます
wget 側では -S・--spider・-d で応答ヘッダーや接続先 IP を先に確認し、--tries=1 と --timeout で再現条件を固定します
DNS（port 53）→ TCP（SYN/RST）→ TLS（Client Hello とアラート）→ HTTP（-A）の順に、止まっている段階を特定します
HTTPS の中身の復号が必要なら、SSLKEYLOGFILE に対応した curl で再現するほうが手早いことが多いです
キャプチャには機密情報が含まれるため、対象を絞り、調査後に削除します