HTTP-Regel

Es gibt 4 Regeltypen auf HTTP-Ebene. USER-AGENT und URL-REGEX lesen die Anfrage, die ein Client an den HTTP-Proxy-Listener von Chute sendet, und greifen daher nur bei Verbindungen, die dort ankommen; eine Verbindung über TUN oder SOCKS5 hat keine HTTP-Anfrage, die sich lesen ließe. Sie werden einmal pro Client-Verbindung entschieden, anhand ihrer ersten Anfrage. Die MitM-Entschlüsselung beginnt erst, nachdem die Richtlinie einer Verbindung gewählt wurde, daher werden die Anfragen, die sie entschlüsselt, nicht erneut gegen die Regeln abgeglichen. PROTOCOL,TCP und PROTOCOL,UDP lesen die Transportschicht und greifen bei jedem Eingang; die Anwendungsprotokoll-Werte von PROTOCOL stammen aus der Protokollerkennung des TUN-Eingangs und aus einer unverschlüsselten Anfrage am HTTP-Proxy-Eingang. SCRIPT wird für jede Verbindung ausgewertet.

USER-AGENT

USER-AGENT,Instagram*,DIRECT

Die Regel greift, wenn der User-Agent der Anfrage übereinstimmt. Wildcard-Zeichen * und ? werden unterstützt. Der Header wird aus der ersten Anfrage jeder Client-Verbindung zum HTTP-Proxy-Listener gelesen; bei HTTPS ist diese Anfrage das CONNECT, mit dem der Client seinen Tunnel öffnet, die Regel sieht also den User-Agent, den der Client dem CONNECT mitgibt, sofern er einen sendet.

URL-REGEX

URL-REGEX,^http://google\.com.*,DIRECT

Die Regel greift, wenn die URL einer unverschlüsselten HTTP-Anfrage, die am HTTP-Proxy-Listener ankommt, mit dem regulären Ausdruck übereinstimmt. Die URL wird vollständig ausgeschrieben — http://host[:port]/path?query, wobei der Port entfällt, wenn er 80 ist —, und der reguläre Ausdruck muss auf die vollständige URL passen, nicht nur auf einen Teilstring: ^http://google\.com allein passt nicht auf http://google.com/, weil der Pfad Teil der URL ist. Ein CONNECT-Tunnel (HTTPS oder alles andere, was ein Client tunnelt) und eine TUN-Verbindung haben keine URL, daher greift URL-REGEX bei ihnen nie, und daran ändert auch die Entschlüsselung einer HTTPS-Verbindung per MitM nichts. Der Probelauf des Regelabgleichs, POST /api/rules/match der HTTP-Control-API, gleicht URL-REGEX mit seinem Feld url genau so ab, wie es gesendet wird; geben Sie ihm also die vollständige URL.

PROTOCOL

PROTOCOL,TLS,Proxy

Die Regel greift, wenn das erkannte Protokoll der Verbindung übereinstimmt. Verwenden Sie dies in Kombination mit sniffing-enabled für beste Ergebnisse. NETWORK wird als Alias von PROTOCOL akzeptiert.

Akzeptierte Protokollwerte: HTTP, HTTPS, TLS, TCP, UDP, QUIC, STUN, MTPROTO, DNS, DOH, DOH3, DOQ, DOT.

Hinweis: Das erkannte Protokoll wird an diesen Stellen befüllt. Bei TUN-Eingangssitzungen wird eine TCP-Verbindung bei aktiviertem sniffing-enabled nur dann als HTTP oder TLS (jede TLS-Verbindung, einschließlich HTTPS) erkannt, wenn Chute ihren Hostnamen nicht bereits kennt: Eine Verbindung zu einer Fake-IP oder zu einer Adresse, die Chutes DNS aufgelöst hat, behält diesen Namen und durchläuft keine Protokollerkennung, daher greifen PROTOCOL,HTTP und PROTOCOL,TLS selten auf TUN-Verkehr, dessen Namen Chute aufgelöst hat. Ein UDP-Datenstrom wird anhand der Paketform automatisch als QUIC erkannt — über TUN ebenso wie über das UDP-Relay des SOCKS5-Eingangs —, ohne dass sniffing-enabled nötig wäre. Bei aktiviertem sniffing-enabled liest Chute zusätzlich den Servernamen aus dem Initial-Paket eines QUIC-Datenstroms, sodass auch DOMAIN-Regeln auf diesen Datenstrom greifen können (siehe sniffing-enabled unter Verschiedene Optionen). Am HTTP-Proxy-Eingang ist eine einfache Anfrage (kein CONNECT) HTTP, ganz ohne Erkennung, denn ihr Anfrage-Header wurde soeben von der Verbindung gelesen; ein CONNECT lässt das Protokoll ungesetzt, und eine TCP-Verbindung am SOCKS5-Eingang erhält nie eines — PROTOCOL,TCP und PROTOCOL,UDP lesen jedoch die Transportschicht der Sitzung, die jeder Eingang befüllt, sodass diese beiden auch dort greifen. Mit encrypted-dns-follow-outbound-mode = true (siehe DNS-Server) werden Chutes eigene verschlüsselte DNS-Upstream-Verbindungen als DOH, DOT, DOQ und DOH3 abgeglichen: alle vier nutzen dann die Richtlinie, die die Regel nennt — DoQ und DoH3 über deren UDP-Relay, wobei udp-policy-not-supported-behaviour entscheidet, wenn sie keines trägt —, und eine REJECT-Entscheidung überspringt jeden der vier. HTTPS ist eine akzeptierte Schreibweise für einen erkannten TLS-Handshake, PROTOCOL,HTTPS und PROTOCOL,TLS greifen also auf denselben Verkehr. STUN, MTPROTO und DNS werden aus Kompatibilitätsgründen akzeptiert, aber noch liefert kein Detektor sie.

SCRIPT

SCRIPT,MyRuleScript,DIRECT

Die Regel wertet ein JavaScript-Skript für benutzerdefinierte Abgleichlogik aus. Der Skriptname muss mit einem im Abschnitt [Script] definierten Skript mit type=rule übereinstimmen.

[Rule]
SCRIPT,CheckInternal,PROXY

[Script]
CheckInternal = type=rule, script-path=internal-check.js

Das Regel-Skript erhält $request und muss $done({matched: true}) oder $done({matched: false}) aufrufen. Beachten Sie, dass $request.dnsResult nur verfügbar ist, wenn die Sitzung bereits aufgelöst wurde (zum Beispiel bei Anfragen direkt an eine IP-Adresse oder im zweiten Abgleichdurchlauf nach der DNS-Auflösung).