Windowsのパケットキャプチャ実務 ── pktmon・netsh trace・Wiresharkの使い分け

「業務アプリの通信が月に数回失敗する。ログには“タイムアウト”だけ。サーバー側にもエラーはなく、再現条件も分からない」。通信障害の調査で、よく出会う状況です。

このとき知りたいのは、接続できなかったのか、接続した後で応答が止まったのかです。同じタイムアウトでも、次に調べる場所は違います。

アプリのログに残るのは、アプリが「書こうと決めたこと」だけです。「タイムアウト」という結果だけでは、SYNに応答がなかったのか、確立した接続でサーバーが黙ったのか、RSTで切られたのかを区別できません。

その一段下にある実際に線を流れたパケットを調べるのが、パケットキャプチャです。ファイルやレジストリへのアクセスを一段下から見るProcess Monitorに対して、こちらは通信の一段下を見ます。パケットが宛先に届いたかまで確かめたいときは、7章で扱う両側採取が重要になります。

flowchart TB
    accTitle: アプリログの一段下にあるパケット
    accDescr: アプリログには書こうと決めたことしか残らず、SYNに応答がなかったのか、確立後に黙ったのか、RSTで切られたのか、そもそも届いたのかは実際に線を流れたパケットにしか残らないことを示す
    log["アプリのログ"] --> dec["書こうと決めたことだけ残る"]
    dec --> to["結果は「タイムアウト」の一言"]
    to -->|一段下を見る| pkt["実際に線を流れたパケット"]
    pkt --> q1["SYNに応答なし?"]
    pkt --> q2["確立後に沈黙?"]
    pkt --> q3["RSTで切断?"]
    pkt --> q4["宛先に届いた?"]

図1: ログに残るのは結果だけで、タイムアウトの内訳は一段下のパケットにしか残らない。

「顧客サーバーにWiresharkをインストールできない」場合も、採取を諦める必要はありません。変更管理やセキュリティポリシーでソフトを追加できなくても、Windowsにはpktmonとnetsh traceという標準の採取手段があります。

基本は、現場の標準ツールで採り、手元のWiresharkで読むという分担です。採取と解析を別の作業として考えると、インストール制約のある現場でも調査を進められます。

この記事では、中小企業の情シス担当者とWindowsアプリ開発者を対象に、pktmon・netsh trace・Wiresharkの使い分けと、それぞれの実務手順を整理します。ループバック通信の罠、クライアント側とサーバー側どちらで採るかの判断、TLSで中身が見えない問題への向き合い方、アプリログとの突き合わせまで、2026年8月時点の一次情報にもとづいて解説します。

困っていることから読む

初めて読む方は、2章で道具を選び、3〜4章で採取し、5章で読む流れを押さえてください。6〜8章は採取条件や観測範囲の注意、9章はアプリログと合わせて結論を出す手順です。

1. まず結論

採取と解析は、別の道具に任せてよい

現場ではpktmonかnetsh traceで採取し、pcapngへ変換して手元のWiresharkで解析します。どちらの出力もETLなので、そのままではWiresharkで開けません。pktmonには pktmon etl2pcap、netsh traceにはMicrosoft製のオープンソースツールetl2pcapngを使います。¹²

道具選びはまずpktmon、足りなければnetsh trace、プロトコル解析はWiresharkです。Microsoftの調査ガイドも、この流れを案内しています。³

採取前に、残す情報と観測する場所を決める

pktmonはWindows 10 / Windows Server 2019以降に標準搭載され、フィルタ登録→開始→停止→変換の4手順で使えます。スタック内のどこでパケットが破棄されたかと、ドロップ理由が分かるのが独自の強みです。ただし、既定で残るのは先頭128バイトだけです。中身まで読むなら開始時に --pkt-size 0 を指定します。⁴⁵⁶

netsh traceはより古くからある標準ツールです。シナリオでETWプロバイダー群を束ね、パケットとWindows内部のイベントを採取できます。再起動をまたぐ採取には persistent=yes を使います。⁷⁸

localhost宛は物理NICを通らないため、物理アダプタのキャプチャには映りません。Npcapのループバックアダプタか、pktmonのスタック内採取を使います。⁹

読み取れる事実と、ファイルの取り扱いを分けて考える

TLSで中身が見えなくても、接続確立、TLSハンドシェイクの成否、RST、どちらが黙ったかは調べられます。SSLKEYLOGFILEによる復号は、開発環境限定の手段です。¹⁰

一方、キャプチャファイルには通信内容そのものが入ります。認証情報や個人情報を含み得る前提で、対象と期間を最小限にし、社外へ渡す前の絞り込みまでを採取手順に含めます。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. キャプチャの3つの道具と使い分け

選ぶ基準は「現場に何を入れられるか」と「パケット以外に何を残したいか」です。まず、3つの道具の役割を比べます。

pktmonとnetsh traceは「採る」、Wiresharkは「読む」役割に分けると考えやすくなります。Wiresharkにも採取機能はありますが、インストールできない現場では利用できません。

標準ツールのETLをテキスト変換して読むことも可能です。ただし、表示フィルタやTCP解析なしに目視するより、pcapngへ変換してWiresharkで解析するほうが調査を進めやすくなります。

