リライトルールとブレークポイント
キャプチャは「見る」ことを、ルールとブレークポイントは「変える」ことを可能にします。Trace Eagleはあなたを自分のトラフィックの所有者にします。コードを書かずにリクエストを変える、シンプルで直接的なクリックルールで何千ものフローを自動リライトする。あるいはブレークポイントを使ってフローを一つずつ一時停止して編集する。ルールでは本当に表現できない複雑なロジックに限って、スクリプト / プラグインに頼ればよいのです。
1. リライトルール(シンプルなクリック、自動変更)
Section titled “1. リライトルール(シンプルなクリック、自動変更)”リクエストを変え始めるのに、スクリプトを書くのは最悪のやり方です。ここではその必要はありません。チートシートからアクションを選んで値を入れる、それだけでルールになります。シンプルで直感的、作った瞬間に適用されます。
ルールは1行に1つ、<match> <action>://<value> の形式です(例:*.example.com resHeaders://X-Debug: 1)。空行と # コメントは無視され、各行は個別に検証され、変更は保存時にホット適用されます。ルールは名前付きグループに整理し、グループ単位で切り替えられます。画面にはクリック式のチートシートが付いており、一度クリックすればマッチする例が挿入されるので、あとは値を編集するだけ。構文を覚える必要はありません。
柔軟なマッチ条件
Section titled “柔軟なマッチ条件”- 完全一致ドメイン:
traceeagle.com(パスプレフィックスtraceeagle.com/pathを含められます) - ワイルドカードサブドメイン:
*.traceeagle.com(頂点ドメインと全サブドメインにマッチ) - URL全体に対する正規表現:
regex://… - 完全一致のフルURL:
$https://host/path - ポート:
:8080 - 否定:任意のマッチの前に
!を付ける
対応するリライトアクション
Section titled “対応するリライトアクション”リクエスト方向
- リダイレクト / 転送:ダイヤル先のターゲットIP(
host)を変える、別のフルURLにマップする(map-remote、ローカルの開発サーバーを指せます)、上流のhttp / socks5プロキシ経由でルーティングする、あるいはクライアントのネットワークリクエスト特性を標準的なクライアントのものに戻す(忠実な再現)。 - 偽データのモック:
mock://200またはmock://200|<body>、サーバーに当たらずプリセットのレスポンスを返します。フロントエンドがバックエンドAPIを待っているときの命綱です。 - リクエストライン / ヘッダーの編集:メソッド、User-Agent、Referer、Basic認証、X-Forwarded-For、Content-Type / 文字コード、Cookie、クエリパラメータのマージ、URLの検索置換。
- リクエストボディの編集:全置換 / 検索置換 / 末尾追加 / 先頭追加 / ローカルファイルへのダンプ。
レスポンス方向
- ステータス / ヘッダーの編集:ステータスコードの変更、任意のレスポンスヘッダーの追加 / 削除、Set-Cookie、ワンクリックでCORSを開放、添付ダウンロードの強制、キャッシュ制御(キャッシュ無効化またはmax-age設定)、Cookie / 圧縮 / keep-aliveの無効化、ヘッダー値の検索置換。
- レスポンスボディの編集:全置換 / 検索置換 / 末尾追加 / 先頭追加 / JSONの浅いマージ。
- タイプ別インジェクション:Content-Typeがマッチしたときに限り、HTML / JS / CSSにスクリプト、スタイル、スニペットをインジェクトまたは置換します。
ネットワークとプロトコル
- ファイルへのダンプ:リクエスト / レスポンスボディに加えて、生のリクエスト / レスポンス全体もワンクリックでローカルファイルにダンプでき、アーカイブやオフライン分析に使えます。
- 貧弱ネットワークのシミュレーション:リクエスト / レスポンスの遅延(ミリ秒)、帯域スロットリング(2G / 3G / 4Gのプリセット付き)。
- WebSocketフレームのリライト:方向別(双方向 / クライアント→サーバー / サーバー→クライアント)の
old=>new置換。 - 生TCP / UDPのリライト:非HTTPのバイトストリーム / SOCKS5 UDPデータグラムに対する方向別の置換。
ルール内の動的な値
Section titled “ルール内の動的な値”ルールの値には ${url} ${host} ${port} ${method} ${status} ${now} ${random} ${randomUUID} ${req.headers.X} ${res.headers.X} などの動的変数に加え、カスタムの名前付き値 {name}(共通の値を一度定義すれば、どこからでも参照できます)を使えます。名前付き値 {name} は主にリクエスト / レスポンスのリライトで使い、WebSocketフレームリライトの置換値は ${...} に対応します。
2. ブレークポイント(手動編集)
Section titled “2. ブレークポイント(手動編集)”ケースごとに正確な制御が必要なフローには、ブレークポイントを使って、リクエストが送信される前またはレスポンスが返る前に一時停止してエディタをポップアップさせます。
2つのトリガー方法
Section titled “2つのトリガー方法”- ルールトリガー:
breakpoint://req|res|bothルールを使って、どのフローを横取りするかを正確にマークします。 - グローバル横取りスイッチ:セッション全体の横取りをオンにし、必要なら横取りフィルタルールでスコープを絞り込みます(ドメイン / メソッド / ステージでフィルタ)。ルールがなければすべてが横取りされます。
横取り後に変えられるもの
Section titled “横取り後に変えられるもの”- リクエストステージ:メソッド、URL(ホストはURLに従います)、ヘッダー、ボディ。
- レスポンスステージ:ステータスコード、レスポンスヘッダー、レスポンスボディ。
- そのまま破棄:Abortでこのリクエスト / レスポンスを落とします(クライアントはゲートウェイエラーを受け取ります)。
- 複数ヒットしたフローは処理待ちのキューに並びます。それぞれを再開したり(Resume)、破棄したり(Abort)、一括で再開したりできます。長時間処理されないフローは自動的に無変更のまま再開されるので、トラフィックが無期限に詰まることはありません。
3. スクリプトとプラグイン(高度な自動化)
Section titled “3. スクリプトとプラグイン(高度な自動化)”ルールでは表現できないロジックは、スクリプトやプラグインに委ねます。
- JavaScriptスクリプト:
onRequest(req)/onResponse(resp)を定義し、フィールドを直接編集すれば反映されます。組み込みヘルパーには、ロギング、他サービスへの同期的なアウトバウンド呼び出し、リクエストをまたいだデータの退避(カウンターやキャッシュしたトークン用)、Base64エンコード / デコードなどがあります。 - HTTPアウトバウンドプラグイン:
plugin://nameルールを使って、リクエスト / レスポンスを自前のプラグインサービスに渡して処理させ(HTTP経由で呼び出し)、プラグインがリライト後の内容を返します(直接モックすることもできます)。言語非依存で、チームが任意の言語でカスタム処理を実装するのに向いています。
4. 処理順序
Section titled “4. 処理順序”フローは順に、リクエストルール、リクエストスクリプト、リクエストプラグイン、リクエストブレークポイント、転送 / モック、レスポンスルール、レスポンススクリプト、レスポンスプラグイン、レスポンスブレークポイントを通過します。パターンはシンプルです。まず自動ルール、次にスクリプト、次にプラグイン、そして最後にブレークポイントだけが手動で介入する、それぞれが自分の仕事をこなし、互いに邪魔をしません。
プロキシキャプチャへ戻る · 関連:リクエストの構成とリプレイ