URL-Umschreibung

Chute kann die URL der Anfrage mit verschiedenen Methoden umschreiben oder bestimmte Anfragen nach URL ablehnen.

Nur eine Regel kann auf eine einzelne Anfrage angewendet werden.

Hinweis: Eine unverschlüsselte HTTP-Anfrage wird nur verarbeitet, wenn sie Chute über seinen HTTP-Proxy erreicht; unverschlüsseltes HTTP, das über die TUN-Schnittstelle ankommt, wird unverändert weitergeleitet. Chute Android leitet sämtlichen Verkehr über TUN, sofern nicht System-HTTP-Proxy in den Einstellungen eingeschaltet ist, womit Apps den HTTP-Proxy von Chute erhalten (Android 10 und neuer; standardmäßig aus). Eine HTTPS-Anfrage wird nur verarbeitet, wenn ihr Host per MitM entschlüsselt wird.

Beispiel:

[URL Rewrite]
^http://www\.google\.cn http://www.google.com header
^http://amazon\.cn https://z.cn 302
^http://ad\.com/ad\.png _ reject
^http://tracker\.com/event _ reject-200
^http://ad\.com/pixel _ reject-img
^http://api\.example\.com/block _ reject-dict
^http://api\.example\.com/list _ reject-array
^http://ad\.com/beacon _ reject-tinygif

Die Umschreibungsregel besteht aus 3 Teilen: regulärer Ausdruck, Ersetzung und Typ. Die Teile werden durch Leerraum getrennt, und das erste Wort, das mit #, ; oder // beginnt, leitet einen Kommentar ein, der bis zum Zeilenende reicht; dieser Abschnitt kennt keine Anführungszeichen. Siehe Kommentar.

Für die Reject-Typen (reject, reject-200, reject-img, reject-dict, reject-array, reject-tinygif) wird auch eine Zwei-Token-Kurzform <pattern> reject ohne den _-Platzhalter akzeptiert. Die Kurzform nimmt außerdem Shadowrockets reject-drop und reject-no-drop an, die beide wie reject beantwortet werden, sowie reject-video, das wie reject-200 beantwortet wird; diese drei werden nur in der Kurzform akzeptiert, nicht als Typ einer Drei-Token-Zeile. Eine Zwei-Token-Zeile, deren zweites Token kein Reject-Schlüsselwort ist, wird als Header-Umschreibung auf diese URL gelesen: ^http://a\.com http://b.com ist dasselbe wie ^http://a\.com http://b.com header. Achten Sie auf die Schreibweise der Reject-Schlüsselwörter — reject200 ist keines, sodass ^http://ad\.com reject200 als Header-Umschreibung auf reject200 gelesen wird. Diese Ersetzung ist weder eine absolute URL noch ein absoluter Pfad, weshalb die Umschreibung zum Anfragezeitpunkt mit einer Warnung im Protokoll verweigert und die Anfrage unverändert weitergeleitet wird: weder abgewiesen noch umgeschrieben.

Antworten, die Chute selbst erzeugt — Map Local, die response eines Skripts sowie die Antworten und die Fehlerseite der URL-Umschreibung und der REJECT-Richtlinien — folgen HTTP: Die Antwort auf eine HEAD-Anfrage besteht nur aus dem Header, mit der Content-Length, die eine GET-Anfrage bekäme, und eine Antwort mit Status 204, 205 oder 304 trägt weder einen Body noch eine Content-Length.

Header-Modus

Chute ändert den Anfrage-Header und leitet die Anfrage bei Bedarf an einen anderen Host weiter. Der Client bemerkt diese Umschreibungsaktion nicht. (Dieser Modus entspricht dem „Map Remote“ von Surge.)

Das Feld Host im Anfrage-Header wird so geändert, dass es mit der neuen URL übereinstimmt.

[URL Rewrite]
^http://www\.google\.cn http://www.google.com header

Die Ersetzung kann auch eine reine Pfadform wie /new/path sein. In diesem Fall wird nur die Anfragezeile auf den neuen Pfad umgeschrieben, und die Anfrage wird weiterhin an denselben Host gesendet. Nur eine Ersetzung, die mit einem Schema und :// beginnt, wird als URL gelesen; ein Pfad, dessen Query-String eine URL enthält, etwa /go?to=http://example.com/, bleibt also eine reine Pfadersetzung.

Wenn das Ziel nicht direkt umgeschrieben werden kann — zum Beispiel beim Umschreiben einer unverschlüsselten HTTP-Anfrage auf eine https://-URL, beim Umschreiben einer HTTPS-Anfrage (mit aktiviertem MitM) auf einen anderen Origin oder wenn eine Folgeanfrage auf einer bereits bestehenden Keep-alive-Verbindung über unverschlüsseltes HTTP von einer Regel getroffen wird, die einen anderen Host nennt — antwortet Chute dem Client automatisch stattdessen mit einer 307-Weiterleitung auf die neue URL anstelle einer transparenten Header-Umschreibung.

302-Modus

Chute gibt einfach eine 302-Weiterleitungsantwort zurück. HTTPS-Anfragen können umgeleitet werden, wenn MitM für den Hostnamen aktiviert ist.

[URL Rewrite]
^http://amazon\.cn https://z.cn 302

307-Modus

Chute gibt einfach eine temporäre 307-Weiterleitung (307 Temporary Redirect) zurück. HTTPS-Anfragen können umgeleitet werden, wenn MitM für den Hostnamen aktiviert ist.

[URL Rewrite]
^http://amazon\.cn https://z.cn 307

Reject-Modus

Lehnt die Anfrage ab, wenn das Muster übereinstimmt. Der Ersetzungsparameter wird ignoriert. Gibt eine HTTP-503-Antwort zurück. HTTPS-Anfragen werden abgelehnt, wenn MitM für den Hostnamen aktiviert ist.

[URL Rewrite]
^http://ad\.com/ad\.png _ reject

Reject-200-Modus

Lehnt die Anfrage mit einem HTTP-200-OK-Status und einem Body der Länge Null ab. Nützlich zum stillen Blockieren von Tracking-Anfragen, ohne Fehlerbehandlung auszulösen.

[URL Rewrite]
^http://tracker\.com/event _ reject-200

Reject-Img-Modus

Lehnt die Anfrage ab, indem ein weißes 1×1-GIF-Bild zurückgegeben wird (HTTP 200 OK). Nützlich zum Blockieren von Werbebildern, ohne dass Platzhalter für defekte Bilder entstehen.

[URL Rewrite]
^http://ad\.com/pixel _ reject-img

Reject-Dict-Modus

Lehnt die Anfrage ab, indem ein leeres JSON-Objekt {} zurückgegeben wird (HTTP 200 OK). Nützlich zum Blockieren von API-Aufrufen, die eine JSON-Antwort erwarten.

[URL Rewrite]
^http://api\.example\.com/block _ reject-dict

Reject-Array-Modus

Lehnt die Anfrage ab, indem ein leeres JSON-Array [] zurückgegeben wird (HTTP 200 OK). Nützlich zum Blockieren von API-Aufrufen, die eine Liste erwarten.

[URL Rewrite]
^http://api\.example\.com/list _ reject-array

Reject-TinyGIF-Modus

Lehnt die Anfrage ab, indem ein 1×1-GIF-Bild zurückgegeben wird (HTTP 200 OK) — Surges Schreibweise für dieselbe Antwort wie reject-img.

[URL Rewrite]
^http://ad\.com/beacon _ reject-tinygif