トラブルシューティング

どんな問題も、まず2つの問いに分割してください: トラフィックはそもそもChuteに届いているのか（トラフィック捕捉の問題）、そしてChuteはそれを転送できているのか（転送の問題）。ライブトラフィックビューがこれに答えてくれます — ダッシュボード（iOS）またはメインウィンドウのトラフィックタブ（Mac）を開いてブラウズしてみてください: 何も表示されなければ、Chuteはトラフィックを受け取っていません。接続は表示されるが失敗する場合、Chuteはそれを転送できていません。この2つの問題では修正方法が全く異なります。

このページは「動かない」のためのものです。問いが「何をしているのか」 — リクエストを読む、ボディを保持する、レスポンスを変える、障害を再現する — なら、代わりにネットワークのデバッグから始めてください。

何も表示されない: トラフィック捕捉の問題

Chute iOS

• スイッチがオンにならず、設定バーが揺れる — 設定が選択されていません。設定バーをタップし、設定をタップしてチェックマークを付けてから完了をタップしてください（「最初に設定を選択してください」）。
• VPN許可ダイアログを拒否してしまった — もう一度スイッチを切り替えて承認してください。VPNプロファイルが動かなくなった場合（スイッチがすぐに戻ってしまう場合）は、アプリの設定にあるVPN設定をリセットを使ってください。次回の開始時にプロファイルが再作成され、再度許可を求められます。
• 別のVPNアプリが接続中 — iOSは同時に1つのVPNトンネルしか実行しません。もう一方のアプリを切断してください（そのオンデマンドルールも無効にしてください。気づかないうちにトンネルを取り戻すことがあります）。

Chute Mac

• システムプロキシはオンなのに、あるアプリがそれを無視する — 多くのツール（特にターミナルプログラム）はシステムプロキシに従いません。Chuteのリスナーを明示的に指定するか（メニューのCopy Shell Export Commandがシェル用のコマンドを用意してくれます）、ネットワーク層でトラフィックをキャプチャする拡張モードを使ってください。
• 拡張モードが開始できない — ネットワーク拡張またはヘルパーの承認が必要です。正確なシステム設定のパス、「システム拡張がブロックされました」のケース、古くなったVPN構成のリセットについては拡張モードのトラブルシューティングを参照してください。
• LANアドレス宛のトラフィックは設計上Chuteをバイパスします — 捕捉が壊れていると判断する前に、その他オプションのskip-proxyとtun-excluded-routesを確認してください。

接続は表示されるが失敗する: 転送の問題

• 経路を切り分ける。 ポリシーグループをDIRECTに切り替えます: 直接接続ではページが開くのにプロキシ経由では失敗する場合、問題はプロキシサーバーにあります — ホスト/ポート/資格情報/暗号方式の誤り、またはサーバーのダウンです。グループに対してレイテンシテストを実行してください。他のポリシーはテストを通過するのに、あるポリシーだけが一度も通過しないなら、それが原因です。
• 意図しないルールにマッチしている。 ライブトラフィックビューで失敗した接続がマッチしたルールを確認し、ルールの評価順序を読み直してください: ルールは2パスで評価されるため、ホスト名ベースのリクエストでは、後の方にある非IPルールが前の方にあるIPルールより先にマッチすることがあります。no-resolveとFINALの配置が典型的な原因です。
• DNSの応答がおかしい。 DNSセクションを確認してください: 暗号化DNSを使う場合は、DoH/DoTサーバー自体にプロキシなしで到達できることを確認します。サーバーを変更したらDNSキャッシュを消去してください（iOSのコントロールパネルのスイッチ、スクリプトからのflushDNS、またはHTTPコントロールAPIのDELETE /api/dns/cache）。
• UDPに依存するアプリの不調 — 選択したポリシーがUDPリレーをサポートしていることを確認してください（プロキシポリシーの機能マトリクスを参照）。また、TailscaleはICMPを転送しないことも思い出してください。出口ノード経由のpingは応答が返りません。

HTTPS復号が復号してくれない

• CAはインストールされ、かつ信頼されている必要があります — iOSではこれは2つの別々のステップで、2つ目（設定 → 一般 → 情報 → 証明書信頼設定）が最も見落とされがちです。CA証明書のインストールと信頼を参照してください。
• ホストが[MITM]のhostnameリストにマッチしている必要があります — 宣言されたホストだけが復号され、:port/:0サフィックスで指定しない限りポート443のみが対象です。
• 一部のアプリは証明書をピン留めしており、復号されると失敗します — 対抗するのではなく、-プレフィックスでそれらのホストを除外してください。
• QUIC/HTTP-3は復号できません — 互換性のあるクライアントをTCPに戻す方法はblock-quicを参照してください。
• iPhone と Apple TV では復号はライセンスが必要な機能です。ライセンスが無ければ何も復号されず、MitM スイッチも効きません — ライセンスと有効化を参照してください。

ログを読む

上記のセクションで解決しない場合、たいていはログが答えを教えてくれます:

