Verschiedene Optionen

[General]
ipv6 = true
loglevel = notify

skip-proxy = 127.0.0.1, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, localhost, *.local

tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
tun-included-routes = 192.168.1.12/32

Allgemeine Optionen

Vollständige IPv6-Unterstützung aktivieren (Standard: true)

ipv6 = true

loglevel (Standard: warning)

loglevel = notify

Einer von none, fatal, warning, notify, info oder verbose. Es wird nicht empfohlen, verbose im täglichen Gebrauch zu aktivieren, da dies die Leistung erheblich verlangsamt.

skip-proxy

skip-proxy = 127.0.0.1, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, localhost, *.local

In der iOS- und der tvOS-Version wird ein Hostname-Eintrag der Proxy-Ausnahmeliste des Tunnels hinzugefügt, sodass Verbindungen dorthin von Chute TUN statt von Chute Proxy verarbeitet werden; ein Eintrag mit IP-Adresse oder CIDR wird zusätzlich zu einer ausgeschlossenen Route des Tunnels, sodass Verkehr in diesen Bereich den Tunnel ganz verlässt, statt von Chute TUN verarbeitet zu werden. Chute Android macht es im VPN-Modus genauso: Solange System-HTTP-Proxy eingeschaltet ist, kommen Hostnamen, *-Platzhalter und IPv4-Adressen in die Ausnahmeliste des Proxys, den das VPN an die Apps übergibt, und ab Android 13 wird jeder Eintrag mit IP-Adresse oder CIDR zu einer ausgeschlossenen Route des VPN — eine einzelne Adresse als /32- oder /128-Route; Loopback-Einträge werden ausgelassen, da Loopback-Verkehr den Tunnel nie betritt. In der macOS-Version werden diese Einstellungen auf das System angewendet, wenn „Als Systemproxy festlegen“ aktiviert ist. Diese Option wird verwendet, um Kompatibilitätsprobleme mit einigen Apps zu beheben.

• Um eine einzelne Domain anzugeben, geben Sie den Domainnamen ein - zum Beispiel apple.com.
• Um alle Websites auf einer Domain anzugeben, verwenden Sie ein Sternchen vor dem Domainnamen - zum Beispiel *apple.com.
• Um einen bestimmten Teil einer Domain anzugeben, geben Sie jeden Teil an - zum Beispiel store.apple.com.
• Um Hosts oder Netzwerke nach IP-Adressen anzugeben, geben Sie eine bestimmte IP-Adresse wie 192.168.2.11 oder einen Adressbereich wie 192.168.2.* oder 192.168.2.0/24 ein.

Hinweis: Wenn Sie eine IP-Adresse oder einen Adressbereich eingeben, können Sie den Proxy nur umgehen, wenn Sie über diese Adresse eine Verbindung zu diesem Host herstellen, nicht wenn Sie über einen Domainnamen eine Verbindung herstellen, der zu dieser Adresse aufgelöst wird.

Proxy-Server-Listening

interface = 127.0.0.1
port = 8118
socks-interface = 127.0.0.1
socks-port = 8119

interface / port steuern die Lauschadresse und den Port des HTTP-Proxy-Servers (Standard 127.0.0.1:8118). socks-interface / socks-port steuern den SOCKS5-Proxy-Server (Standard 127.0.0.1:8119).

Für eine unverschlüsselte http://-Anfrage wickelt der HTTP-Proxy-Server pro Verbindung genau einen Anfrage-Antwort-Austausch ab: Jede Antwort geht mit Connection: close hinaus, danach wird die Verbindung geschlossen, und der Client sendet seine nächste Anfrage über eine neue Verbindung. Eine hinter der ersten per Pipelining gesendete Anfrage wird verworfen; der Client sendet sie auf der neuen Verbindung erneut. Ein Authentifizierungsverfahren, das mehrere Durchgänge auf derselben Verbindung braucht, etwa NTLM oder Negotiate, kann darüber nicht abgeschlossen werden. Ein nicht entschlüsselter CONNECT-Tunnel ist davon nicht betroffen. Ein WebSocket-Upgrade behält seine Verbindung: Nach der 101-Antwort laufen die Daten in beide Richtungen unverändert durch.

Kompatibilitäts-Aliase: doh-server und doh-service werden als Aliase von doh akzeptiert; http-listen / socks5-listen (z. B. 0.0.0.0:6152, [::]:6153 oder ein bloßer Port) werden auf die obigen interface/port-Einstellungen abgebildet. Ein Wildcard-Listen-Host (0.0.0.0, :: oder *) setzt außerdem allow-wifi-access = true.

Eingehende Proxy-Authentifizierung

http-auth = username:password

Erfordert, dass sich Clients authentifizieren, bevor sie die HTTP- und SOCKS5-Proxy-Server von Chute verwenden. Die Zeile kann wiederholt werden, um mehrere Anmeldedaten zu erlauben.

Der HTTP-Proxy beantwortet eine Anfrage ohne gültige Anmeldedaten — eine gewöhnliche Anfrage ebenso wie ein CONNECT — mit 407 Proxy Authentication Required und Proxy-Authenticate: Basic realm="KLNEKit" und schließt dann die Verbindung. Der SOCKS5-Server nimmt dieselben Anmeldedaten über die Benutzername/Passwort-Authentifizierung von SOCKS5 entgegen und schließt eine Verbindung, die diese nicht anbietet oder daran scheitert.

Systemanfragen umgehen

bypass-system = true

Wenn aktiviert, hängt Chute eine feste Liste von 18 Apple-Hostnamen — Push, iCloud-Gateway, Captive-Portal-Prüfung, OCSP und ähnliche — an skip-proxy an und hängt IP-CIDR,17.0.0.0/8,DIRECT,no-resolve hinter Ihre Regeln an, unmittelbar vor FINAL — eine eigene Regel, die 17.0.0.0/8 zuerst trifft, hat also weiterhin Vorrang. Es gibt keine prozessbasierte Zuordnung: Die Option ist genau diese feste Host- und Adressliste, kein Filter darauf, welcher Prozess die Anfrage gestellt hat.

