Wireshark のフィルタ書き方と複数条件の使い分け｜TCP 再送と HTTP エラーの追跡

はじめに

ネットワークのトラブルシューティングやセキュリティ監査において、パケットキャプチャは基本的な技術のひとつです。その中でも、オープンソースで提供されている Wireshark は広く利用されている標準的なツールであり、多くのエンジニアの日常業務で参照されています。

トラフィック量の多い環境では膨大なパケットが記録されるため、目的の通信だけを素早く見つけ出す「フィルタリング」のスキルが作業効率を大きく左右します。特に複数条件を組み合わせた絞り込みは、単一条件では到達できない通信障害の原因特定に直結するため、実務での頻出スキルです。

本記事では、Wireshark のディスプレイフィルタを軸に、IP アドレスや TCP フラグの基本的な指定から、MAC・VLAN・文字列・パケットサイズでの絞り込み、複数条件の組み合わせパターン、TCP 再送解析、TLS SNI や QUIC を含むモダンプロトコル、HTTP ステータスコードでのエラー特定まで、実務で頻出する書き方を整理して解説します。

Wireshark の概要とネットワーク解析における活用シーン

Wireshark は、ネットワークインターフェースを通過するトラフィックをキャプチャし、人間が理解できる形式で可視化するネットワークプロトコルアナライザです。GPL-2.0 ライセンスで公開されており、Windows・macOS・Linux の主要 OS に対応しています。

参考: Wireshark Foundation – 公式サイト
“Wireshark: The world’s most popular network protocol analyzer”
（Wireshark: 世界で最も広く利用されているネットワークプロトコルアナライザ）
https://www.wireshark.org/

パケットキャプチャツールの役割

ネットワーク上を流れるデータは、電気信号や光信号のパルスとして伝送されます。Wireshark はこの生データを収集し、Ethernet や IP、TCP、HTTP といった各プロトコルの階層構造（OSI 参照モデル）に沿ってデコードします。

これにより、パケットのヘッダ情報やペイロードの中身を GUI 上で確認できるようになり、通信の裏側で何がやり取りされているかを把握できます。

通信障害の切り分けやセキュリティ監査での活用

システム開発やインフラ運用の現場で、Wireshark は主に「見えない通信のブラックボックス化」を防ぐために活用されます。

例えば、クライアントとサーバー間で通信エラーが発生した場合、それがネットワークインフラの遅延（パケットロスや再送）によるものなのか、サーバー側アプリケーションの不具合なのかを、パケットの到達状況から客観的に切り分けることができます。セキュリティ監査においては、平文で送信されている機密情報（Telnet や HTTP での認証情報）の検知や、不審な外部通信の解析など、多岐にわたる用途で利用されます。

Wireshark のダウンロードとインストール手順

フィルタリング機能を活用する前に、手元の環境に Wireshark をセットアップします。

公式サイトからのダウンロードと最新版

セキュリティの観点から、インストーラーは公式サイト（wireshark.org）からダウンロードすることを推奨します。Windows、macOS、Linux など、利用中の OS に適合した最新の安定版（Stable Release）を選択します。

2026 年 6 月時点の最新安定版は Wireshark 4.6.6 です。このバージョンでは、ROHC プロトコル dissector のクラッシュ（wnpa-sec-2026-51）や MACsec dissector のバッファオーバーフローといった脆弱性が修正されています。Wireshark の dissector（プロトコル解析エンジン）の脆弱性は、悪意のあるキャプチャファイルを開くだけで DoS や任意コード実行につながる可能性があるため、信頼できないソースの pcap ファイルを開く前に最新版へのアップデートを推奨します。

参考: Wireshark 4.6.6 Release Notes
“The Windows installers now ship with Npcap 1.88.”
（Windows 版インストーラーは Npcap 1.88 を同梱します）
https://www.wireshark.org/docs/relnotes/wireshark-4.6.6.html

サポートポリシー

