Fehlerbehebung

Zerlegen Sie jedes Problem zuerst in zwei Fragen: Erreicht der Verkehr Chute überhaupt (ein Übernahmeproblem), und kann Chute ihn weiterleiten (ein Weiterleitungsproblem)? Die Live-Verkehrsansicht beantwortet das — öffnen Sie das Dashboard (iOS) oder den Tab Datenverkehr des Hauptfensters (Mac) und surfen Sie: Erscheint nichts, empfängt Chute den Verkehr nicht; erscheinen Verbindungen, die aber fehlschlagen, kann Chute sie nicht weiterleiten. Die beiden Hälften haben völlig unterschiedliche Lösungen.

Diese Seite ist für „es funktioniert nicht“. Lautet die Frage „was tut es“ — Anfragen lesen, Bodies aufbewahren, eine Antwort ändern, einen Fehler simulieren —, beginnen Sie stattdessen beim Netzwerk-Debugging.

Nichts erscheint: Übernahmeprobleme

Chute iOS

• Der Schalter lässt sich nicht einschalten und die Konfigurationsleiste wackelt — es ist keine Konfiguration ausgewählt. Tippen Sie auf die Leiste Konfiguration, tippen Sie auf eine Konfiguration, sodass ein Häkchen erscheint, dann auf Fertig („Bitte wählen Sie zuerst eine Konfiguration aus“).
• Der VPN-Berechtigungsdialog wurde abgelehnt — schalten Sie erneut um und genehmigen Sie ihn. Steckt das VPN-Profil fest (der Schalter springt sofort zurück), verwenden Sie VPN-Konfiguration zurücksetzen in den Einstellungen der App; der nächste Start erstellt das Profil neu und fragt erneut nach der Berechtigung.
• Eine andere VPN-App ist verbunden — iOS betreibt immer nur einen VPN-Tunnel gleichzeitig. Trennen Sie die andere App (oder deaktivieren Sie deren On-Demand-Regeln, die sich den Tunnel unbemerkt zurückholen können).

Chute Mac

• Systemproxy ist an, aber eine App ignoriert ihn — viele Tools (insbesondere Terminalprogramme) respektieren den Systemproxy nicht. Richten Sie sie explizit auf Chutes Listener (Shell-Exportbefehl kopieren im Menü erledigt das für Shells), oder verwenden Sie den Erweiterten Modus, der den Verkehr auf Netzwerkebene erfasst.
• Systemproxy oder Erweiterter Modus lässt sich nicht einschalten — beide sind auf den privilegierten Helfer von Chute angewiesen. Seine erste Installation bittet Sie, ihn zu autorisieren, nachdem Chute erklärt hat, wozu (Chute benötigt einen Helfer); unter macOS 13 und neuer muss er eventuell zusätzlich unter Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen erlaubt werden, worauf Chute mit Genehmigung erforderlich oder Chute in Anmeldeobjekten erlauben hinweist. Der Helfer muss die Version haben, die die App erwartet (derzeit 0.8.6): Ein abweichender wird automatisch neu installiert — bestätigen Sie diese Abfrage also nach einem Update von Chute.
• Der Erweiterte Modus startet nicht — beim Typ PacketTunnel braucht zusätzlich die Netzwerkerweiterung eine Genehmigung; siehe die Fehlerbehebung zum Erweiterten Modus für die genauen Pfade in den Systemeinstellungen, den Fall „Systemerweiterung blockiert“ und das Zurücksetzen einer festgefahrenen VPN-Konfiguration.
• Verkehr zu LAN-Adressen umgeht Chute konstruktionsbedingt — prüfen Sie skip-proxy in Verschiedene Optionen, bevor Sie annehmen, die Übernahme sei defekt. tun-excluded-routes hilft hier nicht: Es wird nur von den Tunneln von Chute iOS, Chute tvOS und Chute Android gelesen und tut unter macOS nichts. Um einen LAN-Bereich auf einem Mac in den Erweiterten Modus zu holen, tragen Sie ihn in tun-included-routes ein; beide Typen des Erweiterten Modus berücksichtigen das.

