Proxy-Server

Ein Proxy-Server leitet Anfragen an einen Upstream-Proxy weiter. Chute unterstützt HTTP/HTTPS/SOCKS5/SOCKS5-TLS/SS/SSR/Trojan/VMess/VLESS/AnyTLS/TUIC/Hysteria2/WireGuard/AmneziaWG/ShadowTLS/MASQUE/SSH-Proxy-Protokolle.

Der Abschnitt [Proxy] deklariert Proxy-Server. Sie können mehrere Proxy-Server für verschiedene Regeln erstellen.

Beispiel:

[Proxy]
ProxyHTTP = http, 1.2.3.4, 443, username, password
ProxyHTTPS = https, 1.2.3.4, 443, username, password, sni=example.com
ProxySOCKS5 = socks5, 1.2.3.4, 443, username, password
ProxySOCKS5TLS = socks5-tls, 1.2.3.4, 443, username, password, sni=example.com
SS = ss, 1.2.3.4, 443, method, password, obfs=http
SSR = ssr, 1.2.3.4, 443, method, password, protocol=auth_chain_f, protocol_param=user:pass, obfs=http_post, obfs_param=example.com
Trojan = trojan, 1.2.3.4, 443, password=password, tls=true, sni=example.com, skip-cert-verify=false, ws=true
VMess = vmess, 1.2.3.4, 443, uuid=uuid, sni=example.com, tls=true, ws=true
VLESS = vless, 1.2.3.4, 443, uuid=uuid, sni=example.com, xtls=true
AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com
TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com
Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, up=10, down=100
WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, section-name=wg0, self-ip=10.0.0.2
AmneziaWG = amneziawg, section-name=awg0
ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome
ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false
SSH = ssh, 1.2.3.4, 22, root, password=pw
SCHEME = scheme, ssr://....

Hinweis: Eine Trojan-Richtlinie benötigt ein explizites tls=true — TLS wird nicht impliziert. Ohne tls=true (und ohne grpc=true, das immer über TLS läuft) verbindet sich die Richtlinie im Klartext, und das Protokoll meldet das beim Laden der Konfiguration: Trojan policy <name> has no tls=true; it connects without TLS. Der Import eines Clash/mihomo-Profils schreibt bei jedem Trojan-Knoten tls=true.

Hinweis: scheme nimmt einen Share-Link einer dieser Arten an: ss://, ssr://, anytls://, tuic://, hysteria2:// und shadowtls://. Ein Link jeder anderen Art macht die Zeile zu einem Konfigurationsfehler.

Parameter

Parameter für Proxy mit TLS

tls: Optional.

tls=true

Aktiviert TLS-Transport.

skip-cert-verify: Optional

skip-cert-verify=true

Wenn diese Option aktiviert ist, überprüft Chute das Serverzertifikat nicht. true, 1 und yes schalten sie gleichermaßen ein, sodass auch Share-Links mit insecure=1 funktionieren. skip-common-name-verify=true, Shadowrockets Schreibweise auf socks5-tls-Zeilen, wird als dieselbe Option gelesen.

sni (Standard: hostname)

sni=exmaple.com

Sie können die Server Name Indication (SNI) während des TLS-Handshakes anpassen. Standardmäßig sendet Chute SNI mit dem Hostnamen wie die meisten Browser.

fingerprint: Optional.

fingerprint=chrome

Sendet das TLS-ClientHello eines Browsers statt des systemeigenen, damit der Handshake nicht als der eines Proxy-Clients auffällt. Unterstützte Werte sind chrome, firefox, safari und ios sowie edge, 360, qq, android und random, die alle als Chrome behandelt werden. Auch die Namen, die mihomo, sing-box und Xray verwenden, werden akzeptiert und auf diese vier Vorgaben abgebildet: randomized, chrome_pq und hellochrome_131 etwa werden als Chrome behandelt, hellofirefox_120 als Firefox, hellosafari_16_0 als Safari und helloios_14 als iOS. Xrays hellogolang hat keine Vorgabe.

Das gilt für Trojan, VMess und VLESS über TLS, einschließlich ihrer WebSocket- und gRPC-Transporte, sowie für Shadowsocks und ShadowsocksR über WebSocket mit TLS. REALITY und ShadowTLS haben dieselbe Option in ihren eigenen Abschnitten. Um einen Fingerabdruck für jede Richtlinie ohne eigene Angabe zu setzen, verwenden Sie global-client-fingerprint. Es erreicht ShadowTLS-Richtlinien 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 übernehmen es nie.

Auf diesen Protokollen wählt fingerprint=none — oder unsafe, das dasselbe bedeutet — den TLS-Stack des Systems und hat Vorrang vor global-client-fingerprint. REALITY und ShadowTLS kommen ohne den Browser-Handshake nicht aus, deshalb weist none dort die Verbindung ab. Ein Wert, den Chute nicht erkennt, führt bei jedem Protokoll dazu, dass die Verbindungen der Richtlinie abgewiesen werden, statt auf das TLS des Systems zurückzufallen: Es wird nichts an den Server gesendet, die Verbindung schlägt fehl (eine url-test- oder fallback-Gruppe zählt das wie jeden anderen Fehlschlag), und beim Laden der Konfiguration wird Policy <name>: fingerprint '<value>' is not supported; connections through this policy are refused protokolliert. Ein unbekannter global-client-fingerprint wird dagegen nur ignoriert.

Das Setzen eines Fingerabdrucks aktiviert zugleich den post-quantensicheren Schlüsselaustausch: Chute bietet dann neben X25519 auch die Hybridgruppe X25519MLKEM768 an, sodass eine heute mitgeschnittene Sitzung später nicht von einem Angreifer mit Quantencomputer entschlüsselt werden kann. Ein Server, der die Gruppe nicht kennt, wählt einfach X25519 — es geht also nichts kaputt. Ohne Fingerabdruck läuft die Verbindung über den TLS-Stack des Systems, der sie nicht anbietet — aus demselben Grund benötigt auch ECH einen Fingerabdruck.