Wireshark は最新 2 系列がメンテナンス対象で、各リリースには最低 18 ヶ月、最大 30 ヶ月のサポートが提供されます。2026 年 6 月時点で、現行の Stable は 4.6 系（最新 4.6.6）、Old Stable（LTS 相当）は 4.4 系（最新 4.4.16）です。OS サポートの境目としては、Wireshark 4.6 が Windows 10・RHEL 8・Qt 5 に対応する最後のメジャーリリース、Wireshark 4.2 が macOS 10.14〜10.15 に対応する最後のメジャーリリースとなります。これらより古い OS を使う場合は、対応する系列を選択する必要があります。

OS ごとのインストールとパケットキャプチャドライバ

インストールウィザードは基本的にデフォルトの設定で進めて問題ありませんが、OS によってパケットをキャプチャするための基盤コンポーネントが異なります。

Windows 環境

インストール途中で Npcap（ネットワークパケットキャプチャライブラリ）のインストールが求められます。これがないとネットワークトラフィックを捕捉できないため、同時にインストールすることを推奨します。

なお、Wireshark 4.6.6 の Windows 版には Npcap 1.88 が同梱されており、Windows 環境での低レベルのパケットキャプチャの安定性が改善されています。

macOS 環境

キャプチャ用デバイスへのアクセス権限を付与するため、ChmodBPF というコンポーネントのインストールが必要です。ウィザードの指示に従い、システム設定で許可を付与します。

Linux 環境

主要ディストリビューションのパッケージマネージャからインストールできます。Ubuntu / Debian 系の例:

sudo apt install wireshark

インストール時に「non-superusers が Wireshark を実行できるようにするか」を尋ねられたら Yes を選択します。No を選んだ場合は sudo dpkg-reconfigure wireshark-common で後から変更可能です。続いて、自身を wireshark グループに追加してログインし直すことで、sudo なしでキャプチャ可能になります。

sudo usermod -aG wireshark $USER

キャプチャフィルタとディスプレイフィルタの違い

Wireshark のフィルタリングには、大きく分けて「キャプチャフィルタ」と「ディスプレイフィルタ」の 2 つの方式が存在します。本記事で扱うのは、より柔軟で実務によく使われる後者のディスプレイフィルタです。

両者は適用タイミング・構文・前提条件が異なるため、状況に応じて使い分けます。

使い分けの判断基準

 トラブルシュート目的で短時間キャプチャ:
ディスプレイフィルタを推奨します。全パケットを保持しておけば、後から条件を変更しながら多角的に解析できます。

 常時監視や大容量保存が前提:
キャプチャフィルタを推奨します。ディスク容量とメモリ消費を抑制できます。

 両者の併用:
キャプチャ時に必要最小限まで絞り込み（例: 特定セグメントのトラフィックのみ）、その後ディスプレイフィルタで詳細を抽出する方法もあります。

参考: Wireshark User’s Guide – Filtering Packets
“Display filters allow you to concentrate on the packets you are interested in”
（ディスプレイフィルタを使うと、関心のあるパケットだけに集中できる）
https://www.wireshark.org/docs/wsug_html_chunked/

ディスプレイフィルタの基本構文と複数条件の組み合わせ

実務では、単一条件のフィルタだけで原因特定にたどり着くことは稀です。「特定ホスト宛ての TCP 80 番ポートで、かつエラーレスポンスを返したもの」のように、複数の条件を組み合わせる書き方が、ディスプレイフィルタを活かすポイントになります。

演算子の一覧

ディスプレイフィルタで使える主要な演算子をまとめました。

演算子の優先順位とカッコの使い方

演算子には優先順位があります。not > and > or の順で評価されるため、意図した順序で評価させたい場合は明示的にカッコ () を使うことを推奨します。

# カッコなしの場合（or が最後に評価される）
ip.addr == 192.168.1.1 and tcp.port == 80 or tcp.port == 443
# 解釈: (192.168.1.1 かつ 80番) または 443番（意図と異なる可能性大）

# カッコで明示
ip.addr == 192.168.1.1 and (tcp.port == 80 or tcp.port == 443)
# 解釈: 192.168.1.1 で 80番 または 443番（意図通り）

複数条件の実用パターン集

実務で頻出する組み合わせパターンを整理しました。コピーして即座に活用できる形で並べています。

