接続フラッピングによるクライアント禁止アラート

接続フラッピングによるクライアント禁止アラートは、EMQX Cloudがデフォルトのフラッピング保護を有効にしたことを示します。クライアントが異常な再接続ストームや悪意のある接続試行などで高頻度に接続と切断を繰り返す場合、EMQX Cloudはブローカーの安定性を保護するために自動的にそのクライアントIDをブラックリストに追加します。

• デフォルトルール：1分間に120回を超える接続試行があったクライアントIDはブラックリストに追加されます。ブラックリスト登録後60分間はブローカーへの再接続ができません。
• 手動復旧：正当な動作である場合は、アクセス制御 -> ブラックリストに移動し、該当のクライアントIDを手動で削除してください。

クライアントIDの競合と短い再接続間隔

症状

複数のクライアントが同じクライアントIDを使用すると、1つのオンライン接続を奪い合う状態になります。さらにクライアントSDKが100msなど非常に短い再接続間隔を使用している場合、クライアントは高速な接続・切断・再接続のループに入り、フラッピング保護が発動します。

デプロイメントログでは、同じクライアントIDがフラッピング関連のログに繰り返し登場し、その発信元IPアドレス（peername）が変化します。クライアントログでは、接続が即座に切断されたり乗っ取られたりする様子が確認できることもあります。

主な原因

• 複数のクライアントが同じクライアントIDを使用している。
• 自動再接続間隔が短すぎてバックオフがない。
• コピーされた設定やイメージにより複数のデバイスが同じクライアントIDを割り当てられている。

対応策

• デバイスのシリアル番号、ユーザーID、永続的なUUIDなど、グローバルに一意なクライアントIDを各クライアントに割り当てる。
• 再接続に指数的バックオフ（例：1秒、2秒、4秒）とジッターを導入する。
• 複数クライアントが同じクライアントIDを共有しているコピー設定やイメージを確認する。

ネットワーク品質の悪さによる頻繁な切断

症状

モバイル環境や弱く不安定、パケットロスの多いネットワークでは、キープアライブ失敗後にクライアントが繰り返し切断し即座に再接続を行い、フラッピング保護が発動することがあります。

この場合、クライアントのpeernameやIPアドレスは通常安定しており、切断は特定のネットワーク出口や時間帯に集中します。クライアントやゲートウェイのログにはタイムアウト、接続リセット、TLSハンドシェイク失敗などが記録されることがあります。モニタリングチャートでは接続数の変動や頻繁な切断が確認できます。

主な原因

• 不安定なネットワークリンクや地域的なネットワーク障害。
• NATやファイアウォールのアイドル接続タイムアウト。
• パケットロスによるキープアライブチェックの失敗。

対応策

• クライアントのキープアライブおよびタイムアウト値を適切に設定し、誤検知を防ぐ。
• NATタイムアウト、ロードバランサーのアイドル接続ポリシー、QoSおよびACL関連のパケットロスを調査する。
• ネットワーク不安定時の再接続ストームを防ぐため、再接続のバックオフを設定する。

クライアントアプリケーションの不具合

症状

接続ロジックの誤りや複数スレッド・プロセスでの接続生成により、同一クライアントIDから多数の接続試行が発生します。

1台のデバイスやプロセスのログで、通常よりはるかに多い同時接続試行が見られ、ネットワーク状況との強い相関はありません。

主な原因

• クライアントコードが重複接続を生成している。
• 複数のスレッドやプロセスが同じクライアントIDを使用している。
• 接続失敗後に無制限の高速リトライループに入っている。

対応策

• クライアント側で同期処理を追加し、同時に1つの接続ループのみがクライアントIDを使用するようにする。
• リトライレートを制限し、接続失敗後はバックオフを適用する。
• 認証失敗、認可失敗、不正なパラメータなどの重大なエラーの場合は高速リトライを停止し、まずエラーを報告する。

トラブルシューティング

1. EMQX Cloudコンソールにログインし、デプロイメントログを開き、エラータイプをクライアントに設定します。clientid、peername (IP:port)、存在する場合はusername、およびタイムスタンプを記録します。

2. モニター -> アラート -> アラート一覧に移動し、「接続フラッピングによるクライアント禁止」アラートを確認します。

3. モニター -> クライアントで該当のクライアントIDを検索し、接続状態や最近の動作（頻繁な接続・切断や発信元IPの変化など）を確認します。

4. アクセス制御 -> ブラックリストに移動し、クライアントIDがリストにあるか、残りのTTLを確認します。誤った設定で正当なトラフィックがブロックされている場合はエントリを削除してサービスを復旧し、重複クライアントIDや再接続バックオフの欠如など根本原因を修正してください。

5. 証拠に基づき問題を分類します：

   • 異なる接続が同じクライアントIDを繰り返し乗っ取っている場合は、クライアントID競合を調査します。
   • 問題が特定のネットワークや出口に集中している場合は、ネットワーク品質の悪さを調査します。
   • 特定のクライアントバージョンやデバイスモデルにのみ影響がある場合は、クライアントアプリケーションの不具合を調査します。

モニタリングと統計

モニター -> アラートでアラート発生頻度を確認します。デプロイメントログやモニターのタイムラインと比較し、問題が単一クライアントに限定されるのか多数のクライアントに影響するのかを判断します。

長期分析のためにデータ統合を通じてクライアイベントを記録し、以下が可能です：

• 指定期間内の各クライアントIDの接続・切断イベント数をカウントする。
• 外部ストレージや分析システムで禁止が最も多いクライアントIDや発信元IPアドレスを特定する。

フラッピング保護の推奨事項

• 本番環境で100msなど極端に短い再接続間隔を使用しないでください。弱く不安定なネットワークでは再接続ストームを引き起こし、クライアントがブラックリストに登録される可能性があります。
• アプリケーションで短期間に複数回の再接続が必要な場合は、ジッターを加えた指数的バックオフを使用してください。
• フラッピング保護の閾値やポリシーを調整する場合は、コンソールの設定を利用するか、EMQXテクニカルサポートに相談して評価を受けてください。