Couverture par site réel, splice Vision et double transport — comprenez ce que chaque mécanisme apporte à votre connexion et où se situent les compromis.
TLS 1.3 / QUIC01 — 03
umbra
Votre appareil
Internet ouvert
Transport privé
Sans authentification → site réel
Votre trafic emprunte le chemin authentifié ; les autres requêtes rejoignent le site réel.
01
Se dissimuler derrière une destination réelle
L'authentification REALITY est intégrée dans le session_id TLS — invisible pour tout observateur. Les sondes non authentifiées voient une vraie négociation TLS avec le certificat réel de votre destination configurée. Pas de domaine à enregistrer, pas de certificat d'AC à gérer.
02
Éliminer les couches de chiffrement redondantes
Le vrai splice Vision fait passer les enregistrements TLS internes octet par octet après authentification — pas de double chiffrement, pas d'empreinte TLS-in-TLS. Le mux TCP partage une connexion entre flux avec un remplissage adaptatif pour briser la détection par motif de longueur.
03
Choisir le bon transport pour votre réseau
TCP avec segmentation style Geneva ou QUIC/HTTP-3 avec contrôle de congestion BBR — les deux derrière la même entrée SOCKS5. Choix explicite, pas de basculement automatique. QUIC nécessite un accès UDP ouvert et une destination de repli QUIC réelle.
Comment choisir parmi les principales solutions
Umbra et Xray sont des plateformes logicielles ; VLESS, VMess, Trojan et Shadowsocks sont des protocoles, tandis que REALITY et Vision sont des mécanismes. Le comportement dépend de l'implémentation et de la configuration. En résumé : Umbra mérite votre choix quand vous voulez une paire intégrée et auto-hébergée avec couverture par site réel, les deux voies de transport et SOCKS5 dans un seul binaire que vous administrez de bout en bout.
01
Umbra
Une implémentation Rust écrite from scratch : pile TLS 1.3 auto-développée avec contrôle d'empreinte Chrome au niveau octet, couverture par site réel style REALITY, vrai splice Vision, mux adaptatif, QUIC/HTTP-3 et négociation de clés post-quantique — le tout dans un seul binaire client et serveur.
Points forts
Pile TLS 1.3 auto-développée : chaque octet du ClientHello est construit pour correspondre exactement à Chrome — ordre des extensions, placement GREASE, groupes de partage de clés. Pas une bibliothèque avec des correctifs d'empreinte.
Le vrai splice Vision élimine le TLS-in-TLS après authentification : les enregistrements TLS internes passent octet par octet, supprimant l'empreinte de double chiffrement que laissent les tunnels proxy génériques.
TCP et QUIC derrière une seule entrée SOCKS5 : le mux adaptatif partage les connexions entre flux, tandis que QUIC/HTTP-3 offre un chemin UDP avec contrôle de congestion BBR pour les réseaux à pertes.
Négociation de clés hybride post-quantique (X25519MLKEM768) et liaison de certificat (ML-DSA-65) intégrées dans la négociation — pas un greffon, pas une réflexion après coup.
Résistance aux sondes intégrée dès la conception : les connexions non authentifiées reçoivent une réponse de la destination réelle, pas un rejet de proxy. Des chemins alignés temporellement empêchent la détection par analyse du temps de réponse.
Pile entièrement propriétaire de la cryptographie au transport, sans bibliothèque TLS tierce.
Limites
Alpha en ligne de commande uniquement ; protocole conçu pour un cas d'usage précis, non compatible avec les formats de nœuds hérités.
Le protocole peut changer entre versions : mettez à jour les deux extrémités ensemble.
02
Xray + VLESS + REALITY
L'alternative la plus proche : REALITY et Vision y sont aussi disponibles ; le choix porte sur l'emballage et le flux de travail, pas sur une technologie exclusive.
Points forts
Plateforme multiprotocole mature : routage riche, nombreux clients prêts à l'emploi et documentation communautaire étendue.
Limites
Vous assemblez et maintenez la pile vous-même : configuration centrale, couches de transport, règles de routage et clients assortis.
Des mécanismes communs ne rendent pas les deux interopérables.
03
VMess
Un protocole proxy AEAD à envisager si vos clients le prennent déjà en charge. TLS et WebSocket sont des choix de déploiement supplémentaires, pas des prérequis au chiffrement.
Points forts
Prise en charge client très large, sur toutes les plateformes, y compris les appareils anciens ou modestes.
Limites
Le protocole chiffre sans camoufler : la couverture dépend entièrement de la couche de transport que vous ajoutez.
Les anciens modes non AEAD sont déconseillés ; ciblez des clients qui implémentent AEAD.
04
Trojan
Un protocole proxy fondé sur TLS, pour ceux qui préfèrent un déploiement TLS classique ; le repli dépend de l'implémentation et de la configuration.
Points forts
Véritable poignée de main TLS, repli documenté, conception stable depuis des années.
Limites
Les installations courantes demandent de gérer un domaine et de renouveler un certificat public de confiance.
L'UDP voyage dans TCP sous TLS : sa latence suit le chemin TCP.
05
Shadowsocks
Un proxy chiffré léger pour les déploiements simples ; l'imitation d'un navigateur et la couverture par un site réel ne font pas partie des protocoles de base AEAD ou 2022.
Points forts
Composants minimaux : des clés et un client assorti, sans domaine ni certificat.
Limites
Les protocoles de base chiffrent sans camoufler ; évaluez les plugins séparément si vous voulez une couverture.
Un plugin SIP003 limité à TCP ne doit pas être pris pour un camouflage UDP.
06
Hysteria 2
Une solution centrée sur QUIC avec sa propre conception du contrôle de congestion ; à envisager si UDP est accessible de façon fiable.
Points forts
Voie UDP en datagrammes non fiables conçue pour les réseaux à fortes pertes, avec un contrôle de congestion taillé pour les conditions difficiles.
Limites
UDP bloqué ou restreint supprime son principal atout, et sa conception ne garantit pas une vitesse supérieure sur votre réseau.
Le TCP reste porté par des flux QUIC : les pertes peuvent bloquer les flux comme dans tout transport fiable.