# パターン 1: 特定ホストの特定プロトコルだけ抽出
ip.dst == 192.168.1.1 and tcp.dstport == 80
ip.addr == 192.168.1.1 and tcp.port == 443

# パターン 2: ノイズを除外して目的の通信を浮き上がらせる
not ip.addr == 192.168.0.0/16
not (arp or dns)

# パターン 3: 特定ストリーム内のトラブルだけ抽出
tcp.stream == 5 and tcp.analysis.retransmission
ip.addr == 192.168.1.1 and tcp.flags.reset == 1

# パターン 4: 複数ポート・複数 IP を一括指定（in 演算子）
tcp.port in {80 443 8080}
ip.dst in {192.168.1.1 192.168.1.10 192.168.1.20}

# パターン 5: 時間範囲とプロトコルの組み合わせ
frame.time >= "2026-05-01 09:00:00" and frame.time <= "2026-05-01 10:00:00" and tls
frame.time >= "2026-05-01 09:00:00" and http.response.code >= 400

# パターン 6: エラー条件の複合検出
http.response.code >= 400 and http.response.code < 500 and ip.dst == 192.168.1.1
tcp.flags.syn == 1 and tcp.flags.ack == 0

頻繁に使う複数条件フィルタは、フィルタバー右側の「+」ボタンから「フィルタボタン」として保存できます。tcp.analysis.flags のような頻出フィルタをワンクリックで適用できるようにしておくと、トラブルシュート時の作業効率が向上します。

実務でよく使う基本フィルタ（IP・MAC・VLAN・ポート編）

トラブルシューティングで即座に使える抽出条件を、目的別に整理します。

まず、使う頻度の高いフィルタを目的別にまとめました。詳細は各項で解説します。

特定の IP アドレスやポート番号の抽出

# 送信元 IP が 192.168.1.1 のパケット
ip.src == 192.168.1.1

# 送信先 IP が 192.168.1.1 のパケット
ip.dst == 192.168.1.1

# 送信元・送信先を問わず特定 IP を含むパケット
ip.addr == 192.168.1.1

# 特定 IP をノイズとして除外
not ip.addr == 192.168.1.1

# 特定のサブネット（CIDR）を指定
ip.addr == 192.168.1.0/24

# TCP ポート番号の複数指定（in 演算子）
tcp.port in {80 443}

ip.addr != 192.168.1.1 は「送信元または送信先のいずれかが 192.168.1.1 でない」と解釈されるため、192.168.1.1 を含むパケットも表示されることがあります。確実に除外したい場合は not ip.addr == 192.168.1.1 の書き方を推奨します。

MAC アドレスでの絞り込み

L2 レベルで特定の機器を追う場合は、eth 系のフィールドを使います。

# 送信元・送信先を問わず特定 MAC を含むパケット
eth.addr == aa:bb:cc:dd:ee:ff

# 送信元 MAC で絞る
eth.src == aa:bb:cc:dd:ee:ff

# 送信先 MAC で絞る
eth.dst == aa:bb:cc:dd:ee:ff

# マルチキャストのみ
eth.dst.ig == 1

eth.addr != x も ip.addr != x と同じく「送信元または送信先のいずれかが x でない」と解釈されるため、確実に除外したい場合は not eth.addr == x の書き方を推奨します。
（参照: https://www.wireshark.org/docs/dfref/e/eth.html ）

VLAN・CoS での絞り込み

タグ VLAN 環境では、vlan 系フィールドで VLAN ID や CoS（802.1p の優先度）を指定できます。

# タグ付き（802.1Q）フレームのみ
vlan

# 特定の VLAN ID
vlan.id == 10

# CoS（優先度）で絞る
vlan.priority == 5

# タグなしフレームのみを見る
not vlan

タグなしのフレームだけを確認したい場合は not vlan が使えます。
（参照: https://www.wireshark.org/docs/dfref/v/vlan.html ）

パケットサイズ（長さ）で絞り込む

# フレーム長が 1000 バイトを超えるパケット
frame.len > 1000

# データ（ペイロード）を含む TCP パケットのみ
tcp.len > 0

# MTU 近辺の大きなパケット
frame.len >= 1500