Standard: true.

Immer echte IP

always-real-ip = *.example.com, tracker.example.org

Wenn Chute gefälschte IP-Adressen für gekaperte DNS-Abfragen bereitstellt (siehe hijack-dns), werden Hostnamen, die dieser durch Kommas getrennten Liste entsprechen, immer mit ihren echten aufgelösten IP-Adressen beantwortet. Wildcards werden unterstützt. always-ip-address (Shadowrockets Schreibweise) wird als dieser Schlüssel gelesen: Ein boolescher Wert (true, yes, on, 1) meint jeden Host und wird zu always-real-ip = * umgeschrieben; false wird verworfen; jeder andere Wert wird als Hostliste gelesen. Gespeichert wird die Konfiguration mit der Schreibweise always-real-ip.

System-Hosts-Datei lesen

read-etc-hosts = false

Legt fest, ob die Hosts-Datei des Systems in die [Host]-Tabelle eingelesen wird. Setzen Sie den Wert auf false, um diese Datei zu ignorieren; eine Änderung wird beim Neuladen wirksam. Siehe Lokale DNS-Zuordnung.

Standard: true.

Bestehende Verbindungen unterbrechen

interrupt-exist-connections = true

Wenn aktiviert, werden beim Ändern der ausgewählten Richtlinie in einer beliebigen Richtliniengruppe (über URL-Test, Fallback, Load-Balance, SSID oder manuelle Auswahl) bestehende Verbindungen, die die alte Richtlinie verwendeten, ordnungsgemäß beendet. Dies stellt sicher, dass Verbindungen sofort den neu ausgewählten Proxy verwenden, anstatt auf dem alten zu verweilen.

Das gilt für jede Richtliniengruppe, die eine Verbindung durchläuft: die Gruppe, die ihre Regel nennt, eine darin verschachtelte Gruppe, die Upstream-Gruppe einer verketteten Richtlinie (underlying-proxy) und die Mitgliedsgruppen einer Relay-Gruppe.

Jede betroffene Verbindung wird ordnungsgemäß mit einer 3-Sekunden-Zeitüberschreitung geschlossen, bevor sie zwangsweise getrennt wird.

Standard: false. Dies ist eine globale Einstellung — sie betrifft alle Richtliniengruppen.

Network Framework (macOS / iOS / tvOS)

network-framework = true

Aktiviert Apple Network.framework für ausgehende Verbindungen. Die Verwendung von Network.framework kann eine bessere Leistung und moderne TLS-Stack-Integration auf unterstützten Plattformen bieten.

Standard: true auf macOS, false auf iOS und tvOS.

Einfache Hostnamen ausschließen

exclude-simple-hostnames = true

Wenn aktiviert, umgehen Anfragen an einfache Hostnamen (einzelne Bezeichnungen ohne Punkt, z. B. localhost) die Proxy-Regeln und werden lokal aufgelöst. Dies hilft, unnötige DNS-Abfragen für lokale Netzwerknamen zu vermeiden. Dies ist die Einstellung „Einfache Hostnamen ausschließen“ des macOS-Systemproxys selbst: Chute Mac schreibt sie in die Systemproxy-Konfiguration, sie gilt also nur für Anwendungen, die dem Systemproxy folgen — nicht für den Erweiterten Modus oder TUN-Verkehr. Unter iOS und tvOS wird sie auf dieselbe Weise in die Proxy-Einstellungen des Tunnels geschrieben; ein einfacher Hostname wird dann von Chute TUN statt von Chute Proxy verarbeitet, wie ein Hostname in skip-proxy. Chute Android verwendet sie nicht.

Auf Chute Mac aktiviert eine einmalige Migration diese Option beim ersten Start standardmäßig; eine explizite Aus-Einstellung des Benutzers wird respektiert.

Standard: false.

Datenbankaufzeichnung deaktivieren

disable-db-record = true

Wenn aktiviert, stoppt Chute das Schreiben von Verkehrsaufzeichnungen in die lokale Datenbank. Dies kann die Leistung verbessern und die Speichernutzung reduzieren, jedoch ist der Verkehrsverlauf dann im Chute Dashboard nicht verfügbar.

Standard: false.

Geschwindigkeitsanzeige in der Menüleiste (Nur Mac)

menu-bar-show-speed = true

Wenn aktiviert, zeigt Chute Mac die aktuelle Upload- und Download-Geschwindigkeit in der Menüleiste an.

Wird geparst, von der aktuellen Engine aber nicht angewendet — nichts in Chute Mac liest diesen Schlüssel. Die Geschwindigkeit in der Menüleiste wird über den Menüeintrag Verbindungsgeschwindigkeit anzeigen geschaltet, der in den eigenen Einstellungen der App abgelegt ist. Der Schlüssel wird beim Speichern der Konfiguration weiterhin zurückgeschrieben.

Andere DNS-Server kapern

hijack-dns = 8.8.8.8:53

Standardmäßig gibt Chute nur gefälschte IP-Adressen für DNS-Abfragen zurück, die an die Chute-DNS-Adresse (198.18.0.2) gesendet werden. Abfragen, die an Standard-DNS gesendet werden, werden einfach weitergeleitet.

Einige Geräte oder Software verwenden immer einen fest codierten DNS-Server. (Zum Beispiel verwenden Google Speakers immer 8.8.8.8). Sie können diese Option verwenden, um die Abfrage zu kapern und eine gefälschte Adresse zu erhalten.

Sie können hijack-dns = *:53 verwenden, um alle DNS-Abfragen zu kapern.

Ein Eintrag ohne Port meint Port 53, hijack-dns = 8.8.8.8 ist also 8.8.8.8:53. Ein Eintrag, der sich nicht lesen lässt, wird mit einem Hinweis übersprungen; der Rest der Zeile gilt weiterhin.

Fake IP ist auch auf Apple TV verfügbar (tvOS 17 und neuer). Es war dort deaktiviert; die Überprüfung auf einem Gerät läuft noch.

Ausgeschlossene Routen

tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12

