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

はじめに

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

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

本記事では、Wireshark のディスプレイフィルタを軸に、IP アドレスや TCP フラグの基本的な指定から、複数条件の組み合わせパターン、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 年 5 月時点の最新安定版は Wireshark 4.6.5（2026 年 5 月 3 日リリース）です。 このバージョンでは AI 支援による脆弱性報告の急増を受け、38 件の CVE を含む 43 件の脆弱性が修正されています。Wireshark の dissector（プロトコル解析エンジン）の脆弱性は、悪意のあるキャプチャファイルを開くだけで DoS や任意コード実行につながる可能性があるため、信頼できないソースの pcap ファイルを開く前に最新版へのアップデートを推奨します。

参考: Wireshark 4.6.5 Release Notes
“wnpa-sec-2026-50 UDS protocol dissector infinite loop. Issue 21225.”
（4.6.5 では UDS プロトコル dissector の無限ループ脆弱性をはじめ、複数の脆弱性が修正された）
https://www.wireshark.org/docs/relnotes/wireshark-4.6.5.html

サポートポリシー

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

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

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

Windows 環境

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

なお、Wireshark 4.6.5 には Npcap 1.87 が同梱されており、これ以前のバージョンで報告されていた 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 while hiding the currently uninteresting ones.”
（ディスプレイフィルタを使うと、現時点で関心のあるパケットだけに集中し、それ以外を非表示にできる）
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: 特定ホストの特定プロトコルだけ抽出

# 192.168.1.1 宛ての TCP 80 番ポート通信のみ
ip.dst == 192.168.1.1 and tcp.dstport == 80

# 192.168.1.1 と通信している HTTPS（TCP 443 番）のみ
ip.addr == 192.168.1.1 and tcp.port == 443

パターン 2: ノイズを除外して目的の通信を浮き上がらせる

# 内部セグメントの通信を除外（外部通信のみ表示）
not ip.addr == 192.168.0.0/16

# ARP と DNS のブロードキャストノイズを除外
not (arp or dns)

パターン 3: 特定ストリーム内のトラブルだけ抽出

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

# 特定ホスト間の RST パケットだけ
ip.addr == 192.168.1.1 and tcp.flags.reset == 1

パターン 4: 複数ポート・複数 IP を一括指定（in 演算子）

# Web 系ポート（80・443・8080）を一括指定
tcp.port in {80 443 8080}

# 複数の宛先 IP を一括指定
ip.dst in {192.168.1.1 192.168.1.10 192.168.1.20}

パターン 5: 時間範囲とプロトコルの組み合わせ

# 特定時間帯の TLS 通信のみ
frame.time >= "2026-05-01 09:00:00" and frame.time <= "2026-05-01 10:00:00" and tls

# 特定時間帯の HTTP エラーのみ
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

# 接続要求の SYN のみ（SYN-ACK は除外）
tcp.flags.syn == 1 and tcp.flags.ack == 0

よく使うフィルタはボタン化しておくと便利

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

実務でよく使う基本フィルタ（IP・TCP・プロトコル編）

ここでは、トラブルシューティングで即座に使える IP アドレス、TCP フラグ、およびよく使われるプロトコルの抽出条件を整理します。

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

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 のフィルタは dhcp を使用（旧 bootp）

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.5”
（プロトコルフィールド名は dhcp、バージョン 3.0.0 から 4.6.5 で利用可能）
https://www.wireshark.org/docs/dfref/d/dhcp.html

# DHCP のやり取り全般
dhcp

# 純粋な DHCP メッセージのみ（BOOTP を除外）
dhcp and !dhcp.bootp

# 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’. Each flag is described below.”
（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

# ウィンドウアップデートのみ除外（情報量が多すぎる場合）
tcp.analysis.flags and !tcp.analysis.window_update

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

再送（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（Duplicate ACK）と順序逆転（Out-of-Order）の検知

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

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

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

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

ゼロウィンドウ（Zero Window）の検知

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

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

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

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

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

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

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

http.response.code を活用したエラーパケットの抽出

# 全エラー（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. That asymmetry is diagnostic information, not noise — it tells you which side of the connection is causing the problem.”
（クライアント側とサーバ側のキャプチャは異なって見える。この非対称性は診断情報であり、どちら側が問題の原因かを示す）
https://github.com/LpCodes/Identifying-and-Troubleshooting-Common-TCP-Issues-with-Wireshark

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

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

ディスプレイフィルタの記法（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.5）を取得: dissector 脆弱性が継続的に修正されているため、定期更新を推奨
• キャプチャフィルタとディスプレイフィルタは構文・用途が別物: 事後解析はディスプレイフィルタが基本
• 複数条件は and / or / not と () で組み合わせる: in 演算子で複数値の一括指定も可能
• TCP 解析系フィルタ（tcp.analysis.*）はトラブルシュートの強力な武器: 再送・重複 ACK・ゼロウィンドウから原因の方向性を判断
• TLS 1.3 環境では SNI を起点に絞り込む: ペイロードの参照は事前の鍵情報設定が前提
• HTTP ステータスコードと URI の組み合わせで Web エラーを特定: 500 番台はバックエンド、400 番台はクライアント側の切り分け
• DHCP のフィルタは dhcp を使用: Wireshark 3.0 以降 bootp から変更（後方互換あり）
• キャプチャ位置の差は診断情報: 両端で同時にキャプチャして突き合わせるのが基本

ディスプレイフィルタは単なる検索機能ではなく、「どの条件で絞れば原因に最短で到達できるか」を考えるための思考フレームでもあります。本記事のパターンを起点に、現場のトラフィックに合わせて条件を組み合わせていくことで、トラブルシュートの解像度が大きく向上します。

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