2 ホスト間の通信だけを抽出する

# 192.168.1.1 と 192.168.1.10 の間の通信のみ
ip.addr == 192.168.1.1 and ip.addr == 192.168.1.10

これは「192.168.1.1 を含み、かつ 192.168.1.10 を含む」パケット、すなわち両ホスト間の双方向の通信を抽出します。特定の 2 機器間のやり取りだけを見たい場合に便利です。

TCP フラグでセッション状態を確認する

TCP のコネクション確立（3 ウェイハンドシェイク）や強制切断の有無を確認する際に役立ちます。

# 接続要求のみ（SYN かつ ACK なし）
tcp.flags.syn == 1 and tcp.flags.ack == 0

# SYN-ACK（接続応答）のみ
tcp.flags.syn == 1 and tcp.flags.ack == 1

# 強制リセット（RST）パケット
tcp.flags.reset == 1

# FIN（正常終了）パケット
tcp.flags.fin == 1

tcp.flags.reset == 1 は、サーバー側からの異常切断やファイアウォールによるブロックの兆候を見つける際に多用されます。

アプリケーションプロトコルでの絞り込み

# DNS と ICMP を一度に表示
dns or icmp

# 特定ドメインに対する DNS クエリ
dns.qry.name == "example.com"

# DNS の応答のみ
dns.flags.response == 1

DHCP 関連の通信を抽出する際、現行の Wireshark では dhcp を使用します。Wireshark 3.0 でフィルタ名が bootp から dhcp にリネームされたためです。後方互換のため bootp.* も引き続きエイリアスとして動作しますが、最新の公式ディスプレイフィルタリファレンスでは dhcp が標準表記になっています。

参考: Wireshark Display Filter Reference – Dynamic Host Configuration Protocol
“Protocol field name: dhcp / Versions: 3.0.0 to 4.6.6”
（プロトコルフィールド名は dhcp、バージョン 3.0.0 から 4.6.6 で利用可能）
https://www.wireshark.org/docs/dfref/d/dhcp.html

# DHCP のやり取り全般
dhcp

# DORA フローのメッセージタイプ別抽出
dhcp.option.dhcp == 1   # Discover
dhcp.option.dhcp == 2   # Offer
dhcp.option.dhcp == 3   # Request
dhcp.option.dhcp == 5   # ACK
dhcp.option.dhcp == 6   # NAK

# 特定クライアントの DHCP やり取り
dhcp and dhcp.hw.mac_addr == 00:50:56:00:9f:8e

TCP 解析系フィルタとトラブルシュート

ディスプレイフィルタには、Wireshark がパケットの流れを解析した結果に基づく tcp.analysis.* 系のフィルタ群があります。これらは「再送が起きた」「重複 ACK が出ている」「受信バッファが枯渇した」など、TCP プロトコル単独では検出できないトラブル兆候を可視化できる機能です。Wireshark がスライディングウィンドウを内部で監視し、シーケンス番号と ACK の対応関係から異常を判定しています。

参考: Wireshark User’s Guide – 7.5 TCP Analysis
“TCP Analysis flags are added to the TCP protocol tree under ‘SEQ/ACK analysis'”
（TCP 解析フラグは TCP プロトコルツリーの SEQ/ACK analysis 配下に追加される）
https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html

tcp.analysis.flags: トラブル兆候の入口フィルタ

最初に試すフィルタとして、tcp.analysis.flags が広く知られています。Wireshark が異常を検知した全パケット（再送・重複 ACK・順序逆転・ゼロウィンドウ等）を一括で表示できます。

# Wireshark が検知した TCP の異常を全て表示
tcp.analysis.flags

膨大なキャプチャの中で問題のあるパケットだけを浮き上がらせるため、トラブルシュートの初動として有効です。

Bad TCP: ノイズを除いた異常パケットだけを表示

tcp.analysis.flags は、キープアライブやウィンドウアップデートといった正常な範囲の通知も含むため、情報量が多くなりがちです。Wireshark の標準のカラーリングルール「Bad TCP」に相当する、本当に問題のあるパケットだけに絞るには、これらを除外します。

