公式 ZIP を展開し、対象通信だけに絞ったフィルターを設定します。最初は小さな Lag 値を一つだけ有効にし、Start で観察、Stop で停止して基準状態へ戻ったことを確認します。
01
Clumsy を使う前にテスト目的を決める
検証を始める前に、対象アプリ、操作、期待する表示、許容時間、復旧条件を書き出します。例えば API 応答を300ミリ秒遅らせたとき、読み込み表示が現れ、入力内容が失われず、応答後に処理が完了するかを確認します。目的が具体的なら、障害が見つかったときに原因を追いやすくなります。複数の機能を同時に有効にすると、遅延、損失、帯域制限のどれが結果を変えたのか判断できません。自分が所有する端末、アプリ、ネットワーク、または明示的な許可を受けた検証環境だけで実行してください。
02
公式 Clumsy 0.3 を確認して展開する
現在の公式最新版は jagt/clumsy GitHub Releases の 0.3 です。一般的な64ビット Windows 10 では win64-a.zip を選び、32ビット x86 環境だけで win32 を選択します。ダウンロード元 URL、ファイル名、バイト数、SHA-256 を記録してから展開してください。A、B、C は WinDivert の署名が異なる公式代替ファイルで、Clumsy の機能は同じです。0.4、0.4 v2、0.6 という名称は公式リリース一覧にないため、数字だけを見て新しい公式版だと判断してはいけません。
03
狭い WinDivert フィルターを設定する
フィルターは障害を与える通信の境界です。すべての通信を対象にすると、ブラウザー、更新処理、会議、認証まで不安定になり、検証結果も読みにくくなります。最初は既知のホスト、ポート、プロトコル、方向に限定し、対象操作が本当に一致するか確認します。inbound と outbound では観察するパケットが異なります。匿名掲示板の式を意味も分からず貼り付けず、公式 README と WinDivert のフィルター文法を確認してください。想定外の影響が出たら Stop を選び、基準通信へ戻してから式を簡単にします。
04
最初の遅延テストを実行する
Lag はデータを捨てずに変化を観察しやすいため、最初の試験に向いています。通常時の応答時間を測り、200から300ミリ秒程度の控えめな値を設定します。フィルターを再確認し、Lag だけを有効にして Start を選びます。クリックへの即時反応、読み込み表示、取消操作、タイムアウト、入力保持、接続回復を観察してください。終了後は Stop を選択し、同じ操作をもう一度行って通常値に戻ったことを確認します。アプリ版、Windows 版、Clumsy 版、設定値、観察結果を一つの記録に残します。
05
パケットロスを段階的に追加する
Drop は選ばれたパケットを破棄するため、遅延より影響が大きくなります。低い確率と狭い対象から始め、再試行、再接続、部分失敗の通知を確認します。応答だけが失われると、サーバー側では処理済みなのにクライアントが再送する場合があります。注文、送信、保存など重複が問題になる操作では、要求識別子とサーバーログも合わせて確認します。接続を壊すことが目的ではなく、利用者に状態を正しく伝え、重複せず回復できるかを評価することが目的です。
よくある質問
Clumsy の使い方 よくある質問
Clumsy はインストールが必要ですか？
不要です。ZIP 全体を通常のフォルダーへ展開し、関連する WinDivert ファイルと実行ファイルを同じ場所に保ちます。
最初は何をテストすべきですか？
重要でないアプリに狭いフィルターを設定し、小さな Lag 値を一つだけ試す方法が適しています。
設定は実行中に変更できますか？
再現性を保つため Stop で停止し、一つの変数を変更して別の実行として記録してください。
通常の接続へ戻す方法は？
Stop を選び、Clumsy を終了し、基準操作を再実行して通常の応答へ戻ったことを確認します。
管理者権限が求められる理由は？
WinDivert が一致したパケットを捕捉・再注入する低レベル処理を行うためです。許可された端末だけで承認してください。