flowchart TB
    accTitle: 採るのは標準ツール、読むのはWireshark
    accDescr: 現場ではpktmonまたはnetsh traceでETLを採取し、それぞれの変換ツールでpcapngへ変換して、手元のWiresharkで解析する分担を示す
    pk["pktmon（標準）"] --> etla["ETLファイル"]
    ns["netsh trace（標準）"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["手元のWiresharkで解析"]

図2: 現場では標準ツールでETLを採取し、pcapngへ変換して手元のWiresharkで読む。

Microsoftのパケットロス調査ガイドも同じ構図で、まずpktmonで採取と原因の切り分けを行い、それで足りなければnetsh trace start scenario=InternetClientなどのコンポーネントレベルのトレースへ進み、プロトコルの振る舞いはWiresharkで解析する、という順序を示しています。³

なお、パケットに何が写っているかを読む前提として、Ethernet・IP・TCP・アプリケーションデータという層の重なりをイメージできていると理解が速くなります。層の解剖は「OSI参照モデルをはっきりイメージする」で図解しています。

3. pktmon実務 ── フィルタ→開始→停止→変換

採取の基本はフィルタ登録→開始→停止→変換の4手順です。終了後にはフィルタも片付けます。以下は管理者権限のターミナルで実行します。

開始前に、既存のフィルタと終了後の片付け方を確認してください。最後の pktmon filter remove は名前を指定して消す操作ではなく、登録済みフィルタをすべて削除します。別の調査と共用している環境では、先に pktmon filter list で確認します。

:: 1. 先にフィルタを登録して対象を絞る(対象サーバー192.168.10.20のTCP 8443)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. 採取開始。パケット全体を記録し、1GBのリングバッファで上書き
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. 事象を再現させる。待つ間はカウンターで流量と破棄を確認できる
pktmon counters --drop-reason

:: 4. 停止して、Wireshark用にpcapngへ変換
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. 登録したフィルタを片付ける(フィルタは明示的に消すまで残る)。
::    注意: filter remove は名前を指定できず、登録済みフィルタを「すべて」削除する。
::    別の調査のフィルタが残っている環境では、先に pktmon filter list で確認する
pktmon filter remove

flowchart TB
    accTitle: pktmonの基本手順
    accDescr: フィルタ登録で対象を絞ってから採取を開始し、事象を再現させて停止し、etl2pcapでpcapngへ変換し、最後に登録したフィルタを削除する流れ
    fa["1. filter addで対象を絞る"] --> st["2. start --captureで採取開始"]
    st --> re["3. 事象を再現させる"]
    re -.-> ct["countersで流量と破棄を確認"]
    re --> sp["4. stopで停止"]
    sp --> cv["etl2pcapでpcapngへ変換"]
    cv --> rm["5. filter removeで片付け"]

図3: pktmonはフィルタ登録から始め、採取・停止・変換のあとフィルタを明示的に片付ける。

コマンドを実行する前に、次の4点を決めておくと採り直しを減らせます。

採取前に確認すること

対象を絞る: 複数フィルタはOR条件

フィルタは採取開始前に登録します。Microsoftのドキュメントも、全トラフィックの採取はノイズが多すぎるとして、開始前のフィルタ適用を強く推奨しています。フィルタはIPアドレス、ポート、MACアドレス、プロトコル、VLAN IDなどで指定でき、最大32個まで登録できます。複数のフィルタは「いずれかに合致したら記録」というOR条件です。⁴

方向を絞る: 送信元と宛先は区別されない

pktmonのフィルタは送信元と宛先を区別しません。-i 192.168.10.20は「このアドレスが送信元または宛先のパケット」を意味します。方向の絞り込みは、変換後にWiresharkの表示フィルタで行います。⁴

記録範囲を決める: ヘッダーだけか、パケット全体か

既定のパケットサイズは128バイトです。ヘッダーの解析だけならこれで足りますが、アプリケーションデータまで読むなら--pkt-size 0で全体を記録します。⁶

容量を決める: リングバッファとリアルタイム表示

ログは既定でcircular(リングバッファ)モード、既定サイズは512MBです。--file-sizeで上限を変えられるほか、--log-mode real-timeにすると画面にリアルタイム表示され、ログファイルは作られません。まずリアルタイム表示で「狙った通信が見えていること」を確かめてから、本番の採取を仕掛けると空振りを防げます。⁶

flowchart TB
    accTitle: pktmonフィルタの効き方
    accDescr: 登録した複数のフィルタはいずれかに合致したら記録というOR条件で働き、指定したアドレスは送信元と宛先を区別しないため、方向の絞り込みは変換後にWiresharkの表示フィルタで行うことを示す
    f1["フィルタ1"] --> orc["いずれかに合致で記録"]
    f2["フィルタ2"] --> orc
    f3["フィルタ3（最大32個）"] --> orc
    orc --> rec["採取ログに記録（OR条件）"]
    rec -.-> nodir["送信元と宛先は区別しない"]
    nodir -.-> ws["方向は変換後にWiresharkで絞る"]

図4: 複数フィルタはOR条件で働き、送信元か宛先かの方向は変換後にWiresharkで絞る。

3.1. pktmonならではの強み ── どこで捨てられたかが分かる

Wiresharkと違うpktmonの独自価値は、NICの1地点ではなく、ネットワークスタック内の複数の地点でパケットを捕捉し、破棄(ドロップ)された場所と理由を報告できることです。パケットがどのコンポーネントまで到達し、どこで消えたかが分かるため、「MTU不一致」「VLANフィルタ」のようなドロップ理由から、総当たりせずに原因へ到達できます。⁵

flowchart TB
    accTitle: pktmonはスタック内の複数地点で捕捉する
    accDescr: pktmonはNICの1地点ではなくネットワークスタック内の複数の地点でパケットを捕捉するため、どのコンポーネントまで到達しどこで破棄されたかを理由つきで報告できることを示す
    pin["パケット"] --> p1["地点1で捕捉"]
    p1 --> p2["地点2で捕捉"]
    p2 --> p3["地点3で破棄"]
    p3 -.-> rz["破棄場所とドロップ理由を報告"]
    rz -.-> ex["例 MTU不一致やVLANフィルタ"]

図5: スタック内の複数地点で捕捉するため、どこまで届いてどこで捨てられたかが理由つきで分かる。

まずカウンター、必要ならテキストログで確認する

• pktmon listで、監視対象になるネットワークコンポーネント(NIC、プロトコルスタック、フィルタドライバーなど)の一覧とIDを確認できます。
• pktmon counters --drop-reasonで、コンポーネントごとの通過/破棄カウンターと直近のドロップ理由を一覧できます。ログを解析する前の一次切り分けとして便利です。¹¹
• pktmon etl2txtでテキスト変換すると、破棄されたパケットにはdropとdropReason(破棄理由)が付いて出力されます。⁴

「アプリに届く前にOSのどこかで捨てられているのでは」という疑いは、Wiresharkを眺めるだけでは決着しません。たとえば受信規則の不備でファイアウォールに落とされているケース(「Windowsファイアウォールと業務アプリ」)の切り分けで、この機能は効きます。

Wiresharkへ渡す前に、捕捉地点を絞る

pktmonは同じパケットをスタック内の複数地点で記録します。そのままpcapngへ変換すると、同じパケットが重複して見えることがあります。pcapngには「どのコンポーネントで捕捉したか」の情報が引き継がれないためです。

Wiresharkで読む目的なら、pktmon etl2pcap の --component-id で地点を絞って変換します。ドロップだけを --drop-only で別ファイルにする方法もあります。¹

flowchart TB
    accTitle: pcapng変換で同じパケットが重複して見える理由
    accDescr: pktmonは同じパケットをスタック内の複数地点で記録し、pcapngにはどのコンポーネントで捕捉したかの情報が引き継がれないため重複して見えることがあり、component-idで地点を絞るかdrop-onlyでドロップだけを別ファイルにして変換するのが定石であることを示す
    same["同じパケットを複数地点で記録"] --> conv["そのままpcapngへ変換"]
    conv --> lost["捕捉地点の情報は引き継がれない"]
    lost --> dup["同じパケットが重複して見える"]
    dup --> c1["--component-idで地点を絞る"]
    dup --> c2["--drop-onlyで別ファイルに"]

図6: 捕捉地点の情報がpcapngに引き継がれないため、地点を絞ってから変換するのが定石。

4. netsh trace実務 ── シナリオとETL、再起動をまたぐ採取

netsh traceは、pktmonより古くからWindowsに載っているトレース採取の仕組みです。特徴は「シナリオ」という単位で、その問題に関係するETWプロバイダー一式をまとめて有効化できることです。⁸

:: 使えるシナリオの一覧と、シナリオに含まれるプロバイダーの確認
netsh trace show scenarios
netsh trace show scenario netconnection

:: 採取開始。パケットキャプチャ込み、1GBの循環バッファ
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: 事象を再現させてから停止(マージ処理に少し時間がかかる)
netsh trace stop

netsh traceで決める採取条件

パケットも残すならcapture=yesを付ける

capture=yesを付けるとパケットキャプチャが有効になり、ipv4.address=192.168.10.20のようなキャプチャフィルタで対象を絞れます。フィルタの一覧はnetsh trace show capturefilterHelpで確認できます。⁸

ETLと一緒に、.cabの環境情報も残る

停止するとETLファイルに加えて.cabファイルが生成されます。.cabにはアダプタ構成やOSビルドなどシステム情報が含まれ、環境情報の収集を兼ねられます。⁸

開始前に、既存セッションを確認する

トレースセッションは同時に1つしか実行できません。別の採取を始める前に、走りっぱなしのセッションがないかnetsh trace show statusで確認します。⁸

再起動直後の事象にはpersistent=yesを使う

persistent=yesを付けると、再起動をまたいでセッションが維持されます。「再起動直後の一瞬だけ通信が失敗する」「起動時のサービス接続が失敗する」といった、手動では開始が間に合わない事象の採取はnetsh traceの独壇場です。⁷

flowchart TB
    accTitle: netsh traceのシナリオ採取
    accDescr: シナリオを指定して開始するとETWプロバイダー一式が束ねて有効化され、capture=yesを付けるとパケットも採取され、停止するとETLファイルと.cabファイルが生成される流れを示す
    sc["シナリオを指定して開始"] --> pv["プロバイダー一式を有効化"]
    sc -->|capture=yes| pc["パケットも採取"]
    pv --> re["事象を再現させる"]
    pc --> re
    re --> sp["stopで停止"]
    sp --> etl["ETLファイル"]
    sp --> cab[".cab（システム情報）"]

図7: シナリオで開始するとプロバイダー一式が束ねて有効化され、停止でETLと.cabが生成される。

4.1. ETLをWiresharkで読める形にする ── etl2pcapng

netsh traceのETLは、そのままではWiresharkで開けません。MicrosoftがGitHubで公開しているオープンソースツールetl2pcapngを使うと、netsh trace start capture=yesで採取したETL内のパケットをpcapngへ変換できます。²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

etl2pcapngは変換の際、パケットに関与したプロセスIDをパケットコメントとして書き出します。「どのプロセスの通信か」をWireshark上で確認できるので、同じサーバーに複数のアプリが通信している環境の切り分けで役立ちます。²

パケットとWindows内部のイベントは、読み方が別

なお、ETWイベント側(シナリオプロバイダーが記録したWindows内部のイベント)はpcapngには変換されません。イベントまで読みたい場合はnetsh trace convert input=C:\temp\nettrace.etlでテキスト等に変換するか、Windows Performance Analyzerなどで開きます。⁷³

flowchart TB
    accTitle: netsh traceのETLの読み方は二手に分かれる
    accDescr: ETL内のパケットはetl2pcapngでpcapngへ変換してWiresharkで読み、ETWイベントはpcapngには変換されないためnetsh trace convertやWindows Performance Analyzerで読むことを示す
    etl["netsh traceのETL"] --> pk["パケット"]
    etl --> ev["ETWイベント"]
    pk -->|etl2pcapng| pc["pcapngへ変換"]
    pc --> ws["Wiresharkで読む"]
    pc -.-> pid["プロセスIDがコメントに残る"]
    ev -.-> no["pcapngへは変換されない"]
    no --> alt["convertやWPAで読む"]

図8: ETLのうちパケットはpcapngへ変換して読み、ETWイベントは別の手段で読む。

5. Wiresharkでの読み方入門 ── 表示フィルタとTCP解析

解析は、対象を絞る→TCPの形を確認する→必要に応じて会話全体を見るという順で進めます。まずpcapngを開き、表示フィルタでノイズを削ります。¹²¹³

表示フィルタで、読む対象を絞る

tcp.analysis.*は、WiresharkがTCPのシーケンス番号を追跡して自動判定してくれる解析フラグです。再送、重複ACK、順序入れ替わり、ZeroWindowなどが機械的に拾えるため、最初にtcp.analysis.flagsを打って「問題っぽい箇所」を一覧するのが読み始めの定石です。¹³

タイムアウトを4つの確認点に分ける

tcp.analysis.flags で当たりを付けたら、次の順序で確認します。特に再送は「ACKが返っていない」という観測であり、片側だけで行きと帰りのどちらが失われたかを決めないことが重要です。

1. 接続は成立したか: SYN・SYN/ACK・ACK

3ウェイハンドシェイクは成立したか。SYN→SYN/ACK→ACKの3発が揃っているか。SYNを繰り返しているのに応答がなければ、相手に届いていないか、途中で黙って破棄されています(ファイアウォールの典型パターン)。

2. 強制切断されたか: RSTの時点と送信元

RSTはどちらから飛んだか。SYNに対して即RSTなら宛先ポートで誰も待ち受けていない状態、確立後のRSTならどちらかが接続を強制切断した状態です。RSTの送信元IPが「どちらが切ったか」の直接証拠になります。

3. ACKが返っているか: 再送の継続

再送が続いていないか。同じセグメントの再送が繰り返されているのは、送信側に確認応答(ACK)が返ってきていないサインです。行きのデータが失われたのか、帰りのACKが失われたのかは、片側のキャプチャだけでは確定できません(だからこそ次章の「両側で採る」が効きます)。再送とタイムアウトの深掘りは「TCP再送で産業用カメラ通信が止まる原因と切り分け」で詳しく扱っています。

4. 受信側が詰まっていないか: ZeroWindow

ZeroWindowが出ていないか。受信側アプリがソケットからデータを読み出しておらず、受信バッファが満杯になっているサインです。ネットワークではなく受信側アプリの設計(「TCPでSendした単位ごとにReceiveできるという誤解」)を疑う根拠になります。

flowchart TB
    accTitle: タイムアウト調査で探す形の順序
    accDescr: 3ウェイハンドシェイクの成立、RSTの有無と送信元、再送の継続、ZeroWindowの順に確認して原因の当たりを付ける流れ
    hs{"SYNに応答が返った?"} -->|いいえ| ng["届かず破棄の疑い（FWの典型）"]
    hs -->|はい| rs{"RSTが飛んでいる?"}
    rs -->|はい| who["RSTの送信元が切った側"]
    rs -->|いいえ| rt{"再送が続いている?"}
    rt -->|はい| ack["ACKが返っていないサイン"]
    rt -->|いいえ| zw{"ZeroWindowが出ている?"}
    zw -->|はい| app["受信アプリが読んでいないサイン"]

図9: ハンドシェイク、RST、再送、ZeroWindowの順に形を探すと、次に調べる場所が絞れる。

通信が多いときは、統計で俯瞰してから読む

1パケットずつ読む前に、統計で目的の会話と時間帯を探す方法も有効です。

flowchart TB
    accTitle: 統計で俯瞰してから会話を絞り込む
    accDescr: Conversationsでどの通信がいつどれだけ話したかを一覧して目的の会話を特定し、I/O Graphで無音になった時間帯を掴み、対象の会話だけをフィルタしてTCPストリームで通し読みする流れを示す
    ov["統計で全体を俯瞰"] --> cv["Conversationsで会話一覧"]
    ov --> io["入出力グラフで流量を見る"]
    cv --> flt["目的の会話だけフィルタ"]
    io -.-> mute["無音になった時刻が分かる"]
    flt --> fs["TCPストリームで通し読み"]

図10: 1パケットずつ読む前に統計で俯瞰し、目的の会話に絞ってから通し読みする。

6. ループバック通信の罠 ── localhost宛はNICを通らない

同じPC内のアプリ同士の通信 ── たとえば業務アプリからlocalhost:8080の中間サービスへの接続 ── を調べようとして、「Wiresharkに何も出ない」で詰まるのは定番の罠です。

原因ははっきりしています。localhost(127.0.0.1)宛の通信は物理NICを通らず、OS内部のループバック経路で折り返されるためです。物理アダプタを対象にした通常のキャプチャには、最初から現れません。⁹

flowchart TB
    accTitle: localhost宛の通信がキャプチャに映らない理由
    accDescr: localhost宛の通信は物理NICを通らずOS内部のループバック経路で折り返されるため、物理アダプタ対象の通常のキャプチャには現れないことを示す
    app["アプリ"] --> stack["ネットワークスタック"]
    stack -->|外部宛| nic["物理NIC"]
    nic --> seen["通常のキャプチャに映る"]
    stack -->|localhost宛| lo["OS内部で折り返し"]
    lo -.-> miss["通常のキャプチャには映らない"]
    lo -.-> alt["Npcapループバックかpktmonで採る"]

図11: localhost宛はNICの手前で折り返されるため、物理アダプタのキャプチャには最初から現れない。

採取方法をループバック経路に合わせる

対処は2通りです。

• Wiresharkで採る場合: Npcapが提供する「Adapter for loopback traffic capture」をキャプチャ対象に選びます。Windows版Wireshark(3.0以降)のインストーラーにはNpcapが同梱されているので、Wiresharkが入っている環境なら追加作業なしで使えます。⁹
• 標準ツールで採る場合: pktmonはNICの外側ではなくネットワークスタック内部の複数地点で採取するため⁵、ループバック通信の観測にも使えます。確実を期すなら、本番の再現待ちを仕掛ける前にpktmon start -c -m real-timeのリアルタイム表示で、目的のループバック通信が実際に見えることをその環境で確かめてください。

アドレスの指定でも、2つの取り違えがある

localhostが指すのは127.0.0.1とは限らない

「localhost」はIPv6の::1に解決されることがあります。アプリはIPv6の::1に接続しているのに、調べる側が127.0.0.1(IPv4)だけを見ていて「通信がない」と誤断するパターンです。表示フィルタはip.addr == 127.0.0.1 || ipv6.addr == ::1のように両方張るか、アプリの接続先設定をアドレスで明示します。⁹

自分の実IPを指定しても、物理NICを通るとは限らない

自分自身の実IP宛の通信も、線には出ません。同じPCの192.168.10.5から192.168.10.5宛に接続する場合、宛先が実IPでもOS内部で折り返されます。「実IPを指定しているからNICを通るはず」とは限らない、と覚えておいてください。

flowchart TB
    accTitle: localhostがIPv6に解決される取り違え
    accDescr: アプリのlocalhostはIPv6の::1に解決されて接続していることがあり、調べる側が127.0.0.1だけを見ていると通信がないと誤断するため、表示フィルタを両方に張るか接続先をアドレスで明示して確認することを示す
    app["アプリがlocalhostへ接続"] --> v6["実際は::1（IPv6）に解決"]
    look["調べる側は127.0.0.1だけ見る"] --> none["画面に何も出ない"]
    v6 --> none
    none --> fix1["両アドレスにフィルタを張る"]
    none --> fix2["接続先をアドレスで明示"]

図12: localhostが::1に解決され、127.0.0.1だけを見て「通信がない」と誤断する取り違えに注意する。

7. どこで採るか ── 片側か、両側か、時刻同期

片側で得られるのは、その採取点から見えた事実です。まず全体像を見るのか、行きと帰りのどちらで通信が消えたかまで確かめるのかで、採取場所を選びます。

クライアント側で再送が続いていても、片側だけでは次の二つを区別できません。

• 送ったパケットが、サーバーに届くまでに消えた。
• パケットはサーバーに届いたが、応答が帰り道で消えた。

両側で採って突き合わせると、「クライアントは送った・サーバーには届いていない」のように、どちらが黙ったかが確定します。責任分界(アプリ・OS・ネットワーク機器・相手先)を確定させたい局面では、最初から両側採取を段取りします。

flowchart TB
    accTitle: 片側採取と両側採取で分かること
    accDescr: 片側のキャプチャでは行きのパケットが消えたのか帰りの応答が消えたのか区別できず、両側で採って突き合わせるとどちらが黙ったかが確定することを示す
    one["片側のみで採取"] --> fact["自分の位置から見えた事実だけ"]
    fact --> und["行きが消えたか帰りが消えたか区別できない"]
    both["両側で同時に採取"] --> mt["突き合わせ"]
    mt --> fix["どちらが黙ったかが確定"]
    mt -.-> pre["前提は両マシンの時刻同期"]

図13: 片側では見えた事実しか分からず、両側の突き合わせで初めて責任分界が確定する。

7.1. 突き合わせの前提は時刻同期

両側のキャプチャを突き合わせるには、両マシンの時計が揃っている必要があります。採取を始める前に、時刻のずれを確認・記録しておきます。

:: 時刻同期の状態(同期先・最終同期時刻)を確認
w32tm /query /status

:: 相手サーバーとの時刻差を実測する(5サンプル)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchartは自分と相手コンピューターの時刻オフセットを表示するコマンドで、突き合わせ時に「サーバー側の時刻は+0.8秒ずれていた」と補正する根拠になります。¹⁴ ずれが大きい環境では、先に時刻同期を直してから採取するのが結局近道です。

flowchart TB
    accTitle: 突き合わせ前の時刻差の確認手順
    accDescr: w32tmで自分の時刻同期の状態を確認し、stripchartで相手サーバーとの時刻差を実測して記録し、突き合わせのときにそのずれを補正の根拠として使う流れと、ずれが大きい環境では先に時刻同期を直してから採取することを示す
    st["queryで同期状態を確認"] --> mc["stripchartで時刻差を実測"]
    mc --> rc["ずれを記録しておく"]
    rc --> use["突き合わせ時に補正の根拠"]
    mc -.-> big["ずれが大きければ先に同期を直す"]

図14: 採取の前に時刻差を実測して記録し、突き合わせ時の補正の根拠にする。

7.2. 「いつ起きるか分からない」にはリングバッファ

再現条件が不明な事象は、リングバッファで採りっぱなしにして、発生したら止めるのが基本です。

• pktmon: 既定がcircularモードです。--file-sizeで上限(MB)を指定し、古いパケットから上書きされます。⁶
• netsh trace: maxSize=1024 filemode=circularのように指定します。⁷
• Wireshark: [キャプチャ]→[オプション]→[出力]で「複数ファイル+リングバッファ」を構成できます。ファイルサイズや時間で切り替えながら最新N個だけを保持するため、ディスク使用量に上限を設けたまま長時間回せます。¹⁵

容量だけでなく、発生後の止め方まで決める

いずれの場合も、事象が起きたら「発生時刻をメモしてから」採取を止める運用を、現場の担当者と共有しておいてください。リングバッファは待てば待つほど過去が消えるので、発生から停止までの手順が長いと肝心の区間が上書きされます。

flowchart TB
    accTitle: リングバッファでの待ち構え運用
    accDescr: 再現条件が不明な事象はリングバッファで採りっぱなしにして待ち、事象が発生したら発生時刻をメモしてから速やかに停止する運用と、停止が遅れると古いパケットから上書きされて肝心の区間が消えることを示す
    st["リングバッファで採取開始"] --> wt["採りっぱなしで待つ"]
    wt --> ev["事象が発生"]
    ev --> memo["発生時刻をメモ"]
    memo --> sp["速やかに停止"]
    wt -.-> ow["古いパケットから上書き"]
    ow -.-> late["停止が遅れると肝心の区間が消える"]

図15: リングバッファは待つほど過去が消えるため、発生時刻をメモしたら速やかに止める。

8. TLSで中身が見えない問題 ── 見えなくても分かること

復号する前に、通信の骨格を確認する

いまどきの業務通信の多くはTLS(HTTPS)です。「暗号化されているならキャプチャしても無駄では」と思われがちですが、タイムアウト調査で知りたいことの大半は、暗号化されたままでも分かります。

• TCP接続が確立したか(3ウェイハンドシェイク)
• TLSハンドシェイクがどこまで進んだか ── ClientHelloに対してServerHelloが返ったか、ハンドシェイク中にRSTやアラートで切れたか
• ClientHelloに載る接続先ホスト名(SNI)や、ネゴシエートされたTLSバージョン
• 確立後、どちらが送信を止めたか。無応答の位置、再送、RST、正常なクローズ(FIN)か

つまり「つながらない」「途中で切れる」「応答が返らない」の切り分けに、中身の復号はほとんど要りません。暗号化で失われるのは“何を話したか”であって、“誰がいつ黙ったか”は残るからです。

flowchart TB
    accTitle: TLSのキャプチャで見えることと見えないこと
    accDescr: 暗号化で見えなくなるのはアプリケーションデータの中身だけで、TCP接続の確立、TLSハンドシェイクの成否、SNIやTLSバージョン、RSTやどちらが黙ったかは暗号化されたままでも分かることを示す
    tls["TLS通信のキャプチャ"] --> vis["見えること"]
    tls --> hid["見えないこと"]
    vis --> v1["TCP接続の確立"]
    vis --> v2["TLS成否とSNI"]
    vis --> v3["RSTとどちらが黙ったか"]
    hid --> h1["アプリデータの中身"]

図16: 暗号化で失われるのは中身だけで、通信の骨格はTLSのままでも読める。

中身が必要な場合だけ、復号の可否を確認する

それでも中身が必要な場合、WiresharkにはSSLKEYLOGFILE環境変数で書き出したセッション鍵を使ってTLSを復号する仕組みがあります。ただし対応するのはFirefox・Chrome・Chromium系EdgeのブラウザやOpenSSL系のライブラリなど一部の実装で、Windows標準のSChannel(WinHTTPやWinINETを使うアプリ)はこの仕組みに対応していません。¹⁰ セッション鍵がファイルに書き出される=そのファイルを手にした者が通信をすべて復号できる、という性質上、本番環境で使う手段ではなく、開発環境での再現・デバッグ用と位置づけるべきです。

flowchart TB
    accTitle: SSLKEYLOGFILEによる復号の仕組みと制約
    accDescr: SSLKEYLOGFILEで書き出したセッション鍵を使うとWiresharkでTLSを復号できるが、対応するのはFirefoxやChrome系など一部の実装でSChannelは非対応であり、鍵ファイルを手にした者は通信を復号できるため開発環境限定の手段であることを示す
    env["SSLKEYLOGFILEを設定"] --> key["セッション鍵をファイルへ書き出し"]
    key --> ws["Wiresharkで復号して読む"]
    key -.-> risk["鍵を持つ者は全部復号できる"]
    risk -.-> dev["開発環境限定と位置づける"]
    env -.-> sup["対応は一部のTLS実装のみ"]
    sup -.-> sch["SChannelは非対応"]

図17: セッション鍵の書き出しで復号できるが、対応実装が限られ、鍵の性質上開発環境限定の手段。

なお、社内プロキシ経由の通信では、キャプチャに写る宛先がプロキシサーバーになり、CONNECTトンネルの中をTLSが流れる形になります。そもそもアプリがどのプロキシへ向かうのかという手前の問題は、同日公開の姉妹記事「社内プロキシとWindowsアプリ ── WinINET・WinHTTP・.NETのプロキシ解決を整理する」で整理しています。

9. アプリログとの突き合わせ ── 時刻を同じ軸に並べる

キャプチャ単体で結論が出ることは、実はあまりありません。実務の決め手は、アプリログの1行とパケットの1往復を、同じ時間軸の上に並べることです。

ログの1行を、パケットの観測事実に置き換える

まず例外が出た時刻から、通信を始めた区間を探します。

手順1: 例外時刻とタイムアウト値から、開始時刻を探す

アプリログから事象の時刻を特定します(例: 10:23:41にタイムアウト例外)。タイムアウト値が30秒なら、開始は10:23:11ごろのはずです。

手順2: Wiresharkを日時表示にし、該当区間へ絞る

Wiresharkの時刻表示を[表示]→[時刻表示形式]→[日時]に切り替え、該当区間を表示フィルタで絞ります(frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00"のように時刻でも絞れます)。

手順3: ハンドシェイク・RST・再送・ZeroWindowを確認する

その区間で、5章の順序(ハンドシェイク→RST→再送→ZeroWindow)を確認します。「ログのタイムアウト時刻の30秒前にSYNを送り、以後SYNの再送のみ」まで突き合わせられれば、ログの“タイムアウト”が「この採取点には応答が一切返ってきていない」という観測事実に置き換わります(SYNが相手に届いていないのか、応答のSYN/ACKが帰り道で失われたのかは、この採取点だけでは確定できません。確定させたい場合はサーバー側の採取と突き合わせます)。

手順4: 時刻差とタイムゾーンを補正する

キャプチャの時刻とログの時刻のずれ(7.1節で測った時刻差、ログのタイムゾーン表記)を必ず補正します。突き合わせの誤差が数秒あると、別の通信を犯人にしてしまいます。

flowchart TB
    accTitle: アプリログとパケットの突き合わせ手順
    accDescr: アプリログから事象の時刻を特定し、タイムアウト値から開始時刻を逆算し、Wiresharkで該当区間を絞って形を順に確認し、時刻のずれを補正して同じ時間軸に並べる手順を示す
    lg["1. ログで事象の時刻を特定"] --> rev["タイムアウト値から開始を逆算"]
    rev --> flt["2. 該当区間を表示フィルタで絞る"]
    flt --> chk["3. 5章の順序で形を確認"]
    chk --> adj["4. 時刻のずれを補正"]
    adj --> done["ログの一言が観測事実に変わる"]

図18: ログの時刻から区間を絞り、形を確認し、時刻差を補正して同じ軸に並べる。

第三者へ渡す前に、必要な会話だけを取り出す

調査結果を第三者(ベンダー、回線事業者、顧客のネットワーク担当)へ渡すときは、フィルタでノイズを削ってから渡すのが礼儀であり、安全策でもあります。Wiresharkで対象の会話だけを表示フィルタで絞り、[ファイル]→[指定パケットのエクスポート]で「表示されているパケットのみ」を保存すれば、必要な範囲だけの小さなpcapngを作れます。

採取前から、機密情報の保管と削除を決めておく

キャプチャファイルには通信内容そのものが入ります。平文プロトコルの認証情報、HTTPのCookieやAPIキー、メールや帳票の中身、個人情報が含まれ得ます。次の3点を採取手順とセットで決めておいてください。

• 必要最小限の採取: 採取前フィルタ(3章・4章)で対象を絞り、期間も最小にする。「とりあえず全部」を顧客環境でやらない
• 渡す前の絞り込み: 対象の会話だけをエクスポートし、無関係な第三者の通信を含めない。機密部分が残る場合はマスキングや別手段を宛先と合意する
• 保管と削除: 採取ファイルの保管場所・期限・削除を決め、調査完了後に消す

flowchart TB
    accTitle: キャプチャファイルを渡す前の3つの決めごと
    accDescr: キャプチャには通信内容そのものが入るため、採取前フィルタと期間で必要最小限に絞り、渡す前に対象の会話だけを抽出して無関係な通信を含めず、保管場所と期限を決めて調査完了後に削除するという3点を採取手順とセットで決めることを示す
    cap["キャプチャには通信内容が入る"] --> p1["採取は必要最小限に"]
    cap --> p2["渡す前に対象だけ抽出"]
    cap --> p3["保管期限を決めて削除"]
    p2 -.-> exp["表示フィルタで絞ってエクスポート"]

図19: 最小限の採取、渡す前の絞り込み、保管と削除の3点を採取手順とセットで決める。

10. まとめ

• アプリログの「タイムアウト」の一段下には、実際に線を流れたパケットという事実があります。SYNに応答がないのか、RSTで切られたのか、再送が続いたのか、ZeroWindowなのかで、次に調べる場所が変わります。
• Wiresharkを入れられない現場でも、Windows標準のpktmonとnetsh traceで採取できます。採るのは標準ツール、読むのは手元のWireshark、という分担が基本形です。
• pktmonはフィルタ登録→pktmon start --capture→pktmon stop→pktmon etl2pcapの4手順。既定では128バイトで切り詰められるため、中身まで読むなら--pkt-size 0を忘れずに。ドロップ箇所と理由が分かるのはpktmonだけの強みです。
• netsh traceはシナリオでETWプロバイダーを束ねて採れ、persistent=yesで再起動をまたげます。ETLはetl2pcapngでpcapngへ変換して読みます。
• Wiresharkではtcp.analysis.flagsから読み始め、ハンドシェイク・RST・再送・ZeroWindowの順で形を探します。ConversationsとI/O Graphで俯瞰してから絞ると速い。
• localhost宛はNICを通らないため普通には採れません。Npcapのループバックアダプタか、pktmonのスタック内採取を使います。
• 両側で採って突き合わせれば「どちらが黙ったか」が確定します。その前提は時刻同期(w32tm)です。再現条件不明の事象はリングバッファで待ち構えます。
• TLSでも通信の骨格は見えます。復号(SSLKEYLOGFILE)は開発環境限定の手段と位置づけ、キャプチャファイル自体も機密として最小採取・絞り込み・削除まで運用に組み込んでください。

パケットキャプチャは「ネットワーク専門家の道具」と思われがちですが、実際にはアプリのログと突き合わせて初めて意味が出る、アプリ側の調査道具です。次に“タイムアウト”の一言で調査が止まったら、その一段下を見にいってください。

関連記事

• TCP再送で産業用カメラ通信が止まる原因と切り分け
• TCPでSendした単位ごとにReceiveできるという誤解 ── バイトストリームとして扱うための受信設計
• OSI参照モデルをはっきりイメージする ── HTTPリクエスト1個を7層に解剖する
• Process Monitor(ProcMon)実践ガイド ── 「設定が読まれない」「ACCESS DENIED」を10分で特定する
• Windowsファイアウォールと業務アプリ ── 受信規則はインストーラーで登録する
• 社内プロキシとWindowsアプリ ── WinINET・WinHTTP・.NETのプロキシ解決を整理する

関連する相談領域

合同会社小村ソフトでは、「業務アプリの通信が時々失敗するが原因が分からない」「顧客環境でだけ起きる接続エラーを切り分けたい」といった通信起点の不具合調査を扱っています。パケットキャプチャの採取設計(どこで・何を・どれだけ採るか)から、Wiresharkでの解析、アプリログとの突き合わせ、アプリ側の修正までを一続きで対応します。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Wiresharkをインストールできない顧客サーバーで、パケットキャプチャを採るにはどうすればいいですか？

Windows標準のpktmonまたはnetsh traceを使えば、ソフトの追加インストールなしで採取できます。pktmonなら管理者権限のターミナルでフィルタを登録し、pktmon start --captureで採取を開始、pktmon stopで停止します。採れたETLファイルはpktmon etl2pcapでpcapng形式に変換できるので、解析は自社に持ち帰った手元のWiresharkで行えます。「採るのは標準ツール、読むのはWireshark」という分担が、インストール制約のある現場での基本形です。

pktmonとnetsh traceはどちらを使うべきですか？

pktmonが使えるOS(Windows 10 / Windows Server 2019以降)なら、まずpktmonをおすすめします。コマンドが単純で、ネットワークスタックのどのコンポーネントでパケットが破棄されたか(ドロップ理由)まで確認でき、pcapng変換も単体で完結するからです。netsh traceが有利なのは、pktmonが載っていない古いOSで採る場合、シナリオという形でWindowsコンポーネントのETWイベントもまとめて採りたい場合、persistent=yesで再起動をまたいで採取したい場合です。Microsoftのトラブルシューティング資料も、まずpktmon、足りなければnetsh traceという順序を案内しています。

localhost(127.0.0.1)宛の通信がWiresharkに表示されないのはなぜですか？

localhost宛の通信は物理NICを通らず、OS内部のループバック経路で折り返されるためです。物理アダプタを対象にした通常のキャプチャには最初から現れません。WiresharkではNpcapが提供する「Adapter for loopback traffic capture」を選ぶとループバック通信を採取できます。pktmonはネットワークスタック内部で採取するため、ループバック通信の観測にも使えます。また「localhost」がIPv6の::1に解決されて、127.0.0.1のつもりで見ていた画面に何も出ない、という取り違えもよくあるので、アドレスを明示して確認してください。

HTTPS(TLS)の通信は、パケットキャプチャで中身が見えますか？

アプリケーションデータの中身は暗号化されていて見えません。ただし、TCP接続の確立と切断、TLSハンドシェイクの成否、RSTによる切断、どちらが応答を止めたかといった「通信の骨格」は暗号化されていても分かるため、タイムアウト調査の大半はTLSのままで進められます。中身まで必要な場合はSSLKEYLOGFILEによる復号という手段がありますが、対応するのはFirefoxやChrome系など一部のTLS実装で、Windows標準のSChannelは非対応です。秘密鍵情報を書き出す仕組みなので、使うとしても開発環境限定と考えてください。

採取したキャプチャファイルを、社外のサポート窓口に送っても大丈夫ですか？

そのまま送るのは危険です。キャプチャには通信内容そのものが入っており、平文プロトコルの認証情報、Cookie、APIキー、個人情報が含まれ得ます。まず採取の段階でフィルタと期間を絞って必要最小限にし、渡す前にWiresharkの表示フィルタで対象通信だけを抽出してエクスポートしてください。それでも残る内容は宛先と相談のうえ、機密部分の扱い(マスキング、別手段での提供)を決めてから渡すべきです。採取ファイルの保管期限と削除も、あらかじめ決めておくことをおすすめします。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。