# Bad TCP 相当（再送・重複 ACK・順序逆転・ゼロウィンドウ等に集中）
tcp.analysis.flags && !tcp.analysis.window_update && !tcp.analysis.keep_alive && !tcp.analysis.keep_alive_ack

このフィルタは頻繁に使うため、フィルタボタンとして保存しておくと、トラブルシュートの初動で素早く適用できます。

再送（Retransmission）の検知

再送はパケット損失や輻輳の典型的な兆候です。スループット低下や応答遅延の原因究明で頻出します。

# 通常の再送（タイムアウトベース）
tcp.analysis.retransmission

# 高速再送（重複 ACK 3 回でトリガー）
tcp.analysis.fast_retransmission

# 全種類の再送をまとめて表示
tcp.analysis.retransmission or tcp.analysis.fast_retransmission

# 偽の再送（実際には届いていたが ACK が遅れた）
tcp.analysis.spurious_retransmission

# 特定ストリーム内の再送だけ
tcp.stream == 5 and tcp.analysis.retransmission

重複 ACK・順序逆転の検知

重複 ACK は受信側がパケット損失を検知した際に送る信号で、再送のトリガーとなります。順序逆転は経路の不安定さや負荷分散の挙動を示すことがあります。

# 重複 ACK（パケット損失の予兆）
tcp.analysis.duplicate_ack

# 順序逆転（経路の不安定さやマルチパスの兆候）
tcp.analysis.out_of_order

# 失われた可能性のあるセグメント
tcp.analysis.lost_segment

ゼロウィンドウの検知

ゼロウィンドウは受信側のバッファが枯渇したことを示し、ネットワーク側ではなく受信側アプリケーション・OS の問題を示唆します（ディスク I/O 遅延、CPU 過負荷、バッファサイズ不足など）。

# 受信バッファ枯渇
tcp.analysis.zero_window

# ウィンドウフル（送信側が送信を停止せざるを得ない状態）
tcp.analysis.window_full

# ゼロウィンドウプローブ（送信側が受信側に状態を確認）
tcp.analysis.zero_window_probe

特定のパケットを起点に 1 セッションを通して追いたい場合は、対象パケットを右クリックして「追跡 > TCP ストリーム」を選ぶと、tcp.stream == N のフィルタが自動で適用されます。

TCP トラブル兆候とフィルタの早見表

Expert Information の活用

tcp.analysis.* 系フィルタの結果は、メニューの「Analyze → Expert Information」からも一覧できます。色分けされた重要度別（Error / Warn / Note / Chat）に並ぶため、どこから見ればよいか判断しやすくなります。トラブルシュートではフィルタとセットで活用することを推奨します。

モダンプロトコルのフィルタリング設定

Web 通信の暗号化（TLS 1.3）や UDP ベースのプロトコル（QUIC）が主流となった現代の環境では、従来の http.host や TCP ベースの解析だけでは情報を取得できないケースが増えています。

TLS の SNI（Server Name Indication）を用いた抽出

現代の Web 通信は暗号化されているため、ペイロードから宛先ドメインを判別することは困難です。代わりに、TLS ハンドシェイクの Client Hello に含まれる SNI（Server Name Indication）は平文で流れるため、ここを抽出して特定ドメイン宛ての暗号化トラフィックを識別します。

# 特定ドメイン宛ての TLS 通信を抽出
tls.handshake.extensions_server_name == "example.com"

# 特定ドメインを部分一致で抽出
tls.handshake.extensions_server_name contains "example"

# Client Hello のみを抽出（ハンドシェイク開始タイミングの確認）
tls.handshake.type == 1

TLS 復号の前提条件（制約）

TLS で暗号化された通信のペイロードは、原則として平文で参照できません。復号には以下のいずれかが必要です。

• サーバー側 RSA 秘密鍵（RSA 鍵交換の場合のみ有効。TLS 1.3 では使用不可）
• セッション中に記録した pre-master secret ログファイル（SSLKEYLOGFILE 環境変数で出力）。設定箇所は Edit → Preferences → Protocols → TLS。