Chute VIF kann nur TCP- und UDP-Protokolle verarbeiten. Verwenden Sie diese Option, um bestimmte IP-Bereiche zu umgehen, damit der gesamte Verkehr durchgelassen wird.

Hinweis: Diese Option gilt für die Packet-Tunnel unter iOS und tvOS, wo die Bereiche zu ausgeschlossenen Routen der IP-Einstellungen des Tunnels werden, sowie für Chute Android ab Android 13, wo sie zu ausgeschlossenen Routen des VPN werden — Android 11 und 12 bieten keine Schnittstelle für ausgeschlossene Routen, dort werden die Bereiche ignoriert. Unter macOS hat sie keine Auswirkung, in keinem der beiden Typen des Erweiterten Modus — weder das utun des Helfers noch die Mac-Netzwerkerweiterung schließt irgendeine Route aus. Anfragen, die vom Chute Proxy Server verarbeitet werden, sind nicht betroffen. Kombinieren Sie 'skip-proxy' und 'tun-excluded-routes', um sicherzustellen, dass bestimmter HTTP-Verkehr Chute umgeht.

Diese Option könnte einen Systemfehler ENOMEM (Cannot allocate memory) verursachen. Es scheint ein Fehler im iOS-System zu sein. Bitte verwenden Sie diese Option nach Möglichkeit nicht.

Eingeschlossene Routen

tun-included-routes = 192.168.1.12/32

Standardmäßig deklariert sich die Chute-VIF-Schnittstelle als Standardroute. Da die WLAN-Schnittstelle jedoch eine kleinere Route hat, kann ein Teil des Verkehrs möglicherweise nicht über die Chute-VIF-Schnittstelle laufen. Verwenden Sie diese Option, um eine kleinere Route hinzuzufügen.

Warum eine Standardroute nicht genügt: Das System wählt eine Route nach Präfixlänge, nicht nach Reihenfolge. Das eigene On-Link-Subnetz der physischen Schnittstelle — etwa 192.168.1.0/24 — ist spezifischer als das 0.0.0.0/0 des Tunnels, dieser Verkehr erreicht Chute also nie. Ein Eintrag hier installiert eine noch spezifischere Route und gewinnt. Die Routen kommen zur Standardroute hinzu und schränken niemals ein, was der Tunnel erfasst.

Hinweis: Führen Sie die privaten Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) nicht pauschal auf. Das ist normalerweise unnötig und kann das Routing des Systems durcheinanderbringen; Chute befolgt einen solchen Eintrag, protokolliert aber eine Warnung — außer in der Variante „Network Extension“ des Erweiterten Modus unter macOS, die ihn ohne Warnung befolgt. Der übliche Grund für diese Option ist, einen Bereich zu erreichen, der dem Tunnel einer anderen VPN-App gehört.

Hinweis: Ein Eintrag, der den Ast absägen würde, auf dem Chute sitzt, wird abgelehnt, mit der Begründung im Protokoll: Loopback, die eigenen Subnetze des VIF (198.18.0.0/15 und fd12:1:1:1::/64), Link-Local, Multicast, Broadcast sowie eine Präfixlänge von 0. Die Variante „utun des Helfers“ des Erweiterten Modus unter macOS lehnt zusätzlich einen Eintrag ab, der das aktuelle Standard-Gateway abdeckt. In der Variante „Network Extension“ landet die Begründung im Systemprotokoll statt in dem von Chute.

Hinweis: Auf dem iPhone entscheidet das System getrennt darüber, ob das lokale Netzwerk erfasst wird. Ein hier aufgeführtes lokales Subnetz wird nur berücksichtigt, wenn in den Einstellungen der App zusätzlich Lokale Netzwerke einbeziehen aktiv ist — ein Schalter, der sich nur einschalten lässt, solange Alle Netzwerke einbeziehen aktiv ist; ein Bereich, der dem Tunnel einer anderen App gehört, braucht keinen solchen Schalter. Chute tvOS zeigt dieselben Schalter, wendet sie aber nicht auf den Tunnel an. Unter macOS werden die Routen direkt installiert, dort gibt es keine solche Hürde.

Hinweis: Unter macOS installiert die Variante „utun des Helfers“ des Erweiterten Modus diese Routen, sobald die Schnittstelle angehängt wird; eine geänderte Liste hängt die Schnittstelle beim Neuladen also erneut an. Diese Option setzt Helfer-Version 0.8.6 oder neuer voraus — genehmigen Sie nach einem Update von Chute einmal die Abfrage zur Neuinstallation des Helfers, sonst meldet die Variante „utun des Helfers“, dass der Helfer nicht läuft.

Protokollerkennung

sniffing-enabled = true
sniffing-timeout = 100

Chute kann das tatsächliche Protokoll einer Verbindung erkennen, indem es die ersten Bytes untersucht. Dies ermöglicht, dass Regeln wie PROTOCOL,TLS,Proxy auch für eingehende Nicht-HTTP-Verbindungen korrekt funktionieren.

sniffing-enabled (Standard: false)

sniffing-enabled = true

Aktiviert die Protokollerkennung für TCP-Verbindungen. Im Erweiterten Modus erlaubt derselbe Schalter, einen HTTP/3-(QUIC-)Datenstrom zu einer nackten IP-Adresse nach Namen zu behandeln: Chute liest den Servernamen aus dem QUIC-ClientHello, DOMAIN-Regeln sehen diesen Namen statt der Adresse, und jedes weitere Paket des Datenstroms folgt dem Urteil des ersten. Ein ClientHello, das nicht in ein Paket passt — bei Post-Quanten-Schlüsselaustausch üblich —, wird je Datenstrom aus den Initial-Paketen, die es tragen, wieder zusammengesetzt, bis zu einem zusammengesetzten Hello von 16 KiB, sodass auch sein Name gelesen wird. Solange der Rest des Hellos noch aussteht, werden die Datagramme des Datenstroms zurückgehalten, statt mit ihrer nackten Adresse gesendet zu werden, und gehen gemeinsam hinter dem Namen hinaus, sobald dieser gelesen ist — das erste Fragment eines geteilten Hellos nimmt also nicht mehr einen anderen Weg als der Rest. Die Sicherungen sind eine Wartezeit von einer Sekunde, acht Datagramme oder 16 KiB je Datenstrom sowie 64 gleichzeitig zusammengesetzte Datenströme; ein Datenstrom jenseits davon — oder einer, dessen Initial-Pakete das ClientHello nie vervollständigen — wird wie bisher nach Adresse behandelt.

