Proxy-Richtlinie

Eine Proxy-Richtlinie gibt an, dass die Anfrage an einen anderen Proxyserver weitergeleitet wird. Chute unterstützt HTTP/HTTPS/SOCKS5/SOCKS5-TLS/SS/SSR/Trojan/VMess/VLESS/AnyTLS/TUIC/Hysteria2/WireGuard/ShadowTLS/MASQUE/SSH-Proxy-Protokolle.

Der Abschnitt [Proxy] deklariert Proxy-Richtlinien. Sie können mehrere Proxys 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
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.

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.

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.

Das gilt für Trojan, VMess und VLESS über TLS, einschließlich ihrer WebSocket- und gRPC-Transporte. 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.

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.

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

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. Es verwendet HTTP/2-basiertes gRPC-Framing über TLS, was helfen kann, bestimmte Netzwerkbeschränkungen zu umgehen.

grpc: Optional.

grpc=true

Aktiviert gRPC-Transport. Erfordert, dass TLS aktiviert ist.

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

Aktiviert den Multi-Modus für gRPC, der es mehreren Streams ermöglicht, eine einzelne gRPC-Verbindung für bessere Leistung zu teilen.

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: 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

Aktiviert XTLS-Transport mit dem xtls-rprx-direct-Flow. Für XTLS Vision verwenden Sie stattdessen den Parameter flow.

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 X25519-öffentliche-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. 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 (mit einer protokollierten Warnung).

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.

Achtung: Der gRPC-Transport unterstützt kein ECH. Bei grpc=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.)

ech: Optional.

ech=true

ECH aktivieren. 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.

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, sodass die Verbindung an der Authentifizierung scheitert statt still weiterzulaufen. 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.

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.

mux: Optional

mux=true

Aktiviert Verbindungswiederverwendung / Multiplexing. Die Aliase multiplex und reuse werden ebenfalls akzeptiert. Unterstützt von Trojan, VMess, VLESS, Hysteria2, Shadowsocks(R), ShadowTLS und MASQUE.

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.

underlying-proxy: Optional.

underlying-proxy=OtherProxy

Proxy-Verkettung: Der Wert benennt eine andere Richtlinie, die den Datenverkehr dieser Richtlinie tragen soll. Wird geparst und beim Speichern der Konfiguration bewahrt, ist im aktuellen Kernel aber ohne Wirkung — es wird eine Warnung protokolliert, und die Richtlinie verbindet sich weiterhin direkt mit ihrem eigenen Server.

Hinweis: Beim Import eines Clash-/mihomo-Profils wird diese Option aus dialer-proxy erzeugt; eine Richtlinie kann nach einem Import also verkettet aussehen, während ihr Datenverkehr es nicht ist.

test-url: Optional.

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

Eine Latenztest-URL pro Richtlinie. Wird akzeptiert und beim Speichern der Konfiguration bewahrt, aber nie gelesen: Für Messungen wird stets die url der Richtliniengruppe verwendet, die die Richtlinie enthält. Anders als bei einer unbekannten Option entsteht dabei keine Warnung, da sie auf der Liste der erkannten Optionen steht.

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 + (oder ,), 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.

Parameter für Proxy mit TUIC

TUIC ist ein QUIC-basiertes Proxy-Protokoll, das gemultiplextes TCP- und UDP-Relay bietet.

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 mit Brutal Congestion Control 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.

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 ausgehende Proxy-Richtlinie, 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 WireGuard-Peer-öffentlicher-Schlüssel.

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.

keepalive: Optional (Sekunden).

keepalive=25

Persistentes Keepalive-Intervall für NAT-Traversal.

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 im aktuellen Kernel 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. Es verwendet einen passwortbasierten Handshake nach dem TLS-Handshake, um die Proxy-Verbindung zu authentifizieren und herzustellen.

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.

skip-cert-verify: Optional

skip-cert-verify=true

Wie bei TLS.

fingerprint: Optional

fingerprint=chrome

TLS-Client-Fingerabdruck, der nachgeahmt werden soll. Unterstützte Werte sind chrome, firefox, safari, ios, edge, 360, qq, android, random. 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 (mit einer protokollierten Warnung).

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

Multiplexing über eine gemeinsame QUIC-Verbindung aktivieren (abhängig von der Connection-Pool-Einstellung).

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.