Konfiguration

Die meisten Funktionen von Chute werden durch die Konfigurationsdatei gesteuert. Sie können sie in Ihrem eigenen Texteditor bearbeiten oder im integrierten Editor von Chute iOS, Chute tvOS, Chute Mac (Tab Konfiguration im Hauptfenster, in der älteren Oberfläche Einstellungen...) oder Chute Android. Chute Dashboard hat keinen Konfigurationseditor — was es bearbeitet, sind die Regeln der laufenden Engine, niemals die Datei.

Chute iOS kann Konfigurationsdateien über iCloud Drive synchronisieren; das ist eine lizenzpflichtige Funktion. Chute Mac hat keine eigene iCloud-Synchronisierung: Eine Datei zu teilen heißt dort, im Importfenster eine auszuwählen, die zufällig in iCloud Drive liegt — sie wird dann an ihrem Ort referenziert.

Konfigurationsabschnitte

Die Konfigurationsdatei ist in benannte Abschnitte gegliedert:

Hinweis: Die Abschnitte [Panel], [Ponte], [MTProto], [Keystore], [Port Forwarding], [Testing], [DHCP] und [Snell Server] werden erkannt, damit eine Surge-Konfiguration keinen Fehler erzeugt (jeder protokolliert einen Hinweis), und ihre Zeilen bleiben beim Speichern der Konfiguration wortgetreu erhalten; in Chute haben sie jedoch keine Wirkung.

DNS-Abschnitt

Die DNS-bezogenen [General]-Schlüssel können gleichwertig unter einem Abschnitt [DNS] der obersten Ebene geschrieben werden. Zeilen in diesem Abschnitt werden je nach Schlüssel behandelt:

[DNS]
doh = https://dns.google/dns-query
hijack-dns = 8.8.8.8:53
*.example.com = server:1.1.1.1

Hinweis: Da hier beide Zeilenformen akzeptiert werden, kann ein [DNS]-Abschnitt DNS-Server-Einstellungen mit domainbezogenen Überschreibungen mischen. Wiederholen Sie dieselbe Einstellung nicht in [General] und [DNS]: Eine zweite doh-Zeile wird beispielsweise als doppelte DoH-Konfiguration gemeldet.

Hinweis: fallback-dns-server und encrypted-dns-skip-cert-verification werden auch unter [DNS] gelesen, obwohl sie nicht in der ersten Tabellenzeile stehen. Ein Schlüssel, der keine DNS-Einstellung ist, wird hier nicht ignoriert — er wird als domainbezogene Überschreibung gelesen. Ein hierher verirrter [General]-Schlüssel wie optimistic-dns = false wird so stillschweigend zur Zuordnung optimistic-dns → false. Nur eine Zeile, die auch der Parser für Überschreibungen zurückweist, erhält einen Hinweis. Siehe DNS.

Eine andere Datei einbinden

Ein Profil kann eine weitere Datei einziehen. Surge schreibt #!include <Pfad>, Shadowrocket schreibt include = <other.conf> über dem ersten Abschnitt. Beides wird gelesen, und die eingebundene Datei wird genau dort eingefügt, wo die Direktive steht — ein [Rule]-Fragment landet also in dem Abschnitt, der es benennt.

#!include Rulesets/company.list

• Der Pfad wird relativ zum Verzeichnis der Datei aufgelöst, die ihn nennt, und darf ein * enthalten — #!include Rulesets/*.list zieht ein ganzes Verzeichnis von Regelfragmenten in Namensreihenfolge ein.
• Includes verschachteln sich bis zu 8 Ebenen tief, und eine bereits eingezogene Datei — das Profil selbst eingeschlossen — wird kein zweites Mal eingezogen, sodass ein Zyklus nicht endlos laufen kann; ein Profil, das sich selbst einbindet, wird schlicht ignoriert.
• Ein Include wird nur ausgewertet, wenn das Profil aus einer Datei geladen wurde. Wird es der Engine als Text übergeben — so gelangt eine Konfiguration üblicherweise in den Tunnel —, fehlt das Verzeichnis zur Auflösung, und das Profil wird als unvollständig gemeldet, statt als vollständig behandelt zu werden. Die Direktive selbst bleibt beim Speichern erhalten: Sie wird genau so zurückgeschrieben, wie sie gelesen wurde, und der Inhalt der eingebundenen Datei wird nie in das Profil geschrieben.

Kommentar

Eine Zeile, die mit #, ; oder // beginnt, ist ein Kommentar. Dieselben drei Zeichen leiten auch einen Inline-Kommentar ein, aber nur direkt nach einem Leerzeichen oder Tabulator und nie innerhalb von Anführungszeichen ("…" oder '…', wobei \ das nächste Zeichen maskiert). Das :// einer URL, ein Pfad wie a//b und ein nicht in Anführungszeichen gesetzter base64-Wert, der zufällig // oder # enthält, bleiben daher vollständig. Kommentare und Leerzeilen bleiben beim Speichern der Konfiguration erhalten.

In den Rewrite-Abschnitten und in den ssid- / subnet-Zeilen von [Proxy Group] verhalten sich Inline-Kommentare anders:

Direktivzeilen — #!include, #!MANAGED-CONFIG, #!IOS-ONLY und ähnliche — werden als Direktiven gelesen, bevor irgendetwas davon greift. Die Dateien, die ein Regelsatz, eine Domain-Menge oder ein Proxy-Provider herunterlädt, sind keine Konfigurationsabschnitte: Dort kann nur eine ganze Zeile ein Kommentar sein.