Parameter für Proxy mit Shadowsocks

method: Erforderlich.

Derzeit unterstützt:

rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
salsa20
chacha20
chacha20-ietf
aes-128-gcm
aes-192-gcm
aes-256-gcm
chacha20-ietf-poly1305
xchacha20-ietf-poly1305

Shadowsocks-2022-Methoden

Chute unterstützt das Shadowsocks-2022-Protokoll, das BLAKE3-basierte Schlüsselableitung und AEAD-Chiffren verwendet. Der Methodenname bestimmt die Chiffre-Suite:

2022-blake3-aes-128-gcm
2022-blake3-aes-256-gcm
2022-blake3-chacha20-poly1305

Passwortformat:

Das Passwortfeld für SS2022 besteht aus einem oder zwei base64-kodierten Schlüsseln, getrennt durch : (Doppelpunkt).

Einzelbenutzermodus (ein Schlüssel):

SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "base64-key"

Mehrbenutzermodus mit Identitätsheadern (zwei Schlüssel):

Für 2022-blake3-aes-128-gcm und 2022-blake3-aes-256-gcm können Sie einen Identitätsheader-Schlüssel und einen Benutzerschlüssel angeben, getrennt durch ::

SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "header-base64-key:user-base64-key"

Jeder Schlüssel ist ein base64-kodierter String (unterstützt sowohl Standard- als auch URL-sicheres base64). Die erforderlichen Schlüssellängen:

Einen Schlüssel generieren:

openssl rand -base64 32

Hinweis: SS2022-Methoden unterstützen den Parameter obfs nicht. Die Methode 2022-blake3-chacha20-poly1305 unterstützt keinen Mehrbenutzermodus.

Shadowsocks-AEGIS-Methoden

Chute unterstützt außerdem die AEGIS-Familie von AEAD-Chiffren. Sie bauen auf der AES-Rundenfunktion auf und sind auf jedem Prozessor mit Hardware-AES — darunter alle neueren iPhones, iPads, Apple TVs und Macs — deutlich schneller als AES-GCM oder ChaCha20-Poly1305:

aegis-128l
aegis-256

Die Konfiguration entspricht den klassischen AEAD-Methoden oben; das Passwort ist eine gewöhnliche Passphrase, kein Base64-Schlüssel:

AEGIS = ss, 1.2.3.4, 443, aegis-128l, your-password

Alles Weitere folgt unverändert SIP004: Das Salt ist so lang wie der Schlüssel, der Sitzungs-Subschlüssel ist HKDF-SHA1(key, salt, "ss-subkey"), die TCP-Nutzlast wird in längenpräfixierten AEAD-Blöcken übertragen, wobei die Nonce nach jeder Operation hochgezählt wird, und UDP verwendet eine Nonce aus lauter Nullen.

Sie müssen den Server selbst betreiben. AEGIS ist nicht Teil der Shadowsocks-Spezifikation — es gibt kein SIP dafür, und kein verbreiteter Shadowsocks-Server implementiert es, weder shadowsocks-rust noch shadowsocks-libev, shadowsocks-go, sing-box oder Xray. Diese Methoden funktionieren nur gegenüber einem selbst betriebenen Server, der eigens dafür gebaut wurde. Wenn Sie Chute auf einen kommerziellen oder geteilten Knoten richten, verwenden Sie stattdessen eine der interoperablen Methoden oben.

obfs: Optional.

Derzeit unterstützt:

tls
http

obfs_param: Optional.

obfs_param=example.com

Legt den Host fest, der von der obfs-Schicht verwendet wird. Standardwert ist cloudfront.net, wenn nicht gesetzt.

WebSocket (v2ray-plugin): Optional.

ws=true, ws-path=/path, ws-headers=Host:example.com, tls=true, sni=example.com, skip-cert-verify=false

Trägt den Shadowsocks-Datenstrom in einem WebSocket, so wie es der websocket-Modus von v2ray-plugin tut. Damit erreicht die Richtlinie einen Shadowsocks-Server, der hinter v2ray-plugin läuft, auch wenn ein CDN davorsteht. Die Optionen sind die des WebSocket-Transports und die von TLS. Shadowsocks-2022-Methoden funktionieren darüber ebenfalls, und ShadowsocksR-Richtlinien nehmen dieselben Optionen an und behalten dabei ihr eigenes Protokoll und obfs.

• ws-path ist standardmäßig /; einem Pfad ohne führenden Schrägstrich wird einer vorangestellt.
• Der Host der Upgrade-Anfrage ist der Host aus ws-headers, so wie er geschrieben ist. Fehlt er, ist es sni — oder die Serveradresse, wenn es kein sni gibt —, gefolgt von :<Port>.
• tls=true legt TLS unter den WebSocket. sni, skip-cert-verify, fingerprint und die ECH-Optionen wirken wie bei Trojan. Ohne ws=true bewirkt tls=true nichts: Die Richtlinie verbindet sich ohne TLS, und die Zeile erhält den Hinweis Shadowsocks tls=true only applies with ws=true (the v2ray-plugin transport); this policy connects without TLS.
• ws-mux (Standard true) öffnet auf jedem WebSocket eine mux.cool-Sitzung; das erwartet ein v2ray-plugin-Server, der mit seinem Standard mux=1 gestartet wurde. Für einen Server, der mit mux=0 gestartet wurde, schreiben Sie ws-mux=false.
• Steht in derselben Zeile auch obfs=, wird der WebSocket verwendet und simple-obfs nicht angewendet; beim Laden der Konfiguration wird Policy <name> ignored unsupported option(s): obfs protokolliert.
• UDP läuft nicht durch das Plugin: Es ist gewöhnliches Shadowsocks-UDP, das direkt an host:port geht und nicht durch ein CDN kommt. Schreiben Sie udp-relay=false für einen Server, den Sie über ein CDN erreichen. Spricht der Shadowsocks-Server hinter dem Plugin UoT, trägt udp-over-tcp=true das UDP stattdessen in den Streams der Richtlinie und damit auch durch den WebSocket.
• Der quic-Modus von v2ray-plugin wird nicht unterstützt.