Verbindungen erscheinen, schlagen aber fehl: Weiterleitungsprobleme

• Grenzen Sie den Pfad ein. Schalten Sie Ihre Richtliniengruppe auf DIRECT: Laden Seiten direkt, aber nicht über den Proxy, liegt das Problem beim Proxy-Server — falscher Host/Port, falsche Zugangsdaten oder Verschlüsselung, oder der Server ist ausgefallen. Führen Sie einen Latenztest für die Gruppe aus; eine Richtlinie, die den Test nie besteht, während andere ihn bestehen, benennt den Schuldigen.
• Die falsche Regel greift. Sehen Sie sich in der Live-Verkehrsansicht die passende Regel einer fehlschlagenden Verbindung an und lesen Sie dann die Regelauswertungsreihenfolge erneut: Regeln werden in zwei Durchläufen ausgewertet, daher kann bei hostnamenbasierten Anfragen eine spätere Nicht-IP-Regel vor einer früheren IP-Regel greifen. no-resolve und die Platzierung von FINAL sind die üblichen Verdächtigen.
• DNS-Antworten sehen falsch aus. Überprüfen Sie den DNS-Abschnitt: Stellen Sie bei verschlüsseltem DNS sicher, dass der DoH/DoT-Server selbst ohne den Proxy erreichbar ist; leeren Sie den DNS-Cache nach einem Serverwechsel (die Zeile DNS-Cache leeren im iOS-Bedienfeld, flushDNS aus einem Skript oder DELETE /api/dns/cache über die HTTP-Control-API).
• UDP-abhängige Apps verhalten sich fehlerhaft — vergewissern Sie sich, dass die gewählte Richtlinie UDP-Relay unterstützt (siehe die Fähigkeitsmatrix in Proxy-Server), und denken Sie daran, dass Tailscale kein ICMP weiterleitet — ein ping über einen Exit Node bleibt daher stumm.

Die HTTPS-Entschlüsselung entschlüsselt nicht

• Die CA muss installiert und als vertrauenswürdig eingestuft sein — zwei getrennte Schritte auf iOS; der zweite (Einstellungen → Allgemein → Info → Zertifikatsvertrauenseinstellungen) ist der, den alle übersehen. Siehe CA-Zertifikat installieren und als vertrauenswürdig einstufen.
• Der Host muss auf die hostname-Liste in [MITM] passen — nur deklarierte Hosts werden entschlüsselt, und nur auf Port 443, sofern kein :port-/:0-Suffix etwas anderes bestimmt.
• Manche Apps pinnen ihre Zertifikate und schlagen fehl, solange sie entschlüsselt werden — schließen Sie deren Hosts mit einem --Präfix aus, statt gegen sie anzukämpfen.
• QUIC/HTTP-3 kann nicht entschlüsselt werden — siehe block-quic, um kompatible Clients zurück zu TCP zu lenken.
• Auf iPhone, Apple TV und Android ist die Entschlüsselung lizenzpflichtig: Ohne Lizenz wird nichts entschlüsselt, ganz gleich, was die Konfiguration oder die Control-API verlangt — siehe Lizenz und Aktivierung. Auf dem iPhone ist der Schalter die Zeile MitM im Bedienfeld. Das Apple TV hat überhaupt keine MitM-Zeile; dort wird die Entschlüsselung über enable = true unter [MITM] im Profil eingeschaltet oder zur Laufzeit über die Web-Konsole, über Chute Dashboard oder mit PUT /api/features/mitm.

Die Protokolle lesen

Wenn die obigen Abschnitte es nicht klären, tut es meist das Protokoll:

• Erhöhen Sie vorübergehend die Protokollstufe: loglevel = verbose (danach zurücksetzen — verbose ist langsam).
• Chute Mac: der Tab Protokoll des Hauptfensters. Chute iOS: der Sitzungsprotokoll-Bildschirm; die Teilen-Schaltfläche in der Navigationsleiste übergibt alle Shards dieses Laufs. Chute tvOS: der Sitzungsprotokoll-Bildschirm mit einem Schweregrad-Filter darüber (Alle / Hinweis+ / Warnung+ / Schwerwiegend), sodass die Fernbedienung zum Eingrenzen genügt. Chute Android: Das Protokoll der Engine wird dort in keine Datei geschrieben — lesen Sie es auf der Seite „Protokolle“ der Konsole (nächster Punkt), nehmen Sie es im Laufzeit-Diagnosepaket mit oder verfolgen Sie es mit adb logcat. Der Tab Protokolle des Dashboards und der Tab Protokoll einer Sitzung in der Sitzungsliste zeigen nur das eigene Dienstprotokoll der App (Starts, Stopps, Netzwerkwechsel), das Lokale Protokolle löschen in den Einstellungen leert.
• Auf jeder Plattform: die Seite „Protokolle“ der Web-Konsole oder GET /api/logs über die HTTP-Control-API.
• Die Warnungen sind die interessanten Zeilen: Unbekannte Richtlinien, abgelehnte Optionen und nicht parsbare Regeln werden beim Laden der Konfiguration allesamt als Warnungen protokolliert.
• Das Protokoll wird in Shards von einigen Megabyte geteilt. Chute behält die jüngsten eines Laufs, die neueste Datei ist also das Ende der Geschichte und nicht die ganze — nehmen Sie alle mit. (Chute Android teilt nicht in Shards: Das Protokoll der Engine selbst bleibt in einem Speicherring, und die App hängt ihr Dienstprotokoll an eine einzige logs/runtime.log an, dazu eine Kopie je Lauf unter sessions/<run id>/, beides in ihrem privaten Speicher.)
• Auf macOS liegen die Dateien selbst unter ~/Chute/Share/<run id>/ — siehe Dateispeicherorte (macOS).

Ein Diagnosepaket senden

Wenn jemand anderes hinschauen soll, ist ein Archiv besser als sechs über ein Teilen-Menü gefundene Dateien und ein aus dem Gedächtnis beschriebener Absturz. Die Apps unterscheiden zwei Arten: ein Laufzeit-Diagnosepaket, das die laufende Engine erstellt, und ein Offline-Diagnosepaket, das die App allein erstellt. In beiden sind Passwörter, Token, Cookies und Zugangsdaten in URLs durch <redacted> ersetzt, und Anfrage- und Antwort-Bodys sind nicht enthalten.

Laufzeit-Diagnosepaket — von der laufenden Engine erstellt: eine bereinigte Kopie der Konfiguration, die Zustandsaufnahme der Engine (einschließlich, wie der vorherige Lauf endete), die bemerkenswerten Ereignisse dieses Laufs, die geladenen Regeln und Richtlinien, DNS, Verkehr und das Ende des Protokolls (auf Android der Protokollring der Engine im Speicher, da die Engine selbst keine Dateien schreibt). Der Tunnel muss dafür laufen.

• Chute iOS: Bedienfeld → letzte Zeile des Abschnitts „LOKALER PROXY“, Laufzeit-Diagnosepaket — immer aufgeführt, ausgegraut, bis der Tunnel verbunden ist, und ohne external-http-controller nutzbar; Antippen erstellt das Paket und öffnet das Teilen-Menü
• Chute Android: Bedienfeld → Laufzeit-Diagnosepaket, unterhalb der HTTP-API-Zeilen — deaktiviert, bis das VPN läuft
• Chute Mac: Menüleiste → Diagnosepaket sichern … — die Engine läuft in der App, das Paket wird also an Ort und Stelle erstellt und funktioniert, ob die Engine läuft oder gestoppt ist; es ist immer die Laufzeit-Art, das Offline-Paket erstellt der Mac nie
• Chute tvOS: Dieses Gerät hat weder Teilen-Menü noch Dateibrowser; Diagnosepaket herunterladen in der Konsole ist der einzige Weg — scannen Sie den QR-Code in der App und öffnen Sie die Seite „Diagnose“ auf einem Gerät, von dem aus Sie Mail senden können
• Auf jeder Plattform, aus der Konsole: die Download-Schaltfläche auf der Seite „Diagnose“ oder POST /api/diagnostics/bundle

Offline-Diagnosepaket — von der App ohne die Engine erstellt, funktioniert also, wenn der Tunnel steht oder nie gestartet wurde: der Host-Bericht der App (Version, Gerät, VPN-Zustand, eine Zusammenfassung der Konfiguration und die Diagnoseseiten „Netzwerk / Proxy / Routing-Tabelle“ als Text), die Beendigungsmarkierung des vorherigen Laufs (als „running“ gemeldet, wenn die Engine tatsächlich läuft) und die Protokolldateien, die die App erreichen kann.

• Chute iOS: Einstellungen → Abschnitt „DIAGNOSE“ → Offline-Diagnosepaket
• Chute Android: Einstellungen → Abschnitt „DIAGNOSE“ → Offline-Diagnosepaket sichern
• Chute tvOS: Einstellungen → Offline-Diagnosepaket — der Apple TV erstellt das Paket und zeigt einen QR-Code; scannen Sie ihn mit einem Telefon im selben Netz (oder öffnen Sie die gezeigte Adresse auf einem Computer), um die Zip-Datei herunterzuladen — der Link funktioniert nur, solange dieser Bildschirm geöffnet ist
• Chute Mac: Hier gibt es kein Offline-Paket, und es ist auch keines nötig — Diagnosepaket sichern … in der Menüleiste erstellt die Laufzeit-Art auch bei gestoppter Engine und bewahrt die letzte Beendigung, das Ende des Protokolls und die Konfiguration; die Dateien, aus denen es schöpft, sind gewöhnliche Dateien, die Sie direkt anhängen können: die Protokoll-Shards unter ~/Chute/Share/<run id>/ und die Laufmarkierung ~/Chute/Share/last-run.json — siehe Dateispeicherorte (macOS)

Auf den Plattformen, die beide Arten erstellen, sagt der Dateiname, welche Sie haben: ein Laufzeitpaket heißt diagnostics-<timestamp>.zip, ein Offline-Paket diagnostics-offline-<timestamp>.zip; beide enthalten eine manifest.json, deren Feld kind dasselbe angibt. Ein aus Chute Mac gesichertes Paket ist immer die Laufzeit-Art, sein Name trägt den Teil offline- also nie.

Vor dem Absenden lohnt die Zeile Letzte Beendigung auf der Konsolenseite „Diagnose“: Wegen Speichermangel beendet heißt, dass das System Chute beendet hat und nicht Chute selbst gescheitert ist — das ändert, wonach man sucht.

Warum bewirkt meine Umschreibung nichts?

Eine Umschreibungsregel, die nie passt, hat kein Symptom: Es geschieht nichts, und das sieht genauso aus wie eine Regel, die gepasst und nichts Sichtbares getan hat. Die Konsole beantwortet das direkt: Die Seite Regeln listet jede Umschreibungs- und Mock-Regel auf, die in diesem Lauf gegriffen hat, mit Zähler. Die Tabelle verfolgt bis zu 512 verschiedene Regeln; darüber hinaus meldet sie, wie viele weitere ohne Erfassung ausgelöst haben (rewrite_hit_dropped_rules in der API), und ist dann nur noch ein Teilbild.

• Eine Regel, die dort fehlt, hat nie gepasst — solange die Tabelle keine nicht erfassten Regeln meldet. Prüfen Sie das Muster gegen die URL-Formen in URL-Umschreibung; jede Umschreibungsfamilie, auch Header-Umschreibung, gleicht das Muster an beliebiger Stelle der URL ab.
• Eine Regel, die gegriffen und nichts Sichtbares bewirkt hat, ist ein anderes Problem — öffnen Sie die Verbindung in der Konsole und lesen Sie die Zeilen Angewendete Umschreibungen, die die Regel im eigenen Wortlaut benennen.
• Regeln sehen HTTPS-Verkehr nur, wenn für diesen Host die HTTPS-Entschlüsselung aktiv ist.