• ログレベルを一時的に上げます: loglevel = verbose（verboseは遅いので、使い終わったら元に戻してください）。
• Chute Mac: メインウィンドウのログタブ。Chute iOS: セッションログ画面。ナビゲーションバーの共有ボタンから、その実行のすべてのシャードを渡せます。Chute tvOS: セッションログ画面。上部の重大度フィルター（すべて / 通知以上 / 警告以上 / 致命的）でリモコンだけで絞り込めます。
• どのプラットフォームでも: コンソールの Logs ページ、またはHTTPコントロールAPI の GET /api/logs。
• 注目すべきは警告行です: 未知のポリシー、拒否されたオプション、パースできないルールは、設定の読み込み時に全て警告としてログに記録されます。
• ログは数 MB ごとのシャードに分割されます。Chute は 1 回の実行につき最近のものを保持するため、最新のファイルは物語の結末であって全体ではありません。すべて持って行ってください。（Chute Android は代わりにこの実行のログをメモリ上に保持し、ディスク上にシャードファイルはありません。）
• macOS では、ファイルそのものは ~/Chute/Share/<run id>/ にあります — ファイルの場所（macOS）を参照してください。

診断バンドルを送る

他の人に見てもらう必要があるときは、共有シートから探し出した 6 つのファイルと記憶に頼ったクラッシュの説明より、1 つのアーカイブのほうが役に立ちます。アプリは 2 種類を区別します。動作中のエンジンが作るランタイム診断バンドルと、アプリ単独で作るオフライン診断バンドルです。どちらでも、パスワード、トークン、Cookie、URL 内の資格情報は <redacted> に置き換えられ、リクエストとレスポンスのボディは含まれません。

ランタイム診断バンドル — 動作中のエンジンが作ります。秘匿処理済みの設定、エンジンの健全性スナップショット（前回の実行がどう終わったかを含む）、この実行で注目すべき出来事、読み込まれたルールとポリシー、DNS、トラフィック、そしてログの末尾（Android ではディスク上にシャードが無いため、この実行のメモリ上のログリング）が入っています。トンネルが動作している必要があります。

• Chute iOS: コントロールパネル → 「ローカルプロキシ」セクションの最後の行 ランタイム診断バンドル — 常に表示され、トンネルが接続されるまではグレーアウトし、external-http-controller は不要です。タップするとバンドルを生成して共有シートを開きます
• Chute Android: コントロールパネル → ランタイム診断バンドル（HTTP API の行の下） — VPN が動作するまでは無効です
• Chute Mac: メニューバー → 診断バンドルを保存… — エンジンはアプリ内で動くため、この 1 つのバンドルが両方の種類を兼ね、エンジンが動作中でも停止中でも使えます
• Chute tvOS: この端末には共有シートもファイルブラウザーも無いので、コンソールの Download diagnostic bundle（診断バンドルをダウンロード） が唯一の方法です。アプリの QR コードを読み取り、メールを送れる端末で Diagnostics ページを開きます
• どのプラットフォームでも、コンソールから: Diagnostics ページのダウンロードボタン、または POST /api/diagnostics/bundle

オフライン診断バンドル — エンジン無しでアプリが作るため、トンネルが落ちているときや一度も起動していないときにも使えます。アプリのホストレポート（バージョン、端末、VPN の状態、設定の概要、そしてテキスト化した「ネットワーク / プロキシ / ルートテーブル」の診断ページ）、前回の実行の終了マーカー（エンジンが実際に動作中なら「running」と報告されます）、そしてアプリが到達できるログファイルが入っています。

• Chute iOS: 設定 → 「診断」セクション → オフライン診断バンドル
• Chute Android: 設定 → 「診断」セクション → オフライン診断バンドルを保存
• Chute tvOS: 設定 → オフライン診断バンドル — Apple TV がバンドルを作成し QR コードを表示します。同じネットワーク上のスマートフォンで読み取る（またはパソコンで表示中のアドレスを開く）と zip をダウンロードできます。このリンクはその画面を開いている間だけ有効です
• Chute Mac: 別途のオフラインバンドルは不要です — メニューバーの 診断バンドルを保存… はエンジン停止中でも使え、その材料はそのまま添付できる普通のファイルです。~/Chute/Share/<run id>/ 配下のログシャードと実行マーカー ~/Chute/Share/last-run.json — ファイルの場所（macOS）を参照してください

ファイル名でどちらか分かります。ランタイムバンドルは diagnostics-<timestamp>.zip、オフラインバンドルは diagnostics-offline-<timestamp>.zip です。どちらにも manifest.json が入っており、その kind フィールドがどちらかを示します。

送る前に、コンソールの Diagnostics ページにある 前回の終了 の行を読む価値があります。メモリ不足で強制終了（Killed for memory）は Chute の不具合ではなくシステムによる回収を意味し、次に何を調べるべきかが変わります。

書き換えが効かないのはなぜ？

一度も命中しない書き換えルールには症状がありません。何も起きない — それは「命中したが目に見える変化が無かった」場合とまったく同じに見えます。コンソールはこれに直接答えます。Rules（ルール） ページには、この実行で命中したすべての書き換え/Mock ルールとその回数が並びます。この表が追跡するのは最大 512 種類のルールで、それを超えると記録できなかった発動数を報告し（API では rewrite_hit_dropped_rules）、その時点で表は一部しか示していません。

• その一覧に無いルールは一度も命中していません — その表が記録できなかったルールを報告していない限りは。URL 書き換えの URL 形式に照らしてパターンを確認してください。ヘッダー書き換えは部分一致ではなく URL 全体に対して照合します。
• 命中したのに変化が見えない場合は別の問題です。コンソールでその接続を開き、適用された書き換え の行を読んでください。ルール自身の文言で名指しされます。
• ルールが HTTPS のトラフィックを見られるのは、そのホストに対して HTTPS 復号が有効なときだけです。