Auch die Schreibweise von Shadowrocket wird gelesen: obfs=websocket (oder obfs=ws), mit dem Host in obfsParam oder obfs-host und dem Pfad in path oder obfs-uri. Gespeichert wird die Richtlinie als ws=true. Jeder andere obfs-Wert, den der Shadowsocks-Stack nicht lesen kann — wss aus Quantumult X oder ein Tippfehler —, wird in einem Hinweis genannt, und die Richtlinie verbindet sich als einfaches Shadowsocks: Shadowsocks over WebSocket (the v2ray-plugin transport) is written ws=true, with ws-path= and ws-headers=; obfs=<value> is not read, so this policy would connect as plain Shadowsocks.

SS = ss, 1.2.3.4, 443, aes-256-gcm, password, ws=true, ws-path=/ws, ws-headers=Host:cdn.example.com, tls=true, sni=cdn.example.com

udp-over-tcp: Optional.

udp-over-tcp=true, udp-over-tcp-version=2

Trägt das UDP der Richtlinie in TCP-Verbindungen der Richtlinie statt über das UDP-Relay des Servers — sing-boxs UDP über TCP (UoT). Jeder UDP-Datenstrom erhält eine eigene Verbindung zu der vereinbarten Adresse, die der Server erkennt (sp.v2.udp-over-tcp.arpa, bei Version 1 sp.udp-over-tcp.arpa). Es sind gewöhnliche Verbindungen der Richtlinie, sie folgen also wie jede andere ihrem underlying-proxy: UDP funktioniert dann auch über einen Upstream, der kein UDP trägt, etwa einen HTTP-Proxy, und über den WebSocket-Transport. Der Server muss UoT unterstützen, wie es sing-box- und mihomo-Server tun. Shadowsocks-2022-Methoden funktionieren damit.

• udp-over-tcp-version (Standard 2): Version 2 öffnet jede Verbindung mit einer Anfrage, die das Ziel nennt, und rahmt danach jedes Datagramm über seine Länge; Version 1 hat keine Anfrage und setzt die Adresse vor jedes Datagramm. mihomos Standard ist Version 1, daher schreibt ein aus mihomo importiertes Profil die Version aus. Jeder andere Wert wird gemeldet, als 2 verwendet und beim Speichern des Profils so beibehalten, wie er geschrieben wurde.
• udp-relay=false schaltet UDP für die Richtlinie weiterhin ab.
• Im Shadowsocks-Editor der App sind das der Schalter UDP über TCP und die Auswahl UoT-Version.

SS = ss, 1.2.3.4, 8388, aes-256-gcm, password, udp-over-tcp=true

Parameter für Proxy mit ShadowsocksR/ShadowsocksRR/ShadowsocksR-Akarin

method: Erforderlich.

Derzeit unterstützt:

rc4
rc4-md5-6
rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
cast5-cfb
des-cfb
idea-cfb
rc2-cfb
seed-cfb
salsa20
chacha20
chacha20-ietf

protocol: Optional.

Derzeit unterstützt:

origin
auth_sha1
auth_sha1_v2
auth_sha1_v4
auth_aes128_md5
auth_aes128_sha1
auth_chain_a
auth_chain_b
auth_chain_c
auth_chain_d
auth_chain_e
auth_chain_f
auth_akarin_rand
auth_akarin_spec_a

protocol_param: Optional.

obfs: Optional.

Derzeit unterstützt:

plain
http_simple
http_post
tls1.2_ticket_auth

obfs_param: Optional.

Parameter für Proxy mit WebSocket

Der WebSocket-Transport steht für Trojan, VMess und VLESS zur Verfügung sowie für Shadowsocks und ShadowsocksR, wo er der websocket-Modus von v2ray-plugin ist — was dort anders ist, steht unter WebSocket (v2ray-plugin).

ws: Optional.

ws=true

Aktiviert WebSocket-Transport.

ws-path: Optional.

ws-path=/exmaple

Ändert den Pfad der WebSocket-HTTP-Anfrage.

ws-headers: Optional.

ws-headers=Header1:Value1|Header2:Value2

Ändert den HTTP-Header der WebSocket-HTTP-Anfrage.

Parameter für Proxy mit gRPC

gRPC-Transport ist für Trojan-, VMess- und VLESS-Protokolle verfügbar. Er verwendet HTTP/2-basiertes gRPC-Framing über TLS, was helfen kann, bestimmte Netzwerkbeschränkungen zu umgehen.

grpc: Optional.

grpc=true

Aktiviert gRPC-Transport. Der Transport läuft immer über TLS, ganz gleich, welchen Wert tls in der Richtlinie hat. Schreiben Sie trotzdem tls=true, wenn die Richtlinie global-client-fingerprint übernehmen soll, denn eine gRPC-Richtlinie erreicht es nur mit dieser Angabe.

grpc-service-name: Erforderlich, wenn grpc=true.

grpc-service-name=MyService

Gibt den gRPC-Dienstnamen/-pfad für Multiplexing an. Er muss mit dem auf dem Server konfigurierten Dienstnamen übereinstimmen; es gibt keinen Standardwert.

grpc-multi-mode: Optional.

grpc-multi-mode=true

Verwendet den Multi-Modus von Xray: Der Tunnel ruft /<service>/TunMulti statt /<service>/Tun auf, und mehrere Schreibvorgänge reisen in einer gRPC-Nachricht. Der Server muss den Multi-Modus unterstützen. Jeder Tunnel hat weiterhin eine eigene Verbindung.

Beispiel mit VMess und gRPC:

VMess = vmess, 1.2.3.4, 443, uuid=uuid, tls=true, grpc=true, grpc-service-name=GunService, sni=example.com

Parameter für Proxy mit XHTTP