TLS 1.3 では Forward Secrecy が標準のため、鍵情報を後から取得することはできません。復号を前提とする解析では、キャプチャ取得と同時に鍵情報を出力する仕組みを用意しておく必要があります。

QUIC（HTTP/3）トラフィックの抽出

HTTP/3 は TCP ではなく UDP（443 番ポート）を使用するため、TCP ベースのフィルタでは捕捉できません。

# QUIC プロトコルのパケット
quic

# UDP 443 番宛ての通信全般
udp.dstport == 443

# QUIC の Initial Packet（接続開始）のみ
quic.long.packet_type == 0

QUIC は接続情報の多くが暗号化されており、TLS の SNI に相当する情報も Initial Packet 内に含まれますが、参照には別途設定が必要です。

正規表現（matches）と部分一致（contains）の活用

特定の文字列パターンを含む通信を抽出する場面で、matches（正規表現）と contains（部分一致）が有効です。

# /api/ から始まる URI を持つ HTTP リクエスト
http.request.uri matches "^/api/"

# .json で終わる URI
http.request.uri matches "\.json$"

# User-Agent に "curl" を含むリクエスト
http.user_agent contains "curl"

# パケットペイロードに特定文字列を含む
frame contains "password"

参考: Wireshark Display Filter Reference – Operators
“matches: regular expression (PCRE2) match. The regular expression is a Perl-compatible expression.”
（matches は PCRE2 準拠の正規表現マッチ。Perl 互換の式が利用できる）
https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html

Info 列の文字列で絞り込みたい場合

パケット一覧の Info 列は、各 dissector が組み立てた表示であり、info という単一のフィルタフィールドは存在しません。Info 列に見える文字列で絞り込みたい場合は、次のいずれかを使います。

# パケット全体から文字列を探す（最も手軽）
frame contains "Login"

# 該当するプロトコルフィールドで絞る（例: HTTP の URI）
http.request.uri contains "/login"

# 大文字・小文字を区別せず探す（正規表現の i フラグ）
frame matches "(?i)login"

なお、フィルタではなく一時的に探すだけであれば、「編集 > パケットの検索」（Ctrl+F）で Info 列やパケット詳細の文字列を検索することもできます。フィルタは表示を絞り込み、検索は該当パケットへジャンプする、という違いがあります。

HTTP ステータスコードを用いた Web トラブルシュート

Web サーバーとクライアント間の通信で画面上にエラーが表示された際、ネットワークレベルでどのリクエストが失敗しているかを特定することが調査の起点になります。

# 全エラー（400 番台と 500 番台）
http.response.code >= 400

# 正常応答（200 OK）のみ
http.response.code == 200

# 特定のステータスコードのみ
http.response.code == 404

# クライアントエラー（400 番台）
http.response.code >= 400 and http.response.code < 500

# サーバエラー（500 番台）
http.response.code >= 500

# リダイレクト（300 番台）: リダイレクトループの調査等で活用
http.response.code >= 300 and http.response.code < 400

特にリバースプロキシやロードバランサーを経由する環境では、特定のステータスコードを狙い撃ちすることが有効です。

# 503 のみピンポイント抽出
http.response.code == 503

# 502 / 503 / 504 のゲートウェイ系エラーのみ
http.response.code in {502 503 504}

# 認証・認可系のエラーのみ
http.response.code in {401 403}

エラーが特定のエンドポイントで発生している場合、ステータスコードと URI を組み合わせることで原因の特定が早まります。

# /api/ 配下のエラーレスポンスのみ
http.response.code >= 400 and http.request.uri matches "^/api/"

# 特定ホスト宛ての 5xx エラーのみ
http.response.code >= 500 and ip.dst == 192.168.1.10

これらのフィルタを適用することで、膨大な Web トラフィックの中から障害の根本原因となるパケットを素早く見つけ出し、詳細なペイロード解析へと移行できます。

フィルタ適用時の制約と注意点

ディスプレイフィルタを使いこなす上で、見落とされがちな制約と注意点を整理しました。

TLS 1.3 の暗号化通信は平文で参照できない

