トラブルシューティング

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

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

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

Chute iOS

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

Chute Mac

• システムプロキシはオンなのに、あるアプリがそれを無視する — 多くのツール（特にターミナルプログラム）はシステムプロキシに従いません。Chuteのリスナーを明示的に指定するか（メニューのシェルの export コマンドをコピーがシェル用のコマンドを用意してくれます）、ネットワーク層でトラフィックをキャプチャする拡張モードを使ってください。
• システムプロキシや拡張モードがオンにならない — どちらもChuteの特権ヘルパーに依存しています。初回のインストールでは、Chuteが理由を説明したあと（Chuteにはヘルパーが必要です）、承認を求められます。macOS 13 以降では、さらにシステム設定 → 一般 → ログイン項目と機能拡張でヘルパーを許可する必要がある場合があり、Chuteは承認が必要ですまたはログイン項目でChuteを許可でそれを知らせます。ヘルパーはアプリが想定するバージョン（現在は 0.8.6）でなければなりません。バージョンが合わないヘルパーは自動的に再インストールされるので、Chuteを更新したあとはその確認を承認してください。
• 拡張モードが開始できない — PacketTunnelタイプではネットワーク機能拡張の承認も必要です。正確なシステム設定のパス、「システム拡張がブロックされました」のケース、古くなったVPN構成のリセットについては拡張モードのトラブルシューティングを参照してください。
• LANアドレス宛のトラフィックは設計上Chuteをバイパスします — 捕捉が壊れていると判断する前に、その他オプションのskip-proxyを確認してください。ここでtun-excluded-routesは答えになりません: これを読むのはChute iOS、Chute tvOS、Chute Androidのトンネルだけで、macOSでは何もしません。MacでLANの範囲を拡張モードに取り込むには、両方の拡張モードタイプが従うtun-included-routesにその範囲を書いてください。

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

• 経路を切り分ける。 ポリシーグループをDIRECTに切り替えます: 直接接続ではページが開くのにプロキシ経由では失敗する場合、問題はプロキシサーバーにあります — ホスト/ポート/認証情報/暗号方式の誤り、またはサーバーのダウンです。グループに対してレイテンシテストを実行してください。他のポリシーはテストを通過するのに、あるポリシーだけが一度も通過しないなら、それが原因です。
• 意図しないルールにマッチしている。 ライブトラフィックビューで失敗した接続がマッチしたルールを確認し、ルールの評価順序を読み直してください: ルールは2パスで評価されるため、ホスト名ベースのリクエストでは、後の方にある非IPルールが前の方にあるIPルールより先にマッチすることがあります。no-resolveとFINALの配置が典型的な原因です。
• DNSの応答がおかしい。 DNSセクションを確認してください: 暗号化DNSを使う場合は、DoH/DoTサーバー自体にプロキシなしで到達できることを確認します。サーバーを変更したらDNSキャッシュを消去してください（iOSのコントロールパネルの DNSキャッシュを消去 の行、スクリプトからの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、Androidでは復号はライセンスが必要な機能です。ライセンスが無ければ、設定が何を書いていてもコントロールAPIが何を求めても、何も復号されません — ライセンスと有効化を参照してください。iPhoneでのスイッチはコントロールパネルの MitM の行です。Apple TVにはMitMの行そのものが無いため、復号をオンにするのはプロファイルの[MITM]のenable = trueか、実行時のWebコンソール、Chute Dashboard、PUT /api/features/mitmです。

ログを読む

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

• ログレベルを一時的に上げます: loglevel = verbose（verboseは遅いので、使い終わったら元に戻してください）。
• Chute Mac: メインウィンドウのログタブ。Chute iOS: セッションログ画面。ナビゲーションバーの共有ボタンから、その実行のすべてのシャードを渡せます。Chute tvOS: セッションログ画面。上部の重大度フィルター（すべて / 通知以上 / 警告以上 / 致命的）でリモコンだけで絞り込めます。Chute Android: エンジンのログはファイルに書き出されません — コンソールのLogsページ（次の項目）で読むか、ランタイム診断バンドルで持ち出すか、adb logcatで追いかけてください。ダッシュボードのログタブと、セッション一覧のセッションのログタブに表示されるのはアプリ自身のサービスログ（開始、停止、ネットワークの変化）だけで、設定のローカルログを削除がそれを空にします。
• どのプラットフォームでも: コンソールのLogsページ、またはHTTPコントロールAPI の GET /api/logs。
• 注目すべきは警告行です: 未知のポリシー、拒否されたオプション、パースできないルールは、設定の読み込み時に全て警告としてログに記録されます。
• ログは数MBごとのシャードに分割されます。Chuteは 1 回の実行につき最近のものを保持するため、最新のファイルはログの末尾にすぎず全体ではありません。すべてのファイルを添付してください。（Chute Androidはシャードに分割しません: エンジン自身のログはメモリリングに留まり、アプリは自身のサービスログを単一の logs/runtime.log に追記し、さらに sessions/<run id>/ 以下に実行ごとのコピーを置きます。どちらもアプリのプライベートストレージ内にあります。）
• 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: メニューバー → 診断バンドルを保存… — エンジンはアプリ内で動くため、バンドルはその場で組み立てられ、エンジンが動作中でも停止中でも使えます。種類は常にランタイムで、Macがオフラインの方を作ることはありません
• 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 フィールドがどちらかを示します。Chute Macから保存したバンドルは常にランタイムの方なので、その名前に offline- が付くことはありません。

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

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

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

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