Der XHTTP-Transport steht für die Protokolle Trojan, VMess und VLESS zur Verfügung. Statt eine Verbindung offen zu halten, verpackt er den Tunnel in gewöhnliche HTTP-Anfragen: Der Download kommt als eine einzige, nicht endende Antwort, der Upload geht als Folge von POSTs oder als ein einziger, nicht endender POST hinaus. Dadurch funktioniert er hinter einem CDN — der Hauptgrund, ihn statt WebSocket oder gRPC zu wählen.

Die HTTP-Version wird nicht direkt konfiguriert. Ohne TLS ist es HTTP/1.1, mit TLS HTTP/2 — es sei denn, alpn lautet genau http/1.1 (dann HTTP/1.1) oder genau h3 (dann HTTP/3). REALITY verwendet immer HTTP/2.

xhttp: Optional.

xhttp=true

Aktiviert den XHTTP-Transport.

xhttp-mode: Optional.

xhttp-mode=packet-up

Wie der Upload transportiert wird. auto (Standard) entspricht packet-up, bei REALITY dagegen stream-one.

• packet-up — der Upload ist eine Folge nummerierter POSTs. Am kompatibelsten und am besten für CDNs geeignet.
• stream-up — der Upload ist ein einziger, nicht endender POST, der Download läuft über eine eigene Anfrage.
• stream-one — eine Anfrage trägt beide Richtungen. Server und Zwischenstellen müssen Vollduplex-HTTP unterstützen.

Der Server legt den Modus meist fest; passt er nicht, antwortet er mit 400.

xhttp-path: Optional.

xhttp-path=/yourpath

Der Anfragepfad, standardmäßig /. Er muss dem Pfad entsprechen, unter dem der Server XHTTP anbietet.

xhttp-host: Optional.

xhttp-host=example.com

Der Hostname für den Host-Header und die Anfrage-URL. Standard ist sni, andernfalls die Serveradresse.

xhttp-headers: Optional.

xhttp-headers=Header1:Value1|Header2:Value2

Zusätzliche HTTP-Header im selben Format wie ws-headers.

xhttp-padding: Optional.

xhttp-padding=100-1000

Längenbereich des Paddings, das jede Anfrage mitführt, als MIN-MAX oder als einzelne Zahl. Standard ist 100-1000. Der Server verlangt Padding und prüft dessen Länge, der Bereich muss also innerhalb dessen liegen, was der Server akzeptiert — fehlt es oder stimmt die Länge nicht, wird mit 400 geantwortet.

xhttp-max-post-bytes: Optional.

xhttp-max-post-bytes=1000000

Größter Upload-POST in Bytes, standardmäßig 1000000. Größere Schreibvorgänge werden auf mehrere POSTs aufgeteilt.

xhttp-min-post-interval: Optional.

xhttp-min-post-interval=30

Mindestabstand zwischen aufeinanderfolgenden Upload-POSTs in Millisekunden, standardmäßig 30.

xhttp-xmux-max-concurrency, xhttp-xmux-max-connections, xhttp-xmux-max-reuse-times, xhttp-xmux-max-lifetime: Optional.

xhttp-xmux-max-concurrency=4

XMUX bündelt die zugrunde liegenden HTTP/2-Verbindungen, sodass sich mehrere Tunnel eine teilen. Das sieht aus wie eine gewöhnliche Browsersitzung statt einer Verbindung pro Tunnel. Alle vier stehen standardmäßig auf 0, das Pooling ist damit aus.

• xhttp-xmux-max-concurrency — Tunnel, die sich eine Verbindung teilen dürfen.
• xhttp-xmux-max-connections — erlaubte Verbindungen pro Server.
• xhttp-xmux-max-reuse-times — nach wie vielen Tunneln eine Verbindung keine neuen mehr annimmt.
• xhttp-xmux-max-lifetime — nach wie vielen Sekunden eine Verbindung keine neuen Tunnel mehr annimmt.

Für eine XHTTP-Richtlinie wird mux=true abgelehnt, gleich welches Protokoll sie verwendet, und beim Laden der Konfiguration wird Policy <name> ignored unsupported option(s): mux protokolliert: XHTTP bringt eigenes Multiplexing mit, das generische obendrauf würde es verdoppeln.

xhttp-download-server, xhttp-download-port: Optional.

xhttp-download-server=cdn.example.com

Leitet den Download über eine andere Adresse — typischerweise ein CDN vor demselben Server — während der Upload weiter die Hauptadresse nutzt. Beide müssen denselben Server erreichen: Die Sitzung ist serverseitiger Zustand, ein zweiter Weg ist in Ordnung, ein zweiter Server nicht.

Beispiel mit VLESS und XHTTP:

VLESS = vless, 1.2.3.4, 443, uuid=uuid, tls=true, xhttp=true, xhttp-mode=packet-up, xhttp-path=/yourpath, sni=example.com

Parameter für Proxy mit XTLS

xtls: Optional.

xtls=true

Hüllt den Transport in XTLS. Für sich allein kündigt es keinen Flow an: Die VLESS-Anfrage trägt einen leeren Addons-Block, es wird also kein Flow ausgehandelt. Verwenden Sie flow=xtls-rprx-vision weiter unten, um einen anzukündigen; xtls-rprx-direct ist nicht implementiert.

flow: Optional.

flow = xtls-rprx-vision

Wählt die XTLS-Flusskontrolle. Der einzige unterstützte Wert ist xtls-rprx-vision, der das Vision-Framing aktiviert; der Flow-Wert wird in den VLESS-Addons an den Server gesendet.

skip-cert-verify: Optional

skip-cert-verify=true

Wie bei TLS.

sni (Standard: hostname)

sni=exmaple.com

Wie bei TLS.

Parameter für Proxy mit REALITY

REALITY ist eine TLS-basierte Verschleierungstechnik, die Proxy-Verkehr von regulärem TLS-Verkehr zu einer echten Website ununterscheidbar macht. Es kann mit dem VLESS-Protokoll verwendet werden.

reality: Optional.