sniffing-timeout (Standard: 100ms)

sniffing-timeout = 200

Maximale Zeit in Millisekunden, um auf die ersten Daten zur Protokollbestimmung zu warten. Erhöhen Sie diesen Wert, wenn die Protokollerkennung bei langsamen Verbindungen fehlschlägt.

QUIC blockieren

block-quic = auto

Steuert, ob Chute erkannten QUIC-Datenverkehr einschließlich HTTP/3 abweist. QUIC läuft über UDP und kann durch Chutes HTTP-MitM nicht entschlüsselt werden. Das Abweisen von QUIC kann kompatible Clients dazu veranlassen, die Verbindung über TCP erneut aufzubauen. Dadurch können die TCP-basierte Proxy-Verarbeitung und, sofern konfiguriert, die HTTPS-Entschlüsselung angewendet werden.

Bei über TUN eingehendem Datenverkehr antwortet Chute auf einen abgewiesenen QUIC-Datenstrom mit einer ICMP/ICMPv6-Port-Unreachable-Meldung. Kompatible Clients können dadurch auf TCP zurückfallen, ohne auf einen QUIC-Timeout zu warten.

Ein abgewiesener QUIC-Datenstrom wird mit REJECT als Richtlinie aufgezeichnet, gleich welche Richtlinie die Regel gewählt hat.

Die QUIC-Erkennung für block-quic erfolgt automatisch und benötigt sniffing-enabled nicht. sniffing-enabled steuert die Protokollerkennung — TLS auf TCP und den Servernamen eines QUIC-Datenstroms. Verwenden Sie eine Regel vom Typ PROTOCOL,QUIC,..., um einzelne QUIC-Datenströme regelbasiert zu behandeln.

ICMP im Tunnel beantworten

icmp-auto-reply = false

Eine ICMP-Echo-Anfrage, die in den Tunnel gelangt — IPv4 wie IPv6 —, beantwortet Chute selbst: Die Antwort entsteht lokal, und an das Ziel wird nichts gesendet. Deshalb antwortet jedes Ziel, auch eine Adresse, die eine Regel mit REJECT belegen würde, und ein Host, der nicht erreichbar ist — ein erfolgreicher ping im Tunnel sagt also nichts darüber aus, ob das Ziel erreichbar ist. Auf false gesetzt, wird nicht mehr geantwortet: Die Anfrage wird dann aus dem Gerät hinausgeleitet, ihre Antwort kommt aber nie durch den Tunnel zurück, sodass der Ping nie beantwortet wird.

Standard: true. Gilt für Verkehr, der über TUN eintrifft; ICMP wird nie über einen Proxy geleitet.

TUN umgehen

bypass-tun = 192.168.0.0/16, 10.0.0.0/8

Ähnlich wie skip-proxy, arbeitet jedoch auf der TUN/VIF-Routing-Ebene. Verbindungen zu diesen IP-Bereichen umgehen die TUN-Schnittstelle vollständig und gehen direkt durch den Systemnetzwerkstack.

Hinweis: Diese Option gilt für die Packet-Tunnel unter iOS und tvOS, wo ihre Bereiche zusammen mit tun-excluded-routes zu ausgeschlossenen Routen des Tunnels werden, und ebenso für Chute Android ab Android 13 (Android 11 und 12 ignorieren sie). Unter macOS hat sie keine Auswirkung, in keinem der beiden Typen des Erweiterten Modus.

Fehlerseite für Ablehnung anzeigen

show-error-page-for-reject = true

Wenn aktiviert, gibt Chute eine benutzerfreundliche Fehlerseite für abgelehnte Anfragen zurück. Das gilt nur für eine Anfrage, die über den HTTP-Proxy-Eingang eingetroffen ist; ist die Option aus, wird eine solche Anfrage stattdessen mit HTTP/1.1 503 Service Unavailable beantwortet. Eine abgelehnte Anfrage aus jedem anderen Eingang wird so oder so verworfen.

Standard: false.

Optimistisches DNS

optimistic-dns = false

Wenn aktiviert, gibt Chute das zwischengespeicherte DNS-Ergebnis sofort zurück, während der Eintrag im Hintergrund aktualisiert wird. Dies reduziert die Verbindungslatenz auf Kosten möglicherweise veralteter DNS-Einträge. Ist sie aus, wird ein Eintrag, dessen TTL abgelaufen ist, verworfen statt ausgeliefert, und die Abfrage geht zum Upstream; die Aktualisierung erfolgt trotzdem, sodass die nächste Abfrage aus dem Cache beantwortet wird. Sie steuert außerdem — auf jeder Plattform —, ob der Tunnel mehrere Adressen eines Namens gleichzeitig anwählt.

Standard: true. Setzen Sie optimistic-dns = false zum Deaktivieren.

WLAN-Zugriff erlauben

allow-wifi-access = true

Erlaubt anderen Geräten im selben Netzwerk den Zugriff auf Chutes HTTP- und SOCKS5-Proxy-Ports, indem beide Listener auf 0.0.0.0 erweitert werden. Konfigurationen im Surge-Stil — und die allow-lan-Zuordnung des sing-box-Imports — führen nur dieses Flag und belassen interface beim Standard 127.0.0.1; deshalb muss das Flag die Bind-Adresse selbst erweitern.

Das Flag und ein ausdrückliches Wildcard-interface sind zwei Schreibweisen derselben Absicht, und Chute bildet die Vereinigung: Eine Konfiguration, die bereits 0.0.0.0 schreibt, verhält sich unverändert. Eine Änderung des Flags bindet beide Listener neu, ein Entzug des Zugriffs wirkt also beim Neuladen statt erst beim nächsten Start.

