Serveur proxy

Un serveur proxy transmet les requêtes à un proxy en amont. Chute prend en charge les protocoles de proxy HTTP/HTTPS/SOCKS5/SOCKS5-TLS/SS/SSR/Trojan/VMess/VLESS/AnyTLS/TUIC/Hysteria2/WireGuard/AmneziaWG/ShadowTLS/MASQUE/SSH.

La section [Proxy] déclare les serveurs proxy. Vous pouvez créer plusieurs serveurs proxy pour des règles différentes.

Exemple :

[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://....

Remarque : une politique Trojan exige un tls=true explicite — le TLS n'est pas implicite. Sans lui (et sans grpc=true, qui passe toujours par TLS), la politique se connecte en clair, et le journal le signale au chargement de la configuration : Trojan policy <name> has no tls=true; it connects without TLS. L'importation d'un profil Clash/mihomo écrit tls=true sur chaque nœud Trojan.

Remarque : scheme accepte un lien de partage de l'un de ces types : ss://, ssr://, anytls://, tuic://, hysteria2:// et shadowtls://. Un lien de tout autre type fait de la ligne une erreur de configuration.

Paramètres

Paramètres des proxys avec TLS

tls : facultatif.

tls=true

Active le transport TLS.

skip-cert-verify : facultatif

skip-cert-verify=true

Lorsque cette option est activée, Chute ne vérifie pas le certificat du serveur. true, 1 et yes l'activent tous, si bien que les liens de partage qui écrivent insecure=1 fonctionnent. skip-common-name-verify=true, la graphie Shadowrocket sur les lignes socks5-tls, est lue comme la même option.

sni (par défaut : nom d'hôte)

sni=exmaple.com

Vous pouvez personnaliser l'indication de nom de serveur (SNI) lors de la poignée de main TLS. Par défaut, Chute envoie le SNI avec le nom d'hôte, comme la plupart des navigateurs.

fingerprint : facultatif.

fingerprint=chrome

Présente le ClientHello TLS d'un navigateur plutôt que celui du système, afin que la poignée de main ne se distingue pas comme provenant d'un client proxy. Les valeurs prises en charge sont chrome, firefox, safari et ios, ainsi que edge, 360, qq, android et random, toutes traitées comme Chrome. Les noms qu'utilisent mihomo, sing-box et Xray sont acceptés aussi et ramenés à ces quatre préréglages : randomized, chrome_pq et hellochrome_131, par exemple, sont traités comme Chrome, hellofirefox_120 comme Firefox, hellosafari_16_0 comme Safari et helloios_14 comme iOS. Le hellogolang de Xray n'a pas de préréglage.

Cela s'applique à Trojan, VMess et VLESS sur TLS, y compris leurs transports WebSocket et gRPC, ainsi qu'à Shadowsocks et ShadowsocksR sur WebSocket avec TLS. REALITY et ShadowTLS acceptent la même option dans leurs propres sections. Pour définir une empreinte unique pour toute politique qui n'en nomme pas, utilisez global-client-fingerprint. Elle s'applique toujours aux politiques ShadowTLS, aux politiques VLESS qui définissent tls=true ou reality=true, aux politiques Trojan et VMess qui définissent tls=true, et aux politiques Shadowsocks qui définissent à la fois ws=true et tls=true ; une politique sur le transport gRPC doit elle aussi écrire tls=true. Elle ne s'applique jamais aux politiques ShadowsocksR.

Sur ces protocoles, fingerprint=none — ou unsafe, qui veut dire la même chose — choisit la pile TLS du système et l'emporte sur global-client-fingerprint. REALITY et ShadowTLS ne peuvent se passer de la poignée de main de navigateur : là, none fait refuser la connexion. Une valeur que Chute ne reconnaît pas fait refuser les connexions de la politique au lieu de se rabattre sur le TLS du système, quel que soit le protocole : rien n'est envoyé au serveur, la connexion échoue (un groupe url-test ou fallback la compte comme n'importe quel autre échec), et le chargement de la configuration journalise Policy <name>: fingerprint '<value>' is not supported; connections through this policy are refused. Un global-client-fingerprint non reconnu, lui, est seulement ignoré.

Définir une empreinte active également l'échange de clés post-quantique : Chute propose alors le groupe hybride X25519MLKEM768 aux côtés de X25519, de sorte que la session ne pourra pas être déchiffrée ultérieurement par un attaquant qui l'enregistrerait aujourd'hui et disposerait d'un ordinateur quantique demain. Un serveur qui ne connaît pas ce groupe choisit simplement X25519 ; rien ne casse. Sans empreinte, la connexion utilise la pile TLS du système, qui ne le propose pas — c'est la même raison pour laquelle ECH exige une empreinte.

Paramètres des proxys avec Shadowsocks

method : requis.

Prise en charge actuelle :

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

Méthodes Shadowsocks 2022

Chute prend en charge le protocole Shadowsocks 2022, qui utilise une dérivation de clé fondée sur BLAKE3 et des chiffrements AEAD. Le nom de la méthode détermine la suite de chiffrement :

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

Format du mot de passe :

Le champ mot de passe de SS2022 se compose d'une ou deux clés encodées en base64, séparées par : (deux-points).

Mode mono-utilisateur (une clé) :

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

Mode multi-utilisateurs avec en-têtes d'identité (deux clés) :

Pour 2022-blake3-aes-128-gcm et 2022-blake3-aes-256-gcm, vous pouvez fournir une clé d'en-tête d'identité et une clé utilisateur, séparées par : :

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

Chaque clé est une chaîne encodée en base64 (le base64 standard comme le base64 compatible URL sont pris en charge). Longueurs de clé requises :

Générer une clé :

openssl rand -base64 32

Remarque : les méthodes SS2022 ne prennent pas en charge le paramètre obfs. La méthode 2022-blake3-chacha20-poly1305 ne prend pas en charge le mode multi-utilisateurs.

Méthodes Shadowsocks AEGIS

Chute prend également en charge la famille de chiffrements AEAD AEGIS. Ils reposent sur la fonction de tour d'AES et sont nettement plus rapides qu'AES-GCM ou ChaCha20-Poly1305 sur tout processeur doté d'AES matériel, ce qui inclut tous les iPhone, iPad, Apple TV et Mac récents :

aegis-128l
aegis-256

Ils se configurent comme les méthodes AEAD classiques ci-dessus — le mot de passe est une phrase secrète ordinaire, et non une clé base64 :

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

Tout le reste suit SIP004 sans changement : le sel est aussi long que la clé, la sous-clé de session est HKDF-SHA1(key, salt, "ss-subkey"), la charge utile TCP est transportée en blocs AEAD préfixés d'une longueur avec incrémentation du nonce après chaque opération, et l'UDP utilise un nonce entièrement nul.

Vous devez exploiter le serveur vous-même. AEGIS ne fait pas partie de la spécification Shadowsocks — aucun SIP ne le définit, et aucun serveur Shadowsocks grand public ne l'implémente, y compris shadowsocks-rust, shadowsocks-libev, shadowsocks-go, sing-box et Xray. Choisir l'une de ces méthodes ne fonctionne que face à un serveur que vous exploitez et qui a été construit pour les prendre en charge. Si vous pointez Chute vers un nœud commercial ou partagé, utilisez plutôt l'une des méthodes interopérables ci-dessus.

obfs : facultatif.

Prise en charge actuelle :

tls
http

obfs_param : facultatif.

obfs_param=example.com

Définit l'hôte utilisé par la couche obfs. Vaut cloudfront.net par défaut lorsqu'il n'est pas défini.

WebSocket (v2ray-plugin) : facultatif.

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

Transporte le flux Shadowsocks à l'intérieur d'un WebSocket, comme le fait le mode websocket de v2ray-plugin, si bien que la politique atteint un serveur Shadowsocks placé derrière v2ray-plugin, y compris quand un CDN se trouve devant. Les options sont celles du transport WebSocket et de TLS. Les méthodes Shadowsocks 2022 fonctionnent aussi par-dessus, et les politiques ShadowsocksR acceptent les mêmes options tout en gardant leur propre protocole et leur obfs.

• ws-path vaut / par défaut, et un chemin écrit sans barre oblique initiale en reçoit une.
• Le Host de la requête de mise à niveau est le Host de ws-headers, utilisé tel qu'il est écrit. À défaut, c'est le sni — ou l'adresse du serveur s'il n'y a pas de sni — suivi de :<port>.
• tls=true fait passer TLS sous le WebSocket. sni, skip-cert-verify, fingerprint et les options ECH fonctionnent comme pour Trojan. Sans ws=true, tls=true ne fait rien : la politique se connecte sans TLS, et la ligne reçoit l'avis Shadowsocks tls=true only applies with ws=true (the v2ray-plugin transport); this policy connects without TLS.
• ws-mux (par défaut true) ouvre une session mux.cool sur chaque WebSocket, ce qu'attend un serveur v2ray-plugin démarré avec sa valeur par défaut mux=1. Pour un serveur démarré avec mux=0, écrivez ws-mux=false.
• Si la même ligne porte aussi obfs=, c'est le WebSocket qui est utilisé et simple-obfs n'est pas appliqué ; le chargement de la configuration journalise Policy <name> ignored unsupported option(s): obfs.
• L'UDP ne passe pas par le plugin : c'est de l'UDP Shadowsocks ordinaire, envoyé directement à host:port, qui ne traverse pas un CDN. Écrivez udp-relay=false pour un serveur que vous atteignez via un CDN. Si le serveur Shadowsocks derrière le plugin parle UoT, udp-over-tcp=true transporte plutôt l'UDP dans les flux de la politique, et donc aussi à travers le WebSocket.
• Le mode quic de v2ray-plugin n'est pas pris en charge.

L'écriture de Shadowrocket est lue aussi : obfs=websocket (ou obfs=ws), avec le Host dans obfsParam ou obfs-host et le chemin dans path ou obfs-uri. La politique est enregistrée sous la forme ws=true. Toute autre valeur obfs que la pile Shadowsocks ne sait pas lire — le wss de Quantumult X, ou une faute de frappe — est nommée dans un avis, et la politique se connecte en Shadowsocks simple : 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 : facultatif.

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

Transporte l'UDP de la politique dans des connexions TCP de la politique au lieu du relais UDP du serveur — l'UDP sur TCP (UoT) de sing-box. Chaque flux UDP reçoit sa propre connexion vers l'adresse de rendez-vous que le serveur reconnaît (sp.v2.udp-over-tcp.arpa, ou sp.udp-over-tcp.arpa pour la version 1). Ce sont des connexions ordinaires de la politique : elles suivent donc son underlying-proxy comme toutes les autres. L'UDP fonctionne alors via un amont qui ne transporte pas d'UDP, comme un proxy HTTP, et à travers le transport WebSocket. Le serveur doit prendre en charge UoT, comme le font les serveurs sing-box et mihomo. Les méthodes Shadowsocks 2022 fonctionnent avec.

• udp-over-tcp-version (par défaut 2) : la version 2 ouvre chaque connexion par une requête qui nomme la destination, puis délimite chaque datagramme par sa longueur ; la version 1 n'a pas de requête et place l'adresse devant chaque datagramme. La version par défaut de mihomo est la 1 : un profil importé de mihomo écrit donc la version. Toute autre valeur est signalée, utilisée comme 2 et conservée telle qu'écrite à l'enregistrement du profil.
• udp-relay=false désactive toujours l'UDP de la politique.
• Dans l'éditeur Shadowsocks de l'application, ce sont l'interrupteur UDP sur TCP et le choix Version UoT.

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

Paramètres des proxys avec ShadowsocksR/ShadowsocksRR/ShadowsocksR-Akarin

method : requis.

Prise en charge actuelle :

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

Prise en charge actuelle :

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

obfs : facultatif.

Prise en charge actuelle :

plain
http_simple
http_post
tls1.2_ticket_auth

obfs_param : facultatif.

Paramètres des proxys avec WebSocket

Le transport WebSocket est disponible pour Trojan, VMess et VLESS, ainsi que pour Shadowsocks et ShadowsocksR, où il correspond au mode websocket de v2ray-plugin — voir WebSocket (v2ray-plugin) pour ce qui diffère.

ws : facultatif.

ws=true

Active le transport WebSocket.

ws-path : facultatif.

ws-path=/exmaple

Change le chemin de la requête HTTP WebSocket.

ws-headers : facultatif.

ws-headers=Header1:Value1|Header2:Value2

Modifie l'en-tête HTTP de la requête HTTP WebSocket.

Paramètres des proxys avec gRPC

Le transport gRPC est disponible pour les protocoles Trojan, VMess et VLESS. Il utilise un cadrage gRPC fondé sur HTTP/2 par-dessus TLS, ce qui peut aider à contourner certaines restrictions réseau.

grpc : facultatif.

grpc=true

Active le transport gRPC. Le transport passe toujours par TLS, quelle que soit la valeur tls de la politique. Écrivez tout de même tls=true si la politique doit recevoir global-client-fingerprint, qui ne s'applique à une politique gRPC que si elle le définit.

grpc-service-name : requis lorsque grpc=true.

grpc-service-name=MyService

Indique le nom/chemin du service gRPC pour le multiplexage. Il doit correspondre au nom de service configuré sur le serveur ; il n'y a pas de valeur par défaut.

grpc-multi-mode : facultatif.

grpc-multi-mode=true

Utilise le mode multi d'Xray : le tunnel appelle /<service>/TunMulti au lieu de /<service>/Tun, et plusieurs écritures voyagent dans un même message gRPC. Le serveur doit prendre en charge le mode multi. Chaque tunnel garde malgré tout sa propre connexion.

Exemple avec VMess et gRPC :

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

Paramètres des proxys avec XHTTP

Le transport XHTTP est disponible pour les protocoles Trojan, VMess et VLESS. Au lieu de maintenir une connexion ouverte, il transporte le tunnel dans des requêtes HTTP ordinaires : la réception arrive sous forme d'une longue réponse persistante, et l'envoi part soit en une série de POST, soit en un unique POST persistant. Cela le rend utilisable à travers un CDN, ce qui est la principale raison de le préférer à WebSocket ou gRPC.

La version HTTP ne se configure pas directement. Sans TLS, c'est HTTP/1.1 ; avec TLS, c'est HTTP/2, sauf si alpn indique exactement http/1.1 (HTTP/1.1) ou exactement h3 (HTTP/3). REALITY utilise toujours HTTP/2.

xhttp : facultatif.

xhttp=true

Active le transport XHTTP.

xhttp-mode : facultatif.

xhttp-mode=packet-up

Manière dont l'envoi est transporté. auto (la valeur par défaut) signifie packet-up, ou stream-one lorsque REALITY est utilisé.

• packet-up — l'envoi est une série de POST numérotés. Le choix le plus compatible, et celui que les CDN gèrent le mieux.
• stream-up — l'envoi est un unique POST persistant, la réception se faisant sur une requête distincte.
• stream-one — une même requête transporte les deux sens. Nécessite un serveur et tout équipement intermédiaire prenant en charge le HTTP full-duplex.

Le serveur impose généralement un mode ; une divergence reçoit une réponse 400.

xhttp-path : facultatif.

xhttp-path=/yourpath

Le chemin de la requête. Vaut / par défaut. Il doit correspondre au chemin sur lequel le serveur sert XHTTP.

xhttp-host : facultatif.

xhttp-host=example.com

L'autorité utilisée dans l'en-tête Host et dans l'URL de requête. Vaut sni par défaut, et l'adresse du serveur lorsque celui-ci n'est pas défini.

xhttp-headers : facultatif.

xhttp-headers=Header1:Value1|Header2:Value2

En-têtes HTTP supplémentaires, au même format que ws-headers.

xhttp-padding : facultatif.

xhttp-padding=100-1000

Plage de longueur du remplissage que porte chaque requête, sous la forme MIN-MAX ou d'un seul nombre. Vaut 100-1000 par défaut. Le serveur exige le remplissage et en valide la longueur ; cette valeur doit donc rester dans la plage acceptée par le serveur — une requête sans remplissage, ou avec une quantité erronée, reçoit une réponse 400.

xhttp-max-post-bytes : facultatif.

xhttp-max-post-bytes=1000000

Taille maximale d'un POST d'envoi, en octets. Vaut 1000000 par défaut. Les écritures plus volumineuses sont réparties sur plusieurs POST.

xhttp-min-post-interval : facultatif.

xhttp-min-post-interval=30

Intervalle minimal entre deux POST d'envoi consécutifs, en millisecondes. Vaut 30 par défaut.

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

xhttp-xmux-max-concurrency=4

XMUX regroupe les connexions HTTP/2 sous-jacentes afin que plusieurs tunnels en partagent une, ce qui ressemble à une session de navigateur ordinaire plutôt qu'à une connexion par tunnel. Les quatre valent 0 par défaut, ce qui laisse le regroupement désactivé.

• xhttp-xmux-max-concurrency — tunnels autorisés à partager une connexion.
• xhttp-xmux-max-connections — connexions autorisées par serveur.
• xhttp-xmux-max-reuse-times — tunnels qu'une connexion sert avant de cesser d'en accepter de nouveaux.
• xhttp-xmux-max-lifetime — secondes au bout desquelles une connexion cesse d'accepter de nouveaux tunnels.

Notez que mux=true est refusé pour une politique XHTTP, quel que soit son protocole, et que le chargement de la configuration journalise Policy <name> ignored unsupported option(s): mux : XHTTP apporte son propre multiplexage, et empiler le multiplexage générique par-dessus le doublerait.

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

xhttp-download-server=cdn.example.com

Achemine la réception par une adresse différente — typiquement un CDN devant le même serveur — tandis que l'envoi continue d'utiliser l'adresse principale. Les deux doivent atteindre le même serveur : la session est un état côté serveur, une seconde route est donc acceptable, mais pas un second serveur.

Exemple avec VLESS et XHTTP :

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

Paramètres des proxys avec XTLS

xtls : facultatif.

xtls=true

Enveloppe le transport dans XTLS. Seul, il n'annonce aucun flux : la requête VLESS porte un bloc addons vide, et aucun flux n'est donc négocié. Utilisez flow=xtls-rprx-vision ci-dessous pour en annoncer un ; xtls-rprx-direct n'est pas implémenté.

flow : facultatif.

flow = xtls-rprx-vision

Sélectionne le contrôle de flux XTLS. La seule valeur prise en charge est xtls-rprx-vision, qui active le cadrage Vision ; la valeur de flux est envoyée au serveur dans les addons VLESS.

skip-cert-verify : facultatif

skip-cert-verify=true

Identique à TLS.

sni (par défaut : nom d'hôte)

sni=exmaple.com

Identique à TLS.

Paramètres des proxys avec REALITY

REALITY est une technique d'obfuscation fondée sur TLS qui rend le trafic proxy indiscernable du trafic TLS ordinaire vers un vrai site web. Elle s'utilise avec le protocole VLESS.

reality : facultatif.

reality=true

Active l'obfuscation REALITY. Nécessite un serveur cible qui servira de destination de camouflage.

public-key : requis.

public-key=BASE64KEY

La clé publique X25519 du serveur (base64). La poignée de main REALITY ne peut pas être construite sans elle.

short-id : facultatif.

short-id=abcd1234

Un identifiant court utilisé pour l'authentification REALITY. Typiquement une chaîne hexadécimale.

server-name : facultatif.

server-name=www.microsoft.com

Le SNI (indication de nom de serveur) à présenter lors de la poignée de main TLS. Il devrait s'agir d'un site web réel et couramment consulté, pour un meilleur effet de camouflage. Le certificat du serveur cible doit correspondre à ce nom.

fingerprint : facultatif.

fingerprint=chrome

Empreinte de client TLS à imiter. Les valeurs prises en charge comprennent chrome, firefox, safari, ios, edge, 360, qq, android, random, ainsi que les autres noms cités sous fingerprint. Utiliser une empreinte de navigateur courante aide à éviter la détection. Notez qu'android et random ne sont pas distincts ici — ils sont traités comme chrome. none et toute valeur que Chute ne reconnaît pas font refuser la connexion, car la pile TLS du système ne sait pas mener cette poignée de main.

spiderx : facultatif.

spiderx=/path

Chemin personnalisé pour le camouflage spider de REALITY.

Exemple avec 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

Remarque : REALITY n'utilise pas de certificat classique. La connexion s'appuie sur le véritable certificat du serveur de camouflage.

Paramètres des proxys avec ECH

Encrypted Client Hello masque le nom du serveur à quiconque observe la connexion. Le vrai nom circule chiffré à l'intérieur de la poignée de main, tandis que le nom visible sur le réseau est le public_name publié par l'ECHConfig du serveur.

ECH repose sur la même pile que l'empreinte du client ; une politique doit donc également définir fingerprint — sans elle, ech=true ne fait rien et le vrai nom est envoyé en clair. Cela s'applique à Trojan, VMess et VLESS sur TLS simple, y compris leurs transports WebSocket, ainsi qu'à Shadowsocks et ShadowsocksR sur WebSocket avec TLS.

Remarque : les transports gRPC et XHTTP ne prennent pas en charge ECH. Avec grpc=true ou xhttp=true, ech=true est silencieusement ignoré et le vrai nom du serveur est envoyé en clair. (L'empreinte du client et l'échange de clés post-quantique s'appliquent bien à gRPC et à XHTTP.)

ech : facultatif.

ech=true

Active ECH. Sauf si ech-config est défini, Chute recherche l'ECHConfig dans l'enregistrement DNS HTTPS du nom de serveur, comme le fait un navigateur.

ech-config : facultatif.

ech-config=AEX+DQBBAAAgACD...

Une ECHConfigList en base64, utilisée à la place de la recherche DNS. Définissez-la lorsque le serveur ne publie pas d'enregistrement HTTPS, ou pour épingler une configuration précise. La définir active ECH à elle seule ; il n'est pas nécessaire d'ajouter ech=true.

ech-public-name : facultatif.

ech-public-name=cover.example.com

Remplace le nom de couverture envoyé en clair. Par défaut, il s'agit du public_name contenu dans l'ECHConfig, qui est ce que le serveur attend ; ne définissez ceci que pour un déploiement qui place la configuration derrière un hôte différent.

Exemple avec Trojan :

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

Si le serveur rejette ECH — le plus souvent parce que la configuration est devenue obsolète — il répond sous le nom de couverture et présente le certificat de ce nom, et la poignée de main se replie sur le TLS extérieur. Tant que la vérification du certificat est active, la connexion échoue alors à l'authentification plutôt que de se poursuivre discrètement ; avec skip-cert-verify=true, rien ne vérifie ce nom et la session se poursuit en silence sous le nom de couverture. Actualisez ech-config, ou retirez-le pour revenir à la recherche DNS.

TCP Fast Open (expérimental)

tfo : facultatif

tfo=true

Plus d'informations sur TCP Fast Open sont disponibles sur Wikipédia. Activer TCP Fast Open peut provoquer des échecs de connexion inattendus. Chute Android ignore tfo.

Paramètres communs

udp-relay : facultatif (par défaut : true)

udp-relay=false

Marque la politique comme TCP uniquement. Le relais UDP est activé par défaut lorsque le protocole le permet ; définissez udp-relay=false pour exclure la politique du relais de trafic UDP. Trojan relaie l'UDP sur une connexion TLS simple vers le port du serveur — sans WebSocket, gRPC ni XHTTP, et sans ECH, mais avec l'empreinte de la politique —, si bien que, face à un serveur qui ne sert que l'un de ces transports, il faut définir udp-relay=false.

mux : facultatif

mux=true

Active la réutilisation de connexion / le multiplexage. Les alias multiplex et reuse sont également acceptés. Pris en charge par HTTP/HTTPS, SOCKS5/SOCKS5-TLS, Trojan, VMess, VLESS, Hysteria2, Shadowsocks(R), ShadowTLS et MASQUE. AnyTLS, TUIC et SSH ne sont multiplexés sur aucune plateforme. Pour ceux-ci, mux=true n'est pas appliqué, et le journal le signale au chargement de la configuration : Policy <name>: mux=true is not applied: <reason>.

Hysteria2 et MASQUE multiplexent sur une seule connexion QUIC partagée. Tout autre protocole transporte les connexions multiplexées dans un cadrage propre à Chute, que seul un serveur qui le comprend sait défaire : les serveurs Xray, sing-box et Shadowsocks standard ne le savent pas, n'activez donc pas mux pour eux.

cert-fingerprint-sha256 : facultatif

cert-fingerprint-sha256=<hex>

Épingle le certificat du serveur par son empreinte SHA-256. L'alias cert-fp est également accepté. Effectif uniquement pour MASQUE actuellement.

encrypt-method (VMess) : facultatif (par défaut : auto)

encrypt-method=aes-128-gcm

Chiffrement de la charge utile VMess. Valeurs prises en charge : aes-128-gcm, chacha20-poly1305, aes-128-cfb (alias legacy), none.

alpn : facultatif

alpn=h2|http/1.1

Plusieurs valeurs ALPN se séparent par |. Seuls TUIC, Hysteria2 et MASQUE la lisent — chacun retombant sur h3 lorsqu'elle n'est pas définie —, ainsi que XHTTP, où elle sélectionne la version HTTP que parle le transport. Tout autre protocole ignore cette option et propose l'ALPN que décide son transport : h2 pour gRPC ; lorsqu'une empreinte est définie, http/1.1 pour WebSocket et h2,http/1.1 pour du TLS simple ; sinon, aucun dans les deux cas, puisque c'est alors la pile TLS du système qui mène la poignée de main.

underlying-proxy : facultatif.

underlying-proxy=OtherProxy

Chaînage de proxys : la valeur nomme une autre politique ou un groupe de politiques qui transporte le trafic de celle-ci. L'amont est choisi avant que la politique n'ouvre sa propre connexion au serveur ; A = ..., underlying-proxy=B fait donc passer A par B. B peut à son tour nommer une liaison amont pour plusieurs sauts. Une valeur vide, ou DIRECT, se connecte directement. Mettez entre guillemets un nom qui contient une espace ou une virgule, comme dans underlying-proxy="HK 01". Un nom introuvable fait échouer la connexion (jamais de passage en direct) et est consigné ; aucun repli vers DIRECT n'a lieu.

Une boucle faite de références fixes — y compris celle qui revient par le propre underlying-proxy du premier membre d'un groupe de relais — est refusée au chargement de la configuration. Une boucle qui n'existe qu'à cause du choix actuel d'un groupe de politiques n'est pas refusée définitivement : dès que le groupe choisit autrement, la politique fonctionne, mais tant que la boucle subsiste, chaque connexion qui passe par elle est refusée. Quelle que soit la forme de la chaîne, une connexion qui imbriquerait plus de 16 niveaux d'amont est refusée plutôt que dépliée sans fin.

L'amont résout aussi le nom du serveur de cette politique : un serveur chaîné n'est jamais interrogé par le résolveur local, et Chute ne lui envoie pas de ping direct — pas plus qu'à une politique placée après le premier membre d'un groupe de relais. Sa latence vient des vérifications d'état des groupes et du test de latence, qui l'atteignent tous deux par la chaîne — les groupes url-test, fallback et load-balance mesurent un membre chaîné par le même chemin qu'une connexion.

Tout protocole peut être chaîné, sauf Tailscale (la politique intégrée TAILSCALE), dont le moteur ouvre lui-même ses connexions. Une politique qui joint son serveur par un flux — HTTP, SOCKS5, Shadowsocks, VMess, VLESS, Trojan, AnyTLS, SSH, XHTTP sur HTTP/1.1 ou HTTP/2 et les autres — ouvre ce flux à travers l'amont. Hysteria2, TUIC, MASQUE et XHTTP sur HTTP/3 (TLS avec alpn=h3) parlent QUIC, et WireGuard et AmneziaWG envoient leurs propres datagrammes : ils passent donc par le relais UDP de l'amont. L'amont — pour un groupe, son choix actuel — doit transporter l'UDP, comme le font Shadowsocks, SOCKS5, VMess, VLESS, Trojan et Hysteria2, et non un proxy HTTP ou HTTPS. Sur un amont qui ne transporte pas l'UDP, chaque connexion qui passe par eux est refusée et consignée, jamais envoyée directement. Une fois chaînée, une politique QUIC envoie des datagrammes d'au plus 1200 octets, et un tunnel WireGuard ou AmneziaWG utilise une MTU interne de 1280 sauf si une MTU est écrite (mtu, ou wg-mtu dans sa section), pour que les datagrammes encapsulés tiennent encore dans un chemin de 1500 octets. WireGuard, AmneziaWG et SSH gardent une seule connexion pour tout leur trafic, par leur propre amont : aucun d'eux ne peut donc être un membre ultérieur d'un groupe de relais.

L'UDP passe lui aussi par la chaîne. VMess, VLESS, Trojan et AnyTLS transportent l'UDP dans un flux, si bien que leur UDP fonctionne par n'importe quel amont. Shadowsocks (ShadowsocksR et Shadowsocks 2022 compris) et SOCKS5 relaient l'UDP en datagrammes, tout comme les protocoles QUIC et WireGuard : leur UDP ne fonctionne que tant que l'amont transporte l'UDP — sauf pour un nœud Shadowsocks qui utilise udp-over-tcp : il transporte son UDP dans des flux et fonctionne donc par n'importe quel amont. Les politiques SSH, HTTP et HTTPS ne transportent aucun UDP. L'UDP qu'une politique chaînée ne peut pas transporter suit udp-policy-not-supported-behaviour (REJECT par défaut).

dialer-proxy (mihomo) et detour (sing-box) sont importés dans cette option, et le override: dialer-proxy d'un fournisseur de proxy dans l'underlying-proxy du fournisseur. Un groupe relay de Clash ou mihomo reste un groupe de relais, avec ses membres dans le même ordre. Pour faire passer tous les membres d'un groupe de politiques par un même amont, définissez underlying-proxy sur le groupe. Pour faire passer toutes les politiques de proxy par un même amont, définissez global-underlying-proxy dans [General].

test-url : facultatif.

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

L'URL de test de latence de cette politique lorsqu'elle est membre d'un groupe url-test ou fallback : le groupe mesure ce membre avec cette URL au lieu de sa propre url. Sans elle, l'URL du groupe est utilisée.

interface : facultatif

interface=en0

Fait sortir les connexions TCP que cette politique ouvre vers son serveur par l'interface réseau nommée — par exemple en0 sur un Mac, wlan0 sur Android — au lieu de celle que choisit la route par défaut. Lorsque cette interface n'est pas disponible, la connexion échoue plutôt que de partir par un autre chemin ; allow-other-interface=true lui permet de suivre plutôt la route par défaut. Cela fonctionne sur Chute Mac et Chute Android ; iOS et tvOS l'ignorent. Le relais UDP n'est pas lié à l'interface, pas plus que les protocoles fondés sur QUIC (TUIC, Hysteria2, MASQUE), WireGuard ou Tailscale.

Paramètres des proxys avec AnyTLS

AnyTLS est un protocole de proxy fondé sur TLS avec obfuscation par remplissage.

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

password : requis.

Le mot de passe / la phrase secrète utilisés pour l'authentification.

sni (par défaut : nom d'hôte)

sni=exmaple.com

Identique à TLS.

skip-cert-verify : facultatif

skip-cert-verify=true

Identique à TLS.

Schéma de remplissage : facultatif

Le remplissage se configure avec stop=N et des clés numériques par paquet :

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

Chaque schéma est une liste de segments joints par +, un segment étant soit c (vérification), soit une plage d'octets min-max (16384 au maximum), par ex. stop=2, 0=30-30, 1=100-400+c. Une , fait aussi office de séparateur, mais seulement si la valeur est entre guillemets — 1="100-400,c" — car une virgule non protégée termine le champ et casse la ligne. Préférez +.

Paramètres des proxys avec TUIC

TUIC est un protocole de proxy fondé sur QUIC offrant un relais TCP et UDP multiplexé. Le mot-clé tuic-v5 (graphie de Surge) est également accepté ; la politique est enregistrée sous tuic.

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

uuid : requis.

L'UUID d'authentification.

password : requis.

Le mot de passe d'authentification.

sni (par défaut : nom d'hôte)

sni=exmaple.com

Identique à TLS.

skip-cert-verify : facultatif

skip-cert-verify=true

Identique à TLS.

alpn : facultatif

alpn=h3

Indique la chaîne ALPN de la connexion QUIC.

Paramètres des proxys avec Hysteria2

Hysteria2 est un protocole de proxy fondé sur QUIC, destiné aux scénarios à haut débit.

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

auth : requis.

Le mot de passe / jeton d'authentification.

sni (par défaut : nom d'hôte)

sni=exmaple.com

Identique à TLS.

skip-cert-verify : facultatif

skip-cert-verify=true

Identique à TLS.

up : facultatif (Mbit/s)

up=10

Bande passante d'envoi en Mbit/s. Accepté et conservé, mais inutilisé : il alimente le contrôleur de congestion Brutal de Hysteria2, que ce moteur n'exécute pas. Un avis est consigné pour chaque politique qui le définit. C'est down= qui atteint le réseau, en tant que débit déclaré par le client lors de l'authentification.

down : facultatif (Mbit/s)

down=100

Bande passante de réception en Mbit/s.

alpn : facultatif

alpn=h3

Indique la chaîne ALPN de la connexion QUIC.

obfs : facultatif

obfs=salamander

Active l'obfuscation Salamander du trafic QUIC. Salamander utilise un XOR BLAKE2b-256 pour obfusquer les paquets QUIC, les rendant résistants à l'inspection approfondie des paquets (DPI).

obfs-password : facultatif

obfs-password=your-obfuscation-key

Le mot de passe / la clé utilisés pour l'obfuscation Salamander. Requis lorsque obfs=salamander est défini.

Paramètres des proxys avec WireGuard

WireGuard est un protocole VPN moderne. Chute prend en charge WireGuard comme serveur proxy sortant, soit en ligne, soit en référençant une section [WireGuard] nommée.

Configuration en ligne :

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

Référence de section (recommandé) :

WireGuard = wireguard, section-name=wg0

Consultez Configuration WireGuard pour la syntaxe de la section [WireGuard].

private-key : requis (en ligne uniquement).

Clé privée WireGuard encodée en base64.

peer-public-key : requis (en ligne uniquement).

Clé publique du pair WireGuard, encodée en base64.

self-ip : facultatif (en ligne).

Adresse IP locale attribuée à l'interface WireGuard (par ex. 10.0.0.2).

self-ip-v6 : facultatif (en ligne).

Adresse IPv6 locale attribuée à l'interface WireGuard.

server : requis.

Adresse du serveur WireGuard distant (elle peut provenir de la section [WireGuard] référencée plutôt que de la ligne de politique).

port : requis.

Port du serveur WireGuard distant (il peut provenir de la section [WireGuard] référencée plutôt que de la ligne de politique).

preshared-key : facultatif.

Clé pré-partagée encodée en base64, pour la résistance post-quantique.

allowed-ips : facultatif (en ligne).

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

Les destinations que le pair transporte, sous forme de CIDR séparés par des virgules ; mettez la valeur entre guillemets, puisqu'elle contient des virgules. Une destination située en dehors est refusée ou abandonnée, car le pair ne peut pas en router le retour. Sans cette option, tout est transporté. Consultez Configuration WireGuard pour la forme en section.

keepalive : facultatif (secondes).

keepalive=25

Intervalle de keepalive persistant pour la traversée de NAT. Sans cette option, aucun keepalive n'est envoyé.

mtu : facultatif.

mtu=1420

MTU de l'interface WireGuard.

reserved : facultatif.

reserved=0,1,2

Octets réservés de l'en-tête de paquet WireGuard. Analysé mais sans effet dans le moteur actuel — la valeur n'est pas prise en charge par le FFI BoringTun et est ignorée, avec un avertissement consigné.

Paramètres des proxys avec ShadowTLS

ShadowTLS est un protocole de proxy fondé sur TLS qui encapsule le trafic dans une session TLS 1.3 standard. Chute parle ShadowTLS v3 : le mot de passe est porté sous forme de HMAC dans le session_id du ClientHello, si bien que l'authentification a lieu à l'intérieur de la poignée de main plutôt qu'après elle.

À l'intérieur du tunnel établi, Chute envoie une salutation SOCKS5 sans authentification puis un CONNECT SOCKS5 : le serveur derrière ShadowTLS doit donc être un proxy SOCKS5 sans authentification. Un déploiement shadow-tls qui redirige vers un port Shadowsocks plutôt que vers un port SOCKS5 termine la poignée de main TLS puis échoue.

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

password : requis.

Le mot de passe utilisé pour l'authentification de la poignée de main ShadowTLS.

sni (par défaut : nom d'hôte)

sni=example.com

Identique à TLS. C'est aussi le fait de le renseigner qui active la vérification du certificat de couverture — voir ci-dessous.

skip-cert-verify : facultatif

skip-cert-verify=true

Ce qui active la vérification, c'est sni=. Avec sni= renseigné et skip-cert-verify absent ou à false, la chaîne et le nom d'hôte du certificat que présente le site de façade sont vérifiés par rapport à ce nom, et un échec fait échouer la connexion. Sans sni=, le certificat n'est pas vérifié et un avertissement est consigné une fois par politique, à la première utilisation, car le seul nom disponible est celui du relais, qui n'est pas celui du site de façade. skip-cert-verify=true ignore la vérification dans les deux cas.

fingerprint : facultatif

fingerprint=chrome

Empreinte de client TLS à imiter. Les valeurs prises en charge comprennent chrome, firefox, safari, ios, edge, 360, qq, android, random, ainsi que les autres noms cités sous fingerprint. Utiliser une empreinte de navigateur courante aide à éviter la détection. Notez qu'android et random ne sont pas distincts ici — ils sont traités comme chrome. none et toute valeur que Chute ne reconnaît pas font refuser la connexion, car la pile TLS du système ne sait pas mener cette poignée de main.

Paramètres des proxys avec MASQUE

MASQUE est un protocole de proxy fondé sur HTTP/3 qui tunnelise le trafic par-dessus QUIC. Une politique MASQUE exige type, host et port. Un token d'authentification est facultatif.

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

token=auth-token

Jeton d'authentification Bearer facultatif pour le serveur MASQUE. L'alias masque-token= est également accepté.

mode : facultatif

mode=connect-udp

Accepté par compatibilité, mais ne change pas le comportement de tunnelisation : les flux TCP utilisent toujours un tunnel CONNECT simple et les flux UDP toujours connect-udp. L'alias masque-mode= est également accepté.

mux : facultatif

mux=true

Active le multiplexage sur une connexion QUIC partagée.

sni / alpn / skip-cert-verify : facultatifs

Identiques à TLS. MASQUE fonctionnant sur QUIC, alpn=h3 est généralement utilisé.

Paramètres des proxys avec SSH

Consultez Proxy SSH pour la documentation complète.