reality=true

Aktiviert REALITY-Verschleierung. Erfordert einen Zielserver, der als Tarnziel fungiert.

public-key: Erforderlich.

public-key=BASE64KEY

Der öffentliche X25519-Schlüssel des Servers (base64). Der REALITY-Handshake kann ohne ihn nicht aufgebaut werden.

short-id: Optional.

short-id=abcd1234

Eine kurze Kennung, die für die REALITY-Authentifizierung verwendet wird. Typischerweise ein Hex-String.

server-name: Optional.

server-name=www.microsoft.com

Die SNI (Server Name Indication), die während des TLS-Handshakes präsentiert wird. Dies sollte eine echte, häufig besuchte Website für den besten Tarneffekt sein. Das Zertifikat des Zielservers muss mit diesem Namen übereinstimmen.

fingerprint: Optional.

fingerprint=chrome

TLS-Client-Fingerabdruck, der nachgeahmt werden soll. Unterstützte Werte sind chrome, firefox, safari, ios, edge, 360, qq, android, random sowie die übrigen unter fingerprint genannten Namen. Die Verwendung eines gängigen Browser-Fingerabdrucks hilft, Erkennung zu vermeiden. Beachten Sie, dass android und random hier nicht eigenständig sind — sie werden wie chrome behandelt. none und jeder Wert, den Chute nicht erkennt, weisen die Verbindung ab, weil der TLS-Stack des Systems diesen Handshake nicht leisten kann.

spiderx: Optional.

spiderx=/path

Benutzerdefinierter Pfad für die REALITY-Spider-Tarnung.

Beispiel mit VLESS:

VLESS = vless, 1.2.3.4, 443, uuid=uuid, reality=true, public-key=BASE64KEY, server-name=www.microsoft.com, short-id=abcd, fingerprint=chrome

Hinweis: REALITY verwendet kein traditionelles Zertifikat. Die Verbindung verwendet das echte Zertifikat des Tarnservers.

Parameter für Proxy mit ECH

Encrypted Client Hello verbirgt den Servernamen vor jedem, der die Verbindung beobachtet. Der echte Name reist verschlüsselt im Handshake, während auf der Leitung der public_name steht, den die ECHConfig des Servers veröffentlicht.

ECH baut auf demselben Stack auf wie der Client-Fingerabdruck, deshalb muss eine Richtlinie auch fingerprint setzen — ohne ihn bewirkt ech=true nichts und der echte Name geht im Klartext hinaus. Es gilt für Trojan, VMess und VLESS über einfaches TLS, einschließlich ihrer WebSocket-Transporte, sowie für Shadowsocks und ShadowsocksR über WebSocket mit TLS.

Hinweis: Die gRPC- und XHTTP-Transporte unterstützen kein ECH. Bei grpc=true oder xhttp=true wird ech=true stillschweigend ignoriert und der echte Servername geht im Klartext hinaus. (Der Client-Fingerabdruck und der post-quantensichere Schlüsselaustausch gelten hingegen auch für gRPC und XHTTP.)

ech: Optional.

ech=true

Aktiviert ECH. Ist ech-config nicht gesetzt, sucht Chute die ECHConfig im DNS-HTTPS-Eintrag des Servernamens, genau wie ein Browser.

ech-config: Optional.

ech-config=AEX+DQBBAAAgACD...

Eine ECHConfigList in base64, die statt der DNS-Abfrage verwendet wird. Setzen Sie sie, wenn der Server keinen HTTPS-Eintrag veröffentlicht, oder um eine bestimmte Konfiguration festzuschreiben. Das Setzen schaltet ECH von selbst ein; ech=true ist dann nicht zusätzlich nötig.

ech-public-name: Optional.

ech-public-name=cover.example.com

Überschreibt den im Klartext gesendeten Decknamen. Standard ist der public_name aus der ECHConfig, den der Server erwartet; setzen Sie dies nur für eine Bereitstellung, die der Konfiguration einen anderen Host als Fassade vorschaltet.

Beispiel mit Trojan:

Trojan = trojan, 1.2.3.4, 443, password=pw, tls=true, sni=secret.example.com, fingerprint=chrome, ech=true

Lehnt der Server ECH ab — meist weil die Konfiguration veraltet ist —, antwortet er unter dem Decknamen und zeigt dessen Zertifikat, und der Handshake fällt auf das äußere TLS zurück. Solange die Zertifikatsprüfung aktiv ist, scheitert die Verbindung dann an der Authentifizierung statt still weiterzulaufen; mit skip-cert-verify=true prüft nichts diesen Namen, und die Sitzung läuft stillschweigend unter dem Decknamen weiter. Erneuern Sie ech-config oder entfernen Sie es für die DNS-Abfrage.

TCP Fast Open (Experimentell)

tfo: Optional

tfo=true

Weitere Informationen zu TCP Fast Open finden Sie in Wikipedia. Die Aktivierung von TCP Fast Open kann zu unerwarteten Verbindungsfehlern führen. Chute Android ignoriert tfo.

Gemeinsame Parameter

udp-relay: Optional (Standard: true)

udp-relay=false

Markiert die Richtlinie als nur-TCP. UDP-Relay ist standardmäßig aktiviert, wo das Protokoll es unterstützt; setzen Sie udp-relay=false, um die Richtlinie vom UDP-Relay auszuschließen. Trojan leitet UDP über eine einfache TLS-Verbindung zum Serverport weiter — ohne WebSocket, gRPC oder XHTTP und ohne ECH, aber mit dem Fingerabdruck der Richtlinie —, daher setzen Sie bei einem Server, der nur einen dieser Transporte bedient, udp-relay=false.

mux: Optional

mux=true

Aktiviert Verbindungswiederverwendung / Multiplexing. Die Aliase multiplex und reuse werden ebenfalls akzeptiert. Unterstützt von HTTP/HTTPS, SOCKS5/SOCKS5-TLS, Trojan, VMess, VLESS, Hysteria2, Shadowsocks(R), ShadowTLS und MASQUE. AnyTLS, TUIC und SSH werden auf keiner Plattform gemultiplext. Für diese wird mux=true nicht angewendet, und das Protokoll meldet das beim Laden der Konfiguration: Policy <name>: mux=true is not applied: <reason>.

