ウェブページを読み込んだり、オンラインでデータを送信したりするたびに、デバイスは通信の信頼性を維持するために伝送制御プロトコル（TCP）接続を確立します。これらの接続は通常、3ウェイハンドシェイクで始まり、FINフラグを使用した正常な終了で終了しますが、TCPリセット（RST）によって突然終了する場合もあります。
TCP RSTは、標準的な切断プロセスに従わずに、接続を即座に終了するために一方から送信されるセグメントです。これは、ブラウザのタブを閉じるなどの通常の理由だけでなく、ネットワークエラー、設定ミス、攻撃などの異常な理由でも発生する可能性があります。
このガイドでは、TCP接続の仕組み、リセットが発生する理由、そして正常な動作と潜在的な問題を区別する方法について説明します。また、リセットを診断し、攻撃パターンを特定し、接続を健全に保つための簡単な方法も学びます。
TL; DR： TCP リセットは即時の接続終了であり、ネットワークが正常であるか、誤って構成されているか、または攻撃を受けているかを示すことができます。
TCP リセット (RST) は、接続を即座に終了します。これは意図的に終了する場合 (閉じたポートへのトラフィックを拒否するなど) もありますが、タイムアウト、アプリケーションのクラッシュ、悪意のある干渉などが原因である場合もあります。
早期のリセットは通常、ポートの閉鎖やファイアウォールの拒否を示していますが、セッション中のリセットはアプリのクラッシュ、ポリシーのドロップ、またはユーザーのキャンセルを示唆しています。
頻繁または不規則な RST は、不正なルーティング、プロキシ干渉、または意図的な改ざん (RST フラッドまたはインジェクション攻撃) などの問題を示している可能性があります。
ACL、レート制限、conntrack、アプリレベルのチューニングを組み合わせて、偽のリセットをブロックし、安定した安全な接続を維持します。
TCP接続の開始と終了の仕組み TCPは、インターネットにおける信頼性の高い通信の基盤です。ブラウザとウェブサーバー、アプリとAPIなど、2つのシステム間でデータが正確かつ順序通りに配信されることを保証します。
TCP接続はいくつかの主要な段階を経ます。ハンドシェイクから始まり、データ交換を経て、接続の終了で終了します。接続は正常に終了することもあれば、突然終了したり、単に応答を停止したりすることもあります。
つながりの始まり方 2つのデバイスがデータを交換するには、まず通信に合意する必要があります。この設定は3ウェイハンドシェイクと呼ばれ、以下の3つの簡単なステップで行われます。
SYN SYN は接続を開始し、クライアントの初期シーケンス番号を示すために使用されます。SYN-ACK サーバーは、SYN フラグと ACK フラグの両方が設定されたパケットで応答し、クライアントの要求を確認し、接続のサーバー側を開始します。ACK : クライアントは確認応答を返し、ハンドシェイクを完了します。 これらの手順を実行すると、両側でデータ転送の準備が整います。
つながりが終わる方法 TCP 接続が終了すると、主に次の 3 つの方法で閉じられます。
優雅な終結が訪れる（FIN）: 片側はFINフラグ付きのTCPセグメントを送信し、データ送信の完了を示します。もう片側はACKで応答し、準備ができたら自身のFINを送信します。最後のACKで4段階のプロセスが完了し、接続が完全に切断される前にすべてのデータが確認されます。突然のクローズが発生する (RST): RSTフラグは、接続が突然終了したことを意味します。多くの場合、エラー、クラッシュ、またはポートのブロックが原因です。保留中のデータは送信されず、セッションは停止します。 タイムアウト： 片側が応答を停止するとタイムアウトが発生します。クローズメッセージは交換されず、再試行が失敗するとセッションは終了します。 TCP RST の詳細を理解する TCP RST (リセット) は、TCP ヘッダー内の制御フラグであり、2 つのデバイスに TCP 接続を直ちに閉じるよう指示します。
これは、コンピューターが開いていないポートのメッセージを受信した場合や、アプリがすでに接続を閉じている場合など、一方が予期しないトラフィックを受信した場合に送信されます。
TCP RSTが送信されると、両側は直ちにデータの送信を停止します。接続は標準的なTCPティアダウン（FIN/ACK）を経ずに終了します。
TCP RSTが正常な場合 RSTパケットは、多くの場合、通常のTCP動作の一部です。このような場合、RSTパケットは未使用または無効な接続をクリーンアップするのに役立ちます。
一般的な例をいくつか見てみましょう。
クライアントが開いていないポートに接続しようとすると、ホストは TCP RST で応答します。
ページの読み込みが完了する前に、クライアント アプリケーション (ブラウザーなど) がブラウザー タブを閉じます。
接続がまだ開いている間に、アプリケーションがソケットを閉じるかクラッシュします。
ファイアウォールまたはプロキシは、アイドル状態、許可されていない、またはセキュリティ ポリシーに一致するセッションを強制的に終了するために RST を送信します。
これらはすべて正常であり、健全な接続を維持するのに役立ちます。
TCP RSTが正常でない場合 リセットが多すぎる場合、または不規則なタイミングでリセットが発生する場合は、問題が発生している可能性があります。
一般的なシナリオをいくつか示します。
ファイアウォールやセキュリティ ツールは、接続をブロックまたは切断するために RST を挿入します。
ルーティングまたは NAT ルールの構成が誤っていると、パケットがコンテキスト外で受信されたり間違ったエンドポイントで受信されたりした場合に予期しない RST が発生する可能性があります。
攻撃者は、実際の接続を妨害するために偽の RST を送信します。
アプリまたはシステムが接続を不適切に、または早すぎるタイミングで閉じます。
TCPリセットが発生する理由: 接続ステージによる診断 TCP 接続がリセットされた理由を知るには、それがいつ発生したかを調べることが最も効果的です。
TCP セッションの各段階では、リセットの原因が通常のクリーンアップなのか、セットアップの問題なのか、ネットワークの干渉なのかについての手がかりが得られます。
リセットが発生する主な段階と、それが通常何を意味するかを以下に示します。
SYN後（ハンドシェイク中） Post-SYN リセットは、TCP 3 ウェイ ハンドシェイク中、つまりクライアントが SYN を送信した後、接続が完全に確立される前に発生します。
何が起こっているかを理解するには、次の点に注目してください。
宛先ポートの閉鎖、スキャンの試行、ファイアウォールの拒否などの兆候
開いていないポート
ハンドシェイクを完了しない偽装トラフィック
サーバーまたはファイアウォールは、不正な接続や予期しない接続の試みに応答してRSTを送信します。
原因を確認するには、宛先ポートが開いており、アプリケーションが実際にリッスンしているかどうかを確認してください。ファイアウォールまたは侵入検知システムのログで、ブロックされたSYNパケットがないか確認してください。ランダムなIPアドレスから多数のリセットが送信されている場合は、実際の接続試行ではなく、ネットワークスキャンである可能性があります。
パケット キャプチャでは、リセットは通常、クライアントからの ACK がない SYN-ACK の後に発生し、多くの場合、わずか数ミリ秒の間隔で発生します。
ACK後（ハンドシェイク直後） ACK後のリセットは、3ウェイハンドシェイクが完了した後、アプリケーションデータが交換される前に発生します。これは、セットアップ直後、通信が実際に開始される前に、何らかの理由で接続が中断されたことを意味します。
これは次のような場合に発生する可能性があります:
ミドルボックス（ファイアウォール、プロキシ、フィルタ）がポリシーによってセッションをドロップする
TLS セットアップ中の SNI 不一致などにより、アプリケーションまたはサービスが早期に中止される
キャリアレベルのトラフィックシェイプまたは接続を妨害する「ゼロレーティング」動作
原因を確認するには、サーバーまたはプロキシのログでポリシーエラーまたはTLSエラーがないか確認してください。また、リセットを発生させている可能性のあるミドルボックスやCDNを経由したパスを追跡することもできます。
パケットキャプチャを確認すると、ACKの直後にリセットが発生し、その後にデータは発生しません。多くの場合、TTLが異なるため、ミドルボックスの干渉が疑われます。
PSH後（最初のデータパケット後） PSH後リセットは、接続が確立され、アプリケーション層のデータ（HTTPリクエストなど）の送受信が開始された後に発生します。例えば、クライアントが最初のHTTPリクエストを送信した後などです。このタイプのリセットは通常、アクティブな通信中にセッションが中断されたことを示します。
何が起こっているかを理解するには、次の点に注目してください。
ユーザーがタブを閉じたり、転送中にリクエストをキャンセルしたりした場合など、クライアントアプリケーション（ブラウザなど）が接続を中止する
接続がまだ開いている間にアプリケーションがクラッシュしたり、強制的にシャットダウンしたりした
ウェブアプリケーションファイアウォール（WAF）や侵入防止システム（IPS）などのセキュリティシステムが偽造リセットを挿入した
原因を確認するには、クライアントのアクション（ユーザーのキャンセルやタイムアウトなど）とサーバーログでアプリのクラッシュや再起動が発生していないか確認してください。パケットキャプチャ（pcap）をチェックして、ミドルボックスやセキュリティシステムがトラフィックフローにリセットを挿入していないか確認してください。
パケット トレースでは、リセットは PSH/ACK の後に続くことが多く、同一の ACK 番号または突然の TTL の変更とともに現れることがあります。これらは両方とも改ざんの兆候です。
後ほど（数パケット後） いくつかのデータ パケットが交換された後に発生するリセットは、多くの場合、アプリケーション レベルの問題またはユーザー主導の動作を示しています。
何が起こっているかを理解するには、次の点に注目してください。
ページの再読み込み、リクエストのキャンセル、ウェブサイトからの離脱などの手動のユーザーアクション
アプリケーションのタイムアウト、再試行、またはロジックエラーにより、セッションが早期に終了する
短命な接続を開始し、すぐにリセットするネットワークスキャナまたは監視ツール
原因を確認するには、データバーストとリセットのタイミングを比較し、アプリケーションログでタイムアウトや再試行イベントがないか確認してください。同じIPアドレスから短いセッションが繰り返し発生している場合は、自動スキャンまたは監視アクティビティが発生している可能性があります。
パケット トレースでは、リセットは通常、複数のデータ パケットの後に表示され、一貫した IP ID またはウィンドウ サイズで短いバーストで繰り返されることがあります。
トラブルシューティングプレイブック：症状から根本原因まで TCP リセットの数が多くなり始めたら、次にすべき最善のステップは、それらをキャプチャして、実際に何が起こっているかを解釈することです。
それでは、リセットをトレースし、その意味を理解し、問題の発生箇所を特定するための簡単な方法をいくつか見ていきましょう。
クイックパケットキャプチャフィルター 何が起こっているかを確認する最も速い方法は、RSTパケットを直接キャプチャすることです。これらのリセットをキャプチャして分析するには、主に2つのツールを使用できます。
tcpdumpを使用する場合
Wiresharkで
両方の使い方を見てみましょう。
tcpdumpの使用
# Show all TCP resets
tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0'
# Capture only resets from clients
tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0 and src port < 1024'
# Capture resets to a specific port
tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0 and dst port 443'
# Capture resets on the loopback interface
tcpdump -i lo -n -v 'tcp[tcpflags] & (tcp-rst) != 0'
メイン インターフェイスに何も表示されない場合は、ループバック インターフェイス (-i lo) を忘れずに確認してください。
多くのローカル サービスは内部で通信しており、そこで隠れたリセットが発生することがよくあります。
Wiresharkの使用
Wireshark では、表示フィルターを使用します。
パターンを見つけやすくするために、Delta time列（パケット間の時間）を追加します。これにより、高速リセット（即時アボート）と遅延リセット（タイムアウトまたはユーザーアクション）を区別しやすくなります。
一般的なメッセージを解釈する TCP RSTをキャプチャしたら、誰がリセットを送信したか（クライアントまたはサーバー）、そしてセッションのどの段階で発生したかを確認します。最も一般的なメッセージ/パターンは次のとおりです。
TCP-RST-FROM-クライアント
TCP-RST-FROM-サーバー
同じIP、異なるポート
決定木 タイミングと動作に基づいて一般的な TCP リセットを解釈する簡単な方法を次に示します。
パターン 考えられる原因 次のステップ RSTはSYN-ACKの直後に現れる ミドルボックスポリシー、ポートブロック、ファイアウォール、プロキシ、サーバーによる接続拒否（ポリシーまたは設定ミスなど）、またはバックエンドの誤ルーティング ファイアウォール ルール、プロキシの動作、または TLS SNI ポリシーを確認します。 リクエストから約30秒後に応答がない状態でRSTが表示される アイドル タイムアウト、クライアントの再試行、またはアプリレベルの非アクティブによる切断 クライアントの再試行ロジックまたはサーバーのキープアライブ設定を確認します。 多数のIPからの多数のPost-SYNリセット ポートスキャナー、インターネット全体のプローブ、またはノイズの多いボットネット エッジでブロックまたはレート制限します。 RSTは最初のPSH（データ）の直後に現れる クライアントがリクエストを中止したか、アプリ/サーバーがクラッシュしました アプリのログとクライアント セッションの動作を確認します。 RSTはセッションの後半に現れる 不安定なアプリロジックまたはユーザーのリロード アプリの再試行処理またはセッション タイムアウトを確認します。
より詳細なパケット検査を行う前に、この表を簡単なチェックリストとして使用できます。
認識すべき攻撃と改ざん TCPリセット（RST）パケットは通常の接続エラーではなく、攻撃や意図的な妨害によって発生することがあります。よくある攻撃パターンは次の2つです。
RST洪水
RST注射
パケットキャプチャでは似ているように見えますが、原因と対応はまったく異なります。
RSTフラッド RST フラッドは、攻撃者が大量の偽の TCP リセット パケットをターゲットに送信するサービス拒否 (DoS) 攻撃の一種です。
目的は、アクティブな接続を切断するか、大量の無効な TCP リセットを強制的に処理させてサーバーに過負荷をかけることです。
これらのパケットは多くの場合スプーフィング（攻撃者が送信元 IP アドレスを偽装）されるため、送信元別にフィルタリングすることが困難になります。
パケットキャプチャで表示される内容:
一致する SYN/ACK 履歴のない RST パケットが急増しました。
短期間で複数の宛先ポートまたはサービスをターゲットとするトラフィック。
シーケンス番号と確認応答番号は実際のセッションと一致しません。
応答方法は次のとおりです。
通常のトラフィックをブロックせずにフラッドを遅くするために、RST パケットのレートを制限します。
接続追跡 (conntrack) を使用すると、有効で確立されたセッションのみがリセットを送信できるようになります。
上流のDDoS緩和策（ISPベースまたはクラウドスクラビングなど）を有効にして、大量のRSTフラッドがインフラストラクチャに到達する前にフィルタリングします。
ヒント： 誤検知に注意してください。実際のアプリ、プロキシ、またはロード バランサーの中には、アイドル セッションを閉じるときにクイック RST を送信するものもあります。
RST注射 RST 注射は異なります。
ファイアウォールまたはミドルボックスは、何千ものパケットを送信する代わりに、単一の RST パケットを偽造して特定の接続を中断します。
この手法は、特に特定のコンテンツを検出した後、ネットワーク検閲（特定の Web サイトまたはオンライン コンテンツへのアクセスをロックまたは制限する）やトラフィック フィルタリングでよく使用されます。
これらの偽造リセットは、多くの場合、TLS ClientHello（ブラウザが安全なHTTPS接続を開始するために最初に送信するメッセージ）の直後に発生し、ドメイン名（SNI）が見える状態になります。このタイミングは、改ざんの確実な指標となります。
何を探すべきか：
偽造された RST または RST+ACK は、最初のデータ パケット (多くの場合 ClientHello) の直後に表示されます。
RST の TTL 値は、そのフロー内の通常のパケットと異なります (同じデバイスからのものではありません)。
ACK 番号は複数の RST 間で同一である可能性があります (明確な自動化パターン)。
確認方法は次のとおりです。
VPNまたは別のネットワーク経由で同じ接続をテストしてください。リセットが消えた場合は、干渉は元のパスにある可能性があります。
通常のパケットとリセット パケットの TTL (Time To Live) と IP ID 値を比較します。
これを軽減するには、次の操作を実行できます。
TLS 1.3 を Encrypted ClientHello (ECH) とともに使用すると、ドメイン名が仲介者から隠されます。
ローカル ミドルボックスをバイパスするには、暗号化された DNS (DoH または DoT) と VPN トンネルを試してください。
パターンベースの RST インジェクションを回避するには、ランダムなタイミングで接続を再試行します。
干渉を証明するために、一貫したリセット パターン (同じ TTL デルタまたは ACK 番号など) をログに記録して文書化します。
緩和マトリックス（どこで何が機能し、トレードオフがあるか） TCPリセットに対する万能な解決策はありません。ホストからISPまで、各制御層ごとに異なるツールとトレードオフが存在します。そこで、TCP RSTを克服するための一般的な方法をいくつか見ていきましょう。
アクセス制御リスト（ACL） アクセス制御リスト（ACL）は、ルーターやファイアウォールに適用されるルールセットで、IPアドレス、ポート、プロトコルの種類に基づいてトラフィックを許可または拒否します。ネットワークエッジでの使用に最適で、既知の不正トラフィックを早期にブロックします。
通常のトラフィックパターンがわかっている場合は、ACL を使用できます。例えば、クライアントやサーバーが固定の IP アドレス範囲からアクセスしている場合などです。
レートリミッター レートリミッターは、短時間に許可されるパケット、接続、またはセッションの量を制御します。これにより、突然のトラフィックバーストやRSTフラッドによるサーバーへの負荷を軽減できます。
ただし、レートリミッターの設定を厳しくしすぎると、通常のトラフィックの急増をブロックしてしまう可能性があります。そのため、レートリミッターは、リセットや接続の急増が頻繁に発生する場合にのみ使用してください。
ステートフルトラッキング（Conntrack） ステートフルトラッキング（conntrackとも呼ばれる）は、アクティブなTCPセッションをすべて記録します。各RSTパケットが実際に既存の接続に属しているかどうかを確認します。
これにより、偽造リセットや偽造リセットに対して非常に効果的です。適切に調整されていれば、ミスのリスクは低くなります。ただし、接続量が多い場合、トラッキングテーブルがオーバーフローし、接続が切断されたり、パフォーマンスが低下したりする可能性があります。
スプーフィング攻撃やフラッディング攻撃に直面した場合は、conntrack を使用できます。
異常検知または侵入検知システム（IDS） 異常検出システムまたは IDS ツールは、奇妙な RST タイミング、奇妙な TTL 値、または繰り返しの ACK 番号などの異常な動作がないかネットワーク トラフィックを監視します。
これらは、パケットを直接ブロックしていなくても、誰かが接続を改ざんしているかどうかを確認するのに役立ちます。
ここでは、システムのトレーニングの質に応じて、誤検知のリスクは中程度から高程度です。そのため、特に改ざんや検閲を証明するために、可視性と分析のためのデータが必要な場合に使用できます。
アップストリームスクラビングまたはDDoS防御 アップストリーム スクラビングとは、不正なパケットがユーザーに到達する前にフィルタリングする ISP またはクラウド プロバイダーを介してトラフィックを送信することを意味します。
これは、ボリューム型DDoS攻撃を受けている場合や、偽造RSTによるフラッド攻撃を受けている場合に非常に役立ちます。このような場合には、上流スクラビングを外部防御層として活用できます。
アプリレベルのバックオフとキープアライブの調整 アプリケーション層では、再試行タイマー、バックオフ時間、キープアライブ設定を構成することで、リセットをよりスムーズに処理できます。これによりリセットが停止するわけではありませんが、アプリによる過度な再接続試行やリソースの浪費を防ぎ、一時的な障害発生時のアプリ側の負荷を軽減できます。
結局のところ、エラーのリスクが低く、一時的なネットワーク障害が発生した場合でもアプリの安定性を維持するのに役立ちます。そのため、短時間の停止、ユーザーの切断、ミドルボックスの干渉などによってリセットが発生した場合にも使用できます。
自動スキャン vs. 人間の行動 TCPリセットは、必ずしも実際のユーザーや壊れたアプリから発生するわけではありません。多くのリセットは、インターネット経由でテストパケットを送信し、どのシステムやポートが開いているかを確認する自動スキャナーによって発生します。
これらのテストパケットはプローブと呼ばれます。これは、実際にデータを交換するのではなく、デバイスが応答するかどうかを確認するために送信される小さな接続試行です。
スキャナーの動作 自動スキャナーは毎秒数千ものプローブを送信します。そのトラフィックは高速で反復的であり、何に注意すべきかが分かれば簡単に見分けられます。
IP ID フィールドは、多くの場合、54321 (ZMap などのスキャナーで使用される) などの標準値に固定されます。
TCP ウィンドウ サイズは通常 65535 です。
ほとんどの接続は SYN ステージの直後に終了し、ハンドシェイクは完了しません。
プローブは短いバーストで到着し、さまざまなポートやサーバーにすぐに到達します。
実際のクライアント接続のようにランダム化されるのではなく、多くのプローブ間で送信元ポートが同じになることがよくあります。
これらの一貫したパターンにより、スキャン トラフィックは通常のユーザー アクティビティとは区別されます。
人間の交通はどのように異なるか 実際のユーザーやアプリからの接続は、より自然で多様な動作をします。ハンドシェイクを完了し、データを交換し、通常はFINまたは単一のRSTで接続を終了します。
タイミングとパケット サイズも異なるため、自動テストではなく実際のユーザー操作が示されます。
ネットワークを監視する TCP リセットは通常のインターネット トラフィックの一部ですが、頻繁または予期しない RST は、ネットワークで何が起こっているかについて多くのことを伝えます。
ユーザーがページを閉じるなど、リセットの中には無害なものもあります。一方、アプリケーションのクラッシュ、ネットワークのルーティングミス、接続の切断、アプリの設定ミス、さらには改ざんや攻撃など、より深刻な問題を示している場合もあります。
これらを理解する最良の方法は、注意深く観察することです。tcpdumpやWiresharkなどのツールを使って、リセットをいくつかキャプチャしてみましょう。RSTを送信した側を特定し、接続の確立とデータ交換のタイミングを観察しましょう。
時間が経つにつれて、これが基準となり、異常を発見するための基準となります。
リセットを常に監視し、そのパターンを理解することで、問題への対応から予測へと移行できます。こうして、強力で信頼性の高いネットワークが構築されます。
よくあるご質問
TCP と UDP の違いは何ですか?
TCPは接続を確立し、エンドポイント間で順序正しく信頼性の高いデータ配信を保証します。UDPはコネクションレスで高速ですが、パケットの到着や順序通りの到着を保証するものではありません。
ファイアウォールは TCP リセットを引き起こす可能性がありますか?
はい。ファイアウォールや侵入防止システム（IPS）、ディープ・パケット・インスペクション（DPI）ツールは、RSTパケットを送信して、不要なパターンに一致する接続やセキュリティルールに違反する接続をブロックできます。
ハーフオープン TCP 接続とは何ですか?
TCP ハーフオープン接続は、片側では接続がまだアクティブであると認識されているが、もう片側では接続プロセスが完了していないか、すでに閉じられている場合に発生します。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
