ネットワークのデバッグ

Chuteはプロキシですが、自分のデバイスでプロキシを動かす理由はたいてい経路選択ではありません。すべてのリクエストが、自分の制御下にある場所を通るようになる — それが理由です。だからアプリが実際に何を送っているのかを観察でき、ボディを保存してあとから読み、転送中のリクエストやレスポンスを書き換え、正常なバックエンドを壊れたように見せてアプリの振る舞いを確かめられます。

それぞれの仕組みのリファレンスは本マニュアルの別の場所にあります: HTTPS復号、モックレスポンス、URL書き換え、JSスクリプト。このセクションはそれらを実際に使う順に並べ、プラットフォームごとに何が変わるかを示します。

同じエンジンを見る 4 つの窓

動いているChuteは 1 つ、見方は 4 つ。窓を間違えるのが「そこに無い」の典型的な原因です。

コンソールとDashboardは大きく重なりますが、入り口が違います — コンソールはエンジンが提供しブラウザで開くもの、Dashboardはバイナリチャネルで話すMacアプリです。どちらも他方の上位互換ではありません。違いはDashboardが届かないものにあります。

まず 4 つのスイッチを正しく

「接続は見えるのにリクエストが見えない」は、ほぼ必ずこの 4 つのどれかに行き着きます。この順で確認してください:

1. そもそもトラフィックがChuteに届いている。 トラフィックビューに行があることが証拠です。何も無いならデバッグではなくトラフィック捕捉の問題です — トラブルシューティングを参照。
2. CAがインストールされ、かつ信頼されている。 iOSでは 2 ステップ、macOSでは 1 ステップ、tvOSではそのどちらもアプリ内では行いません — CA証明書のインストールと信頼を参照。
3. ホストがMitMリストにある。 Chuteは宣言されたホストだけを復号します。Dashboardで M フラグの無い行は、一度も復号されていません。
4. 記録がオンになっている。 replica = true、またはアプリのスイッチ（トラフィックキャプチャ）。iPhone、Apple TV、Androidではエンジンがライセンスも要求するので、そこではキーだけでは何も取得されません。記録がオフでも各行はルール・ポリシー・タイミングを持ちます — 欠けるのはペイロードだけです。[Replica] がさらに何を残すかを絞り、残したものもその実行のあいだしか持ちません: Chuteは停止時に記録したボディを削除します。

3 と 4 はコンソールからもDashboardからもAPIからも実行時に切り替えられますが、いずれも設定ファイルには書き戻されません。再起動すればファイルの内容が優先されます。

プラットフォームごとにできること

次に読むもの

• MacからiPhoneをデバッグ — まっさらなスマートフォンからMac画面上の復号済みボディまで、全行程。
• Macでのデバッグ — Mac自身のトラフィック。ターミナルツールやプロセス単位の切り分けを含みます。
• Apple TVのデバッグ — ブラウザも共有シートも無く、自分では証明書もインストールできないデバイス。
• レプリカ — どの接続がボディを保持するか、そして何でもかんでも取得するのをやめる方法。
• モックと障害注入 — 固定レスポンス、エラーステータス、遅延の注入、そしてChuteには本当にできないこと。

「何をしているのか」ではなく「動かない」が問いなら、代わりにトラブルシューティングから始めてください。とくに書き換えが効かないのはなぜ？ — このセクションが最も多く生む問いがこれです。