Hysteria2 und MASQUE multiplexen über eine gemeinsame QUIC-Verbindung. Jedes andere Protokoll trägt die gemultiplexten Verbindungen in einem eigenen Framing von Chute, das nur ein Server zerlegen kann, der es versteht: Standard-Server von Xray, sing-box und Shadowsocks können das nicht, schalten Sie mux für sie also nicht ein.

cert-fingerprint-sha256: Optional

cert-fingerprint-sha256=<hex>

Pinnt das Serverzertifikat anhand seines SHA-256-Fingerabdrucks. Der Alias cert-fp wird ebenfalls akzeptiert. Derzeit nur für MASQUE wirksam.

encrypt-method (VMess): Optional (Standard: auto)

encrypt-method=aes-128-gcm

VMess-Payload-Verschlüsselung. Unterstützte Werte: aes-128-gcm, chacha20-poly1305, aes-128-cfb (Alias legacy), none.

alpn: Optional

alpn=h2|http/1.1

Mehrere ALPN-Werte werden mit | getrennt. Nur TUIC, Hysteria2 und MASQUE lesen die Option — jedes von ihnen verwendet h3, wenn sie nicht gesetzt ist —, dazu XHTTP, wo sie die HTTP-Version des Transports auswählt. Jedes andere Protokoll ignoriert diese Option und bietet das ALPN an, das sein Transport bestimmt: h2 für gRPC; mit einem fingerprint http/1.1 für WebSocket und h2,http/1.1 für reines TLS; ohne ihn für beide keines, weil dann der TLS-Stack des Systems den Handshake führt.

underlying-proxy: Optional.

underlying-proxy=OtherProxy

Proxy-Verkettung: Der Wert benennt eine andere Richtlinie oder Richtliniengruppe, die den Datenverkehr dieser Richtlinie trägt. Der Upstream wird zuerst verbunden, danach der eigene Server; A = ..., underlying-proxy=B sendet A also über B. B kann wiederum einen Upstream nennen und so mehrere Hops bilden. Leer oder DIRECT bedeutet direkte Verbindung. Ein Name mit Leerzeichen oder Komma wird in Anführungszeichen gesetzt, etwa underlying-proxy="HK 01". Bei einem fehlenden Namen wird die Verbindung abgelehnt (fail-closed) und protokolliert; es gibt keinen Rückfall auf DIRECT.

Eine Schleife aus festen Referenzen — auch eine, die über das eigene underlying-proxy des ersten Mitglieds einer Relay-Gruppe zurückführt — wird beim Laden der Konfiguration abgelehnt. Eine Schleife, die nur wegen der momentanen Wahl einer Richtliniengruppe besteht, wird nicht endgültig abgelehnt: Sobald die Gruppe anders wählt, funktioniert die Richtlinie, doch solange die Schleife besteht, wird jede Verbindung über sie abgelehnt. Unabhängig von der Form der Kette wird eine Verbindung, die mehr als 16 Upstream-Ebenen tief verschachtelt wäre, abgelehnt, statt endlos aufgefaltet zu werden.

Der Upstream löst auch den Servernamen dieser Richtlinie auf: Ein verketteter Server wird nie über den lokalen Resolver nachgeschlagen, und Chute pingt ihn nicht direkt an — ebenso wenig wie jede Richtlinie nach dem ersten Mitglied einer Relay-Gruppe. Seine Latenz stammt aus den Verfügbarkeitstests der Gruppen und dem Latenztest, die ihn beide über die Kette erreichen — url-test-, fallback- und load-balance-Gruppen messen ein verkettetes Mitglied auf demselben Weg, den eine Verbindung nimmt.

Jedes Protokoll lässt sich verketten außer Tailscale (die integrierte Richtlinie TAILSCALE), dessen Engine ihre Verbindungen selbst aufbaut. Eine Richtlinie, die ihren Server über einen Stream erreicht — HTTP, SOCKS5, Shadowsocks, VMess, VLESS, Trojan, AnyTLS, SSH, XHTTP über HTTP/1.1 oder HTTP/2 und die übrigen —, öffnet diesen Stream über den Upstream. Hysteria2, TUIC, MASQUE und XHTTP über HTTP/3 (TLS mit alpn=h3) sprechen QUIC, WireGuard und AmneziaWG senden eigene Datagramme; sie laufen daher über das UDP-Relay des Upstreams: Der Upstream — bei einer Gruppe deren aktuelle Auswahl — muss UDP tragen, wie es Shadowsocks, SOCKS5, VMess, VLESS, Trojan und Hysteria2 tun und ein HTTP- oder HTTPS-Proxy nicht. Über einen Upstream ohne UDP wird jede Verbindung über sie abgelehnt und protokolliert, nie direkt gesendet. Verkettet sendet eine QUIC-Richtlinie Datagramme von höchstens 1200 Byte, und ein WireGuard- oder AmneziaWG-Tunnel verwendet eine innere MTU von 1280, sofern keine angegeben ist (mtu oder wg-mtu in seinem Abschnitt), damit die eingepackten Datagramme noch auf einen 1500-Byte-Pfad passen. WireGuard, AmneziaWG und SSH halten für ihren gesamten Verkehr eine Verbindung über ihren eigenen Upstream; keine von ihnen kann daher ein späteres Mitglied einer Relay-Gruppe sein.