TLS で暗号化されたペイロードは、復号前提でなければ平文では参照できません。HTTP のヘッダ・ボディ・URI などはすべて暗号化対象となるため、http.host や http.request.uri といったフィルタは TLS 通信に対しては機能しません。代わりに、TLS の SNI（tls.handshake.extensions_server_name）や TCP/IP レベルの情報を起点にした絞り込みが必要です。

キャプチャ位置によって見え方が変わる

クライアント側でキャプチャした結果と、サーバー側でキャプチャした結果は同一にはなりません。経路上のパケット損失や順序逆転は、キャプチャ位置によって観測される/されないが分かれます。これはノイズではなく診断情報であり、問題の発生箇所を特定する手がかりになります。

参考: TCP トラブルシュートガイド
“Captures taken at the client vs. the server will look different.”
（クライアント側とサーバー側のキャプチャは異なって見える）
https://github.com/LpCodes/Identifying-and-Troubleshooting-Common-TCP-Issues-with-Wireshark

両端で同時にキャプチャを取得し、突き合わせて解析するアプローチを推奨します。

また、ASIC を搭載した機器（FortiGate など）では、専用プロセッサーにオフロードされたセッションが特定地点のキャプチャに現れないことがあります。FortiGate でのキャプチャ取得と pcap への変換手順は、関連記事『FortiGate のキャプチャを Wireshark で解析｜fgt2eth 変換の手順』を参照してください。

キャプチャフィルタとディスプレイフィルタは構文が別物

ディスプレイフィルタの記法（ip.addr == ...、tcp.port == ...）はキャプチャフィルタでは使えず、その逆も同様です。キャプチャフィルタは BPF 構文（host、port、net 等）を使います。tcp.analysis.* のような解析系フィルタはディスプレイフィルタ専用で、キャプチャフィルタには存在しません。

bootp と dhcp の互換性に注意

Wireshark 3.0 以降では dhcp が公式表記となっています。bootp はエイリアスとして引き続き動作するものの、表示フィルタリファレンスでは「Versions: 1.0.0 to 2.6.20」と記載されており、3.0 以降は dhcp に置き換えられました。新規にフィルタを書く際は dhcp を使うことを推奨します。

dissector の脆弱性とキャプチャファイルの取り扱い

Wireshark の dissector には定期的に脆弱性が報告されており、悪意のあるキャプチャファイルを開くだけで DoS や任意コード実行につながる可能性があります。信頼できないソースから受け取ったキャプチャファイルを開く際は、最新版の Wireshark を使用し、可能であれば隔離された解析環境（仮想マシン等）で開くことを推奨します。

大容量キャプチャでのパフォーマンス

ディスプレイフィルタは全パケットを保持した上で表示を絞り込む方式のため、数 GB を超えるキャプチャファイルではフィルタ適用に時間がかかり、メモリ消費も増大します。長時間キャプチャや常時監視用途では、tshark でファイルを前処理する方法も検討できます。

# tshark で大容量 pcap から HTTP エラーのみを抽出して別ファイルに保存
tshark -r large.pcap -Y "http.response.code >= 400" -w errors.pcap

まとめ

本記事では、Wireshark のディスプレイフィルタを軸に、目的別の基本フィルタから複数条件の組み合わせ、TCP 解析、モダンプロトコル、HTTP エラー追跡までを整理しました。ディスプレイフィルタは単なる検索ではなく、どの条件で絞れば原因に最短で到達できるかを考えるための道具でもあります。最新版を保ちつつ、現場のトラフィックに合わせてパターンを組み合わせることで、トラブルシュートの解像度が上がります。

• 最新の安定版は 4.6.6（Npcap 1.88 同梱、dissector 脆弱性の修正が継続）
• 事後解析はディスプレイフィルタ、大容量取得はキャプチャフィルタが基本
• 複数条件は and / or / not と () で組み立て、in で複数値を一括指定
• IP・MAC・VLAN・ポート・文字列・サイズなど目的別に絞り込み
• TCP の異常は Bad TCP でノイズを除いて把握
• TLS 1.3 環境は SNI を起点に絞り込み、復号は事前の鍵情報が前提
• HTTP は 400 番台でクライアント側、500 番台でバックエンド側を切り分け

以上、最後までお読みいただきありがとうございました。