Dies sind die Proxy-Ports, und sie haben keine Authentifizierung, solange http-auth nicht gesetzt ist. Setzen Sie in einem fremden Netzwerk zusätzlich Zugangsdaten.

Verwaltete Konfiguration

#!MANAGED-CONFIG https://example.com/config.conf interval=86400 strict=false

Eine Konfiguration, deren erste Zeile ein #!MANAGED-CONFIG-Header ist, wird automatisch von der URL neu abgerufen. Die Header-Parameter und das Aktualisierungsverhalten sind unter Verwaltete Konfiguration dokumentiert.

Replikat / Datenverkehrsaufzeichnung

replica = true

Der Schlüssel replica in [General] (replica = true) aktiviert die Datenverkehrsaufzeichnung; der Abschnitt [Replica] filtert, was das Chute Dashboard anzeigt — seine Schlüssel sind unter Replikat dokumentiert.

Unter iOS, tvOS und Android ist zusätzlich eine aktive Lizenz erforderlich: Ohne sie zeichnet replica = true nichts auf.

Externer Controller-Zugriff (Chute Dashboard)

external-controller-access = password@0.0.0.0:6155

Startet den Fernsteuerungsserver, der von Chute Dashboard verwendet wird. Der Wert ist password@host:port; ein Benutzername kann optional dem Passwort vorangestellt werden (user:password@host:port). Auf iOS und tvOS wird ein begleitender USB-Kanal auf port + 1 geöffnet (nicht auf macOS). Wie Sie Chute Dashboard verbinden, steht auf der Seite Chute Dashboard.

HTTP-Control-API und Web-Konsole

[General]
external-http-controller = 127.0.0.1:9090
external-http-secret = your-secret-token
external-http-ui = true
external-http-cors = false

Chute bietet eine eingebettete HTTP-Control-API und eine Web-Konsole, ähnlich wie Clash- und Surge-Dashboards. Die API stellt Engine-Status, Verkehr, Verbindungen, DNS, Richtliniensteuerungen und Konfigurationsverwaltung über REST-Endpunkte bereit.

Surges http-api = <secret>@<host>:<port> wird als external-http-controller plus external-http-secret gelesen. Ein Profil darf die Teile auch getrennt schreiben: http-api-secret, http-api-ui und http-api-cors werden als external-http-secret, external-http-ui und external-http-cors gelesen, http-api-web-dashboard ebenfalls als external-http-ui; gespeichert wird die Konfiguration mit den external-http-*-Schlüsseln. http-api-tls wird nicht unterstützt — der Controller spricht unverschlüsseltes HTTP — und erzeugt nur einen Hinweis.

external-http-controller (Standard: deaktiviert)

external-http-controller = 127.0.0.1:9090

Die Anfragen, die die Konsole während des Betriebs im Speicher hält, sind auf 4 MB unter macOS und 1 MB unter iOS, tvOS und Android begrenzt.

Adresse und Port des HTTP-Controllers. Für rein lokalen Zugriff 127.0.0.1 verwenden. Eine Bindung an eine Adresse außerhalb von Loopback (etwa 192.168.1.5:9090) verlangt ein ausdrückliches external-http-secret — ohne dieses verweigert der Server den Start und protokolliert, was fehlt.

Eine Wildcard-Adresse (0.0.0.0, ::, *) gilt bei dieser Prüfung als nicht-Loopback: Sie lauscht auf allen Schnittstellen, also dem Gegenteil von „nur lokal“. Akzeptierte Schreibweisen sind 0.0.0.0:9090, *:9090 (dasselbe) und für IPv6 [::]:9090 — ein nacktes :::9090 wird automatisch eingeklammert; eine Adresse, die sich nicht parsen lässt, wird als Konfigurationsfehler gemeldet, statt den Controller stillschweigend ausgeschaltet zu lassen. Als Loopback gilt der gesamte Bereich 127.0.0.0/8, nicht nur 127.0.0.1.

external-http-secret (Standard: ein generiertes Token)

external-http-secret = your-secret-token

Das Bearer-Token für die API-Authentifizierung. Anfragen müssen den Header Authorization: Bearer <secret> enthalten — das Token wird nur in diesem Header angenommen, nie als Query-Parameter, und in konstanter Zeit verglichen. Fehlgeschlagene Authentifizierung liefert 401 mit {"ok": false, "error": {"code": "unauthorized", "message": "missing or invalid token"}}. Geschützt ist jede Datenroute: /api/*, die Clash-kompatiblen Aliase und die älteren Routen, die nur noch Chute Android anbietet (/status, /policies, /dns, /records und ähnliche) — auch sie nehmen das Token nur in diesem Header an. Das eigene Remote-Dashboard von Chute Android nutzt inzwischen nur noch die /api/*-Pfade. Die Seite und die statischen Dateien der Web-Konsole (/, /assets/…, unter Chute Android zusätzlich /ui) brauchen kein Token (mit external-http-ui = false gibt es sie gar nicht — die Seite ist ein 404).

Fehlt der Schlüssel, erzeugt Chute ein Token, statt ohne Authentifizierung auszuliefern. Das erzeugte Token wird in eine Datei control-token in Chutes Share-Ordner geschrieben — nicht neben die Konfiguration: der App-Group-Container auf iOS und tvOS, das private Datenverzeichnis der App auf Android —, lesbar nur für den Eigentümer, über Neustarts hinweg weiterverwendet, und die Apps zeigen es an — siehe Web-Konsole öffnen. Die Control-API kann die Verbindungsdatenbank herausgeben, deren Einträge jede URL, jeden Header und jeden Prozessnamen dieses Laufs enthalten; ein offener Controller ist keine vertretbare Voreinstellung.

Wenn Sie trotzdem ohne Authentifizierung ausliefern wollen, sagen Sie es in der Konfiguration:

external-http-secret = none

Das wird nur bei einer Loopback-Bindung akzeptiert. Außerhalb von Loopback genügt weder none noch ein fehlender Schlüssel: Der Controller verweigert den Start und nennt, was er braucht.

Beim Upgrade: Wenn Sie sich darauf verlassen haben, dass ein fehlendes external-http-secret „keine Authentifizierung“ bedeutet, erhalten lokale Skripte künftig 401. Lesen Sie entweder das erzeugte Token in der App aus, oder schreiben Sie external-http-secret = none, um das alte Verhalten bewusst beizubehalten.

external-http-ui (Standard: true)

external-http-ui = true

Wenn aktiviert, stellt Chute eine eingebettete Web-Konsole unter der Controller-Adresse bereit. Die Web-Konsole bietet eine Übersicht, Verbindungsverwaltung, DNS-Inspektion, Verkehrsüberwachung, Richtliniensteuerungen und Konfigurationsbearbeitung. Setzen Sie auf false, um die API aktiviert zu lassen, während die UI deaktiviert wird.

Die Web-Konsole öffnen

Die Konsole wird unter der Adresse des Controllers ausgeliefert, und jede App kann Ihnen Adresse und Token übergeben — auch das generierte Token, das Sie sonst gar nicht lesen könnten:

• Chute Mac: Menüleiste → Web-Konsole öffnen und Web-Konsolen-Token kopieren. Das Detailfenster einer Verbindung hat zusätzlich Anfragen & Verlauf, das ebenfalls die Konsole öffnet — ihre Startseite, nicht diese Verbindung.
• Chute iOS: Bedienfeld → Zeile „Web-Konsole“ → Öffnen, Adresse kopieren oder Zugriffstoken kopieren.
• Chute tvOS: Das Bedienfeld hat eine eigene Zeile Adresse der Web-Konsole, die Host und Port zeigt. Sie auszuwählen zeigt einen QR-Code, wenn der Listener von anderen Geräten erreichbar ist — das Anmelde-Token steckt im Code, nicht auf dem Bildschirm —, und, wenn der Controller an Loopback gebunden ist, stattdessen eine Erklärung, weil sich eine Loopback-Konsole nicht vom Telefon aus öffnen lässt.
• Chute Android: Bedienfeld → Adresse der Web-Konsole → Öffnen oder Adresse kopieren, dazu eine Zeile Generiertes Zugriffstoken, die beim Antippen kopiert. Keine der beiden Zeilen erscheint, wenn das Token ein selbst konfiguriertes Secret ist; ein solches wird nie angezeigt.

Die so erzeugte Adresse trägt das Token als Query-Parameter. Die Seite verbraucht es beim Laden und entfernt es aus der Adresszeile, sodass das Öffnen des Links eine vollständige Anmeldung ist und niemand 32 Hex-Zeichen abtippen muss.

external-http-cors (Standard: false)

external-http-cors = true

Aktiviert CORS (Cross-Origin Resource Sharing)-Header auf API-Antworten. Nützlich, wenn die Web-Konsole oder Drittanbieter-Tools von einem anderen Origin auf die API zugreifen müssen.

API-Endpunkte:

Endpunkt-Hinweise:

• GET /api/connections akzeptiert limit (positive Ganzzahl, Standard und Maximum 1000) und cursor (liefert nur Verbindungen mit einer id größer als der Cursor). Das Antwortfeld data enthält connections, total, page_size, has_more und — wenn weitere Seiten existieren — next_cursor.
• GET /api/connections/history akzeptiert limit (Standard 100, Maximum 1000) und cursor/before (Synonyme; beide zugleich zu übergeben wird abgelehnt).
• GET /api/connections/:id/request und .../response liefern {"connection_id": <id>, "data": "<base64>"}. Mitschnitte größer als 2 MiB liefern 413.
• GET /api/config liefert die Konfiguration mit sensiblen Werten (http-auth, external-http-secret, ca-p12, ca-passphrase, WireGuard-Schlüssel und ähnliche) ersetzt durch <redacted> — geben Sie das Ergebnis nicht unverändert an PUT /api/config zurück, sonst werden die Platzhalter wörtlich in die Konfiguration geschrieben.
• GET und PUT /api/config sind auch unter /api/configs erreichbar sowie unter dem Clash-Alias /configs.
• PUT /api/config akzeptiert entweder JSON {"configuration": "<full text>"} oder den rohen Konfigurationstext als Request-Body (Limit 1 MB). Bei Erfolg lädt die Engine neu — oder startet, falls sie nicht lief.
• PUT /api/policies/:group übernimmt die Auswahl aus dem ersten vorhandenen der Body-Schlüssel policy, name, selected, select; der Wert kann ein Richtlinienname oder ein numerischer Index als String sein. Der spezielle Gruppenname GLOBAL setzt die global ausgewählte Richtlinie.
• PUT /api/mode erfordert eine JSON-Zahl: {"mode": 0} — 0 Regel, 1 direkt, 2 Proxy.
• PUT /api/features/mitm und PUT /api/features/record-traffic nehmen {"enabled": true} entgegen.
• GET /api/logs akzeptiert since (Unix-Sekunden); der In-Memory-Puffer behält die letzten 1000 Einträge, jeder als {timestamp, wall_time, level, section, message} — timestamp und wall_time tragen denselben Wert in Unix-Sekunden, der vorgerückt wird, wenn die Uhr nicht weiterläuft, damit die Einträge streng geordnet bleiben.
• GET /api/health meldet, was die Engine gerade hält und warum sie zuletzt etwas abgewiesen hat, sowie wie der vorherige Lauf endete (clean, unclean oder suspected_memory — siehe Fehlerbehebung).
• GET /api/events liefert den Ringpuffer im Speicher; ?persisted=1 liest stattdessen den gespeicherten Verlauf dieses Laufs und antwortet mit available: false, wenn die Aufzeichnung aus ist.
• Ohne [Tailscale]-Abschnitt antwortet GET /api/tailscale mit state: "idle" — das ist eine normale Antwort, kein Fehler.
• Die Prüfungen unter POST /api/diagnostics/* nehmen ihre Argumente aus der Query oder einem JSON-Body, sind auf zehn Sekunden begrenzt und antworten genau einmal. url-test/:policy weist einen nicht definierten Richtliniennamen zurück, statt REJECT zu messen.
• GET /api/scripts listet die aktivierten generischen Skripte als {name, type}; POST /api/scripts/run nimmt name aus dem Body oder der Query, ist wie die Diagnoseprüfungen begrenzt und antwortet mit {name, timedOut, result} — timedOut unterscheidet ein Skript, das $done nie aufgerufen hat, von einem, das durchgelaufen ist. Ein Name, der kein aktiviertes generisches Skript ist, ergibt 404.
• POST /api/rules/match beantwortet, wohin eine Anfrage ginge, ohne eine Verbindung zu öffnen. Es nimmt host (oder eine url, aus der Host und Port stammen; eine URL-REGEX-Regel wird gegen diese url genau so geprüft, wie sie geschrieben ist, auch wenn sie im echten Verkehr nur schlichte http://-Anfragen sieht), port (Standard 443) sowie optional ip, protocol, process, process_path, src_ip, src_port, in_port, in_type, in_user, in_name, network, ssid, bssid, from_tun, user_agent — ein unbekanntes Feld wird mitsamt der Liste der zulässigen zurückgewiesen statt ignoriert. Die Antwort trägt die matched-Regel (ihre Zeile, ihren Typ, die von ihr benannte Richtlinie und die resolved_policy, auf die eine Gruppe gerade zeigt), die policy, need_resolve sowie rule_count und match_generation, gegen die gerechnet wurde. Da eine Domain zweimal abgeglichen wird — einmal über den Namen und noch einmal, sobald eine Adresse bekannt ist —, enthält passes einen Eintrag je Durchgang; ohne ip gibt es nur den Durchgang vor der Auflösung, und die Antwort sagt das in note. Mit explain=true kommen die Kandidatenregeln dazu, die ebenfalls hätten passen können, bis zu 50, mitsamt der Zahl der nicht aufgeklappten Regelsätze.
• POST /api/config/validate parst eine Konfiguration und wirft sie weg: Die laufende Engine übernimmt nichts davon. Schicken Sie sie als {"configuration": "<full text>"} oder als rohen Text. Die Antwort besteht aus valid, error_count, advisory_count, rule_count, policy_count und einer errors-Liste aus {line, severity, content, error} — severity trennt eine abgelehnte Zeile von einer mit Vorbehalt akzeptierten, und content ist die beanstandete Zeile in geschwärzter Form, denn eine fehlerhafte [Proxy]-Zeile trägt meist genau das Passwort, das sie fehlerhaft gemacht hat. Verwenden Sie es vor PUT /api/config, das den Lauf neu startet, den Sie gerade untersuchen.
• GET /api/loglevel meldet das aktuelle level, das nslog_level, die in die Datei geschriebenen sections sowie die available_levels / available_sections, die Sie setzen dürfen. PUT (oder PATCH) nimmt level, sections oder beides: sections ist ein Array von Abschnittsnamen oder die Zeichenkette "all", ein leeres Array wird abgelehnt — zum Abschalten der Protokollierung nehmen Sie level mit none. Die Stufe auf diesem Weg zu ändern startet den Lauf nicht neu, und genau darum geht es: loglevel = verbose in der Datei braucht ein Neuladen, und ein Neuladen verliert das, was Sie sehen wollten.
• GET /api/rules meldet zusätzlich rewrite_hits: jede Umschreibungs- oder Mock-Antwort-Regel, die in diesem Lauf gegriffen hat, mit Zähler. Eine Regel, die dort nicht auftaucht, hat nie gepasst — das ist die übliche Erklärung für eine Umschreibung, die scheinbar nichts tut. Die Tabelle verfolgt bis zu 512 verschiedene Regeln und meldet alles darüber hinaus als rewrite_hit_dropped_rules. rules listet jede Regel, die der Matcher durchläuft, in Reihenfolge: zuerst die automatischen Tailscale-Regeln, dann Modulregeln, dann den Abschnitt [Rule] der Konfiguration, zuletzt FINAL; rule_regions nennt zu jedem Index die Herkunft der Zeile (front, module, configuration).
• POST /api/rewrites/:family nimmt {"rule": "<configuration line>"} — genau den Text, den Sie in die Datei schreiben würden. Eine Zeile, die sich nicht parsen lässt, wird mit 400 abgewiesen statt als Regel gespeichert, die nie passen kann. :family ist eines von url-rewrite, header-rewrite, body-rewrite, mock. So hinzugefügte Regeln leben nur in der laufenden Engine und werden nicht in die Konfigurationsdatei zurückgeschrieben.
• GET /api/connections/export?format=har liefert ein HAR-1.2-Dokument, POST /api/diagnostics/bundle ein ZIP — beides sind Dateien und werden deshalb, anders als jeder andere Endpunkt, nicht in {"ok": ..., "data": ...} verpackt. export akzeptiert source (current als Standard oder history), limit (Standard 100, höchstens 300), ids sowie bodies=1, um die aufgezeichneten Nutzdaten mitzugeben. Jeder Eintrag trägt ein _kl-Objekt mit dem, wofür HAR kein Feld hat: gewählte Richtlinie, passende Regel und die Umschreibungen, die gegriffen haben.
• Der Eintrag einer verketteten Verbindung in GET /api/connections und GET /api/connections/history enthält chainPath, den Weg von diesem Gerät bis zum Ausgang, etwa Airport/HK-01 → Landing; bei einer Verbindung über eine einzige Richtlinie ist er leer, und der HAR-Export führt ihn als _kl.chain. In den Zählern je Richtlinie von GET /api/traffic zählt auch ein Upstream die Bytes, die er für verkettete Verbindungen getragen hat; die globalen Summen zählen sie einmal.

Beispiel — den Status lesen, dann eine Richtliniengruppe umschalten:

curl -H "Authorization: Bearer your-secret-token" http://127.0.0.1:9090/api/status
{"ok":true,"data":{"running":true,"outbound_mode":0,"mitm":false, ...}}

curl -X PUT -H "Authorization: Bearer your-secret-token" \
     -d '{"policy": "ProxyB"}' http://127.0.0.1:9090/api/policies/MainGroup
{"ok":true,"data":{"outbound_mode":0,"selectable_groups":[...], ...}}

Beispiel — fragen, wohin eine Anfrage ginge, bevor man sie stellt:

curl -X POST -H "Authorization: Bearer your-secret-token" \
     -d '{"url": "https://api.example.com/v1/orders", "explain": true}' \
     http://127.0.0.1:9090/api/rules/match
{"ok":true,"data":{"policy":"MainGroup","matched":{"rule":"DOMAIN-SUFFIX,example.com,MainGroup", ...}, ...}}

Das Protokoll beim Reproduzieren auf ein Teilsystem eingrenzen, ohne den Lauf neu zu starten:

curl -X PUT -H "Authorization: Bearer your-secret-token" \
     -d '{"level": "verbose", "sections": ["MitM", "DNS"]}' \
     http://127.0.0.1:9090/api/loglevel

Hinweis: Diese Funktion ist standardmäßig deaktiviert. Jede Antwort verwendet den Umschlag {"ok": true, "data": {...}} bei Erfolg und {"ok": false, "error": {"code": "...", "message": "..."}} bei Fehlern; Request-Bodys sind auf 1 MB begrenzt.

PUT-Endpunkte akzeptieren auch PATCH. Für Dashboards von Drittanbietern stehen Clash-kompatible Alias-Pfade zur Verfügung: /version, /traffic, /connections, /configs, /proxies, /rules — die Pfade sind erreichbar, aber die Antworten verwenden Chutes Umschlag und Feldnamen statt des Clash-Schemas (/version liefert {"name", "run_id", "egress_probe"}, wobei egress_probe auf den Apple-Engines network_address und auf Android egress_ip ist), Clash-Dashboards funktionieren daher nicht ohne Weiteres.

Proxy-Test-URL

[General]
proxy-test-url = http://cp.cloudflare.com/generate_204
test-timeout = 3

proxy-test-url ist die Test-URL jeder url-test-, fallback- und load-balance-Gruppe ohne eigenes url, und test-timeout (Sekunden) die Zeitüberschreitung jeder solchen Gruppe ohne timeout. Die Gruppen folgen diesen Schlüsseln auch nach dem Speichern der Konfiguration; nur ein url oder timeout in der Gruppenzeile setzt sie außer Kraft. Eine ungültige proxy-test-url ist ein Konfigurationsfehler. internet-test-url wird vom direkten Internettest der Web-Konsole verwendet und ohne Proxy abgerufen; ohne Angabe nutzt die Engine ihre eingebaute Erfolgs-URL.

UDP über eine Richtlinie ohne UDP

udp-policy-not-supported-behaviour = DIRECT

Was mit einem UDP-Datagramm geschieht, dessen Richtlinie kein UDP weiterleiten kann, etwa ein reiner HTTP-Proxy: REJECT (Standard) verwirft es, DIRECT sendet es stattdessen direkt. block-quic wird vorher entschieden, anhand der Richtlinie, die die Regel gewählt hat: Mit block-quic = auto wird QUIC, das an einen Proxy ohne UDP-Weiterleitung geht, abgewiesen statt direkt gesendet. Anderes UDP fällt weiterhin auf DIRECT zurück. Ebenso wird das UDP einer verketteten Richtlinie behandelt, das nicht über ihren Upstream laufen kann, und ebenso ein DoQ- oder DoH3-Upstream, der dem ausgehenden Modus folgt und dabei auf eine Richtlinie ohne UDP trifft: REJECT überspringt diesen Upstream, DIRECT fragt ihn direkt.

Front-Proxy

[General]
global-underlying-proxy = Airport

Sendet jede Proxy-Richtlinie ohne eigenes underlying-proxy über die genannte Richtlinie oder Gruppe — was Shadowrocket Front-Proxy (前置代理) nennt und nur in seiner App einstellen lässt. Die Richtlinien von Proxy-Providern gehören dazu. Unverändert bleiben: jede Richtlinie, die eine Verbindung über die Front-Richtlinie selbst durchlaufen kann — ihre Mitglieder, deren Upstreams und die Hops eines Relays darunter —, damit die Front-Richtlinie nie über sich selbst läuft; eine Richtlinie mit underlying-proxy=DIRECT, die sich damit ausnimmt; Richtliniengruppen, bei denen ihre Mitglieder entscheiden; sowie DIRECT, REJECT und TAILSCALE. Lassen Sie den Schlüssel weg oder schreiben Sie DIRECT, um ihn auszuschalten. Ein nicht definierter Name lehnt jede Richtlinie ab, die er erfassen würde, statt sie direkt verbinden zu lassen.

close-if-proxy-chain-missing (Shadowrocket) wird gelesen und beim Speichern des Profils zurückgeschrieben. Chute verhält sich immer wie bei true: Eine verkettete Richtlinie, deren Upstream fehlt, wird abgelehnt. false — Shadowrockets Standard, der den fehlenden Hop überspringt und den Knoten direkt verbindet — wird nicht befolgt, und ein Hinweis sagt das einmal.

Client-Fingerabdruck

global-client-fingerprint = chrome

Legt den TLS-Client-Fingerabdruck für jede Richtlinie fest, die keinen eigenen fingerprint trägt, die Richtlinien eines Proxy-Providers eingeschlossen. Der Wert der Richtlinie hat immer Vorrang; dies ist also eine Vorgabe und keine Übersteuerung.

Unterstützte Werte sind chrome, firefox, safari und ios sowie edge, 360, qq, android und random, die alle als Chrome behandelt werden, sowie die übrigen unter fingerprint genannten Namen. Ein unbekannter Wert wird mit der Warnung Ignoring unsupported global-client-fingerprint '<value>' ignoriert und der TLS-Stack der Plattform verwendet.

Standard: leer, also der TLS-Stack der Plattform. ShadowTLS-Richtlinien lesen ihn immer, VLESS-Richtlinien mit tls=true oder reality=true, Trojan- und VMess-Richtlinien mit tls=true und Shadowsocks-Richtlinien mit ws=true und tls=true; eine Richtlinie mit gRPC-Transport braucht ebenfalls ein geschriebenes tls=true. ShadowsocksR-Richtlinien lesen ihn nie.