Auch UDP läuft durch die Kette. VMess, VLESS, Trojan und AnyTLS tragen UDP in einem Stream, ihr UDP funktioniert daher über jeden Upstream. Shadowsocks (einschließlich ShadowsocksR und Shadowsocks 2022) und SOCKS5 leiten UDP als Datagramme weiter, ebenso die QUIC-Protokolle und WireGuard: Ihr UDP funktioniert nur, solange der Upstream UDP trägt — außer ein Shadowsocks-Knoten verwendet udp-over-tcp: Er trägt sein UDP in Streams und funktioniert daher über jeden Upstream. SSH-, HTTP- und HTTPS-Richtlinien tragen überhaupt kein UDP. UDP, das eine verkettete Richtlinie nicht tragen kann, folgt udp-policy-not-supported-behaviour (Standard REJECT).

dialer-proxy (mihomo) und detour (sing-box) werden in diese Option importiert, das override: dialer-proxy eines Proxy-Providers in das underlying-proxy des Providers. Eine relay-Gruppe aus Clash oder mihomo bleibt eine Relay-Gruppe mit ihren Mitgliedern in derselben Reihenfolge. Um alle Mitglieder einer Richtliniengruppe über einen einzigen Upstream zu senden, setzen Sie underlying-proxy für die Gruppe. Um jede Proxy-Richtlinie über einen einzigen Upstream zu senden, setzen Sie global-underlying-proxy in [General].

test-url: Optional.

test-url=http://www.gstatic.com/generate_204

Die Latenztest-URL dieser Richtlinie, wenn sie Mitglied einer url-test- oder fallback-Gruppe ist: Die Gruppe misst dieses Mitglied mit dieser URL statt mit ihrer eigenen url. Ohne diesen Wert gilt die URL der Gruppe.

interface: Optional

interface=en0

Leitet die TCP-Verbindungen, die diese Richtlinie zu ihrem Server aufbaut, über die genannte Netzwerkschnittstelle — etwa en0 auf einem Mac oder wlan0 auf Android — statt über die, die die Standardroute wählt. Ist diese Schnittstelle nicht verfügbar, schlägt die Verbindung fehl, statt einen anderen Weg zu nehmen; allow-other-interface=true lässt sie stattdessen der Standardroute folgen. Das funktioniert in Chute Mac und Chute Android; iOS und tvOS ignorieren es. Das UDP-Relay wird nicht gebunden, ebenso wenig die QUIC-basierten Protokolle (TUIC, Hysteria2, MASQUE), WireGuard oder Tailscale.

Parameter für Proxy mit AnyTLS

AnyTLS ist ein TLS-basiertes Proxy-Protokoll mit Padding-Verschleierung.

AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, skip-cert-verify=false

password: Erforderlich.

Das Passwort/die Passphrase, die für die Authentifizierung verwendet wird.

sni (Standard: hostname)

sni=exmaple.com

Wie bei TLS.

skip-cert-verify: Optional

skip-cert-verify=true

Wie bei TLS.

Padding-Schema: Optional

Das Padding wird mit stop=N plus numerischen Pro-Paket-Schlüsseln konfiguriert:

AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, stop=2, 0=30-30, 1=100-400+c

Jedes Schema ist eine Liste von Segmenten, verbunden durch +, wobei ein Segment entweder c (check) oder ein min-max-Byte-Bereich ist (max. 16384), z. B. stop=2, 0=30-30, 1=100-400+c. Auch ein , funktioniert als Trenner, aber nur bei einem Wert in Anführungszeichen — 1="100-400,c" —, denn ein Komma ohne Anführungszeichen beendet das Feld und zerbricht die Zeile. Bevorzugen Sie +.

Parameter für Proxy mit TUIC

TUIC ist ein QUIC-basiertes Proxy-Protokoll, das gemultiplextes TCP- und UDP-Relay bietet. Das Schlüsselwort tuic-v5 (Surges Schreibweise) wird ebenfalls akzeptiert; gespeichert wird die Richtlinie als tuic.

TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com, skip-cert-verify=false, alpn=h3

uuid: Erforderlich.

Die UUID für die Authentifizierung.

password: Erforderlich.

Das Passwort für die Authentifizierung.

sni (Standard: hostname)

sni=exmaple.com

Wie bei TLS.

skip-cert-verify: Optional

skip-cert-verify=true

Wie bei TLS.

alpn: Optional

alpn=h3

Gibt den ALPN-String für die QUIC-Verbindung an.

Parameter für Proxy mit Hysteria2

Hysteria2 ist ein QUIC-basiertes Proxy-Protokoll für Szenarien mit hohem Durchsatz.

Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, skip-cert-verify=false, up=10, down=100, alpn=h3

auth: Erforderlich.

Das Authentifizierungspasswort/-token.

sni (Standard: hostname)

sni=exmaple.com

Wie bei TLS.

skip-cert-verify: Optional

skip-cert-verify=true

Wie bei TLS.

up: Optional (Mbps)

up=10

Upload-Bandbreite in Mbps. Wird angenommen und erhalten, aber nicht verwendet: Der Wert speist Hysteria2s Brutal-Staukontrolle, die diese Engine nicht ausführt. Für jede Richtlinie, die ihn setzt, wird ein Hinweis protokolliert. Auf die Leitung gelangt down=, nämlich als die Rate, die der Client bei der Authentifizierung angibt.

down: Optional (Mbps)

down=100

Download-Bandbreite in Mbps.

alpn: Optional

alpn=h3

Gibt den ALPN-String für die QUIC-Verbindung an.

obfs: Optional

obfs=salamander

Aktiviert die Salamander-Verschleierung für den QUIC-Verkehr. Salamander verwendet BLAKE2b-256 XOR, um QUIC-Pakete zu verschleiern und sie resistent gegen DPI (Deep Packet Inspection) zu machen.

obfs-password: Optional

obfs-password=your-obfuscation-key

Das Passwort/der Schlüssel, das/der für die Salamander-Verschleierung verwendet wird. Erforderlich, wenn obfs=salamander gesetzt ist.

Parameter für Proxy mit WireGuard

WireGuard ist ein modernes VPN-Protokoll. Chute unterstützt WireGuard als ausgehenden Proxy-Server, entweder inline oder durch Verweis auf einen benannten [WireGuard]-Abschnitt.

Inline-Konfiguration:

WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, self-ip=10.0.0.2, server=1.2.3.4, port=51820

Abschnittsreferenz (empfohlen):

WireGuard = wireguard, section-name=wg0

Siehe WireGuard-Konfiguration für die [WireGuard]-Abschnittssyntax.

private-key: Erforderlich (nur inline).

Base64-kodierter WireGuard-Privatschlüssel.

peer-public-key: Erforderlich (nur inline).

Base64-kodierter öffentlicher Schlüssel des WireGuard-Peers.

self-ip: Optional (inline).

Lokale IP-Adresse, die der WireGuard-Schnittstelle zugewiesen wird (z. B. 10.0.0.2).

self-ip-v6: Optional (inline).

Lokale IPv6-Adresse, die der WireGuard-Schnittstelle zugewiesen wird.

server: Erforderlich.

Remote-WireGuard-Serveradresse (kann stattdessen aus dem referenzierten [WireGuard]-Abschnitt stammen).

port: Erforderlich.

Remote-WireGuard-Serverport (kann stattdessen aus dem referenzierten [WireGuard]-Abschnitt stammen).

preshared-key: Optional.

Base64-kodierter Pre-Shared-Key für Post-Quantum-Resistenz.

allowed-ips: Optional (inline).

allowed-ips="10.0.0.0/8, 192.168.0.0/16"

Die Ziele, die der Peer trägt, als durch Kommas getrennte CIDRs; setzen Sie den Wert in Anführungszeichen, da er Kommas enthält. Ein Ziel außerhalb davon wird abgewiesen oder verworfen, weil der Peer es nicht zurückleiten kann. Ohne diese Angabe wird alles getragen. Siehe WireGuard-Konfiguration für die Abschnittsform.

keepalive: Optional (Sekunden).

keepalive=25

Persistentes Keepalive-Intervall für NAT-Traversal. Ohne diese Angabe wird kein Keepalive gesendet.

mtu: Optional.

mtu=1420

MTU für die WireGuard-Schnittstelle.

reserved: Optional.

reserved=0,1,2

Reservierte Bytes für den WireGuard-Paket-Header. Wird geparst, ist in der aktuellen Engine aber ohne Wirkung — der Wert wird vom BoringTun-FFI nicht unterstützt und mit einer protokollierten Warnung ignoriert.

Parameter für Proxy mit ShadowTLS

ShadowTLS ist ein TLS-basiertes Proxy-Protokoll, das Verkehr innerhalb einer Standard-TLS-1.3-Sitzung kapselt. Chute spricht ShadowTLS v3: Das Passwort wird als HMAC in der session_id des ClientHello übertragen, die Authentifizierung findet also innerhalb des Handshakes statt und nicht danach.

Innerhalb des aufgebauten Tunnels sendet Chute ein SOCKS5-Greeting ohne Authentifizierung und ein SOCKS5-CONNECT — der Server hinter ShadowTLS muss also ein SOCKS5-Proxy ohne Authentifizierung sein. Eine shadow-tls-Installation, die auf einen Shadowsocks- statt auf einen SOCKS5-Port weiterleitet, schließt den TLS-Handshake ab und scheitert danach.

ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome

password: Erforderlich.

Das Passwort, das für die ShadowTLS-Handshake-Authentifizierung verwendet wird.

sni (Standard: hostname)

sni=example.com

Wie bei TLS. Ihn zu schreiben schaltet zugleich die Prüfung des Tarnzertifikats ein — siehe unten.

skip-cert-verify: Optional

skip-cert-verify=true

Was die Prüfung einschaltet, ist sni=. Ist sni= geschrieben und skip-cert-verify nicht gesetzt oder false, werden die Kette und der Hostname des Zertifikats, das die Tarn-Website präsentiert, gegen diesen Namen geprüft, und ein Fehlschlag lässt die Verbindung scheitern. Ohne sni= wird das Zertifikat nicht geprüft, und bei der ersten Verwendung wird einmal je Richtlinie eine Warnung protokolliert, denn der einzige verfügbare Name ist der des Relays und nicht der der Tarn-Website. skip-cert-verify=true überspringt die Prüfung in beiden Fällen.

fingerprint: Optional

fingerprint=chrome

TLS-Client-Fingerabdruck, der nachgeahmt werden soll. Unterstützte Werte sind chrome, firefox, safari, ios, edge, 360, qq, android, random sowie die übrigen unter fingerprint genannten Namen. Die Verwendung eines gängigen Browser-Fingerabdrucks hilft, Erkennung zu vermeiden. Beachten Sie, dass android und random hier nicht eigenständig sind — sie werden wie chrome behandelt. none und jeder Wert, den Chute nicht erkennt, weisen die Verbindung ab, weil der TLS-Stack des Systems diesen Handshake nicht leisten kann.

Parameter für Proxy mit MASQUE

MASQUE ist ein HTTP/3-basiertes Proxy-Protokoll, das Datenverkehr über QUIC tunnelt. Eine MASQUE-Richtlinie erfordert type, host und port; ein Authentifizierungs-token ist optional.

ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false, mux=true

token: Optional

token=auth-token

Optionales Bearer-Authentifizierungs-Token für den MASQUE-Server. Der Alias masque-token= wird ebenfalls akzeptiert.

mode: Optional

mode=connect-udp

Wird aus Kompatibilitätsgründen akzeptiert, ändert aber das Tunneling-Verhalten nicht: TCP-Datenströme verwenden immer einen einfachen CONNECT-Tunnel und UDP-Datenströme immer connect-udp. Der Alias masque-mode= wird ebenfalls akzeptiert.

mux: Optional

mux=true

Aktiviert Multiplexing über eine gemeinsame QUIC-Verbindung.

sni / alpn / skip-cert-verify: Optional

Wie bei TLS. Da MASQUE über QUIC läuft, wird typischerweise alpn=h3 verwendet.

Parameter für Proxy mit SSH

Siehe SSH-Proxy für die vollständige Dokumentation.