Hysteria 2 : analyse complète du protocole, différences avec Hysteria 1, configuration du serveur et du client

Introduction

Ces dernières années, les systèmes de blocage et d’inspection profonde des paquets (DPI) sont devenus plus précis, agressifs et rusés. Les VPN traditionnels basés sur TCP perdent souvent en vitesse et en fiabilité, notamment sur les réseaux mobiles ou congestionnés. Dans ce contexte, Hysteria 2 s’impose comme l’un des transports les plus pratiques pour un tunnel stable sur QUIC/UDP : démarrage rapide, haute tolérance aux pertes, masquage efficace et administration simplifiée. Cet article décortique l’architecture du protocole, ses différences majeures avec Hysteria 1, les bonnes pratiques pour configurer serveur et clients, ainsi que des check-lists, optimisations et cas concrets.

Voici ce que vous allez obtenir : un modèle mental clair d’Hysteria 2, une collection de configurations testées et d’étapes à suivre, des outils de diagnostic, des stratégies pour contourner le DPI, et des réponses aux questions épineuses. Notre objectif est que cet article devienne votre référence pratique sur Hysteria 2 « par des praticiens, pour des praticiens ».

Principes de base

Qu’est-ce qu’Hysteria 2 et pourquoi QUIC/UDP ?

Hysteria 2 est un tunnel haute performance basé sur QUIC/UDP avec authentification, chiffrement TLS 1.3 et obfuscation optionnelle. Contrairement aux VPN TCP, QUIC fonctionne en UDP et gère le contrôle de congestion ainsi que la fiabilité au niveau utilisateur. Concrètement, cela signifie un démarrage plus rapide, moins de blocages dus à la perte de paquets, une meilleure résilience dans les réseaux instables et l’absence de lenteur liée à la récupération des longues sessions TCP.

Dans quels cas Hysteria 2 excelle

• Réseaux à forte latence et pertes (mobiles, Wi‑Fi congestionnés).
• Contournement du DPI ciblant signatures TCP, empreintes TLS et comportements non standards.
• Scénarios à forte charge avec de nombreuses requêtes courtes : accélération du pipeline et overhead réduit.

Différences entre Hysteria 2 et Hysteria 1

• Modèle de transport : Hysteria 1 offrait des modes de masquage supplémentaires (ex. faketcp), alors qu’Hysteria 2 mise sur un QUIC/UDP pur et de qualité, limitant les artefacts détectables.
• Propreté du protocole : meilleure compatibilité avec le fonctionnement standard de QUIC et TLS 1.3, ce qui réduit les traces spécifiques détectables.
• Obfuscation : Hysteria 2 applique une obfuscation légère avant la négociation TLS (exemple : mode 'salamander') pour camoufler les signatures DPI avant chiffrement.
• Modèle d’authentification : simplifié, basé sur mots de passe/tokens, avec une meilleure ergonomie pour les scénarios multi-clients.
• Performances : ajustement pratique des paramètres de contrôle de congestion et des buffers ; heuristiques améliorées pour l’estimation initiale du débit.
• Masquage (masquerade) : configuration facilitée d’une réponse crédible aux scanners aléatoires, réduisant le risque de blocage sélectif de ports.

Approfondissement

Stack protocolaire d’Hysteria 2

• UDP comme transport de base : élimination presque complète des problèmes liés au head-of-line blocking, indépendance des machines d’état TCP des équipements réseaux.
• QUIC : assure chiffrement au niveau transport, contrôle de congestion indépendant, multiplexage de flux sans blocage global.
• TLS 1.3 au-dessus de QUIC : handshakes rapides, reprise de sessions, suites de chiffrement compactes, fuite limitée de métadonnées (en général visible uniquement le SNI sauf usage rare d’ECH).
• Obfuscation avant TLS : couche légère qui rend le trafic initial moins prévisible pour le DPI, diminuant les risques de détection par signature avant l’établissement du tunnel sécurisé.

Authentification et modèle d’accès

La pratique courante est un mot de passe ou token symétrique, unique ou multiple pour divers utilisateurs. Cela simplifie le déploiement et l’intégration de clients sur différentes plateformes (desktop, mobile). Le changement de mot de passe reste une opération légère, adaptée à une rotation régulière.

Algorithmes et paramètres de performance

• Évaluation initiale de la bande passante (montante/descendante) : vous renseignez une capacité estimée client ; le transport s’en sert comme guide pour la fenêtre et la cadence, limitant les effets de pompage.
• MTU et fragmentation : QUIC impose un MTU minimum de 1200 octets. Sur les réseaux difficiles, activer la fragmentation ou limiter la taille des datagrammes côté client (exemple : 1200) aide à éviter les pertes liées au PMTU blackhole.
• Keepalive : envois réguliers et minimalistes permettant de maintenir l’état NAT et d’éviter les coupures intempestives des sessions longues inactives.
• Multiplexage des flux : des dizaines de streams bidirectionnels fonctionnant en parallèle sans blocage mutuel améliorent les performances web et API.

Masquage en trafic ordinaire

Les ingrédients clés de crédibilité : port 443/UDP, ALPN 'h3' (lorsque supporté côté client), certificat valide et légitime, SNI cohérent. Lors d’accès aléatoires externes (scan, clients curieux), le serveur peut servir un contenu statique ou proxy un site légitime (masquerade), ne révélant pas le service tunnel.

DPI et blocages : tendances actuelles en 2026

• DPI hybride : combinaison de critères signatures et comportements : taille, fréquence et timings des paquets, empreintes TLS/QUIC persistantes.
• Limitation du débit UDP : certains fournisseurs limitent UDP, surtout sur ports courants. Tester des ports alternatifs et configurer la fragmentation contrôlée est crucial.
• Réputation IP individuelle : les adresses VPN partagées finissent souvent sur listes noires. Avoir une IP dédiée réduit la corrélation massive et le bruit des voisins.

Pratique 1 : Conception d’architecture et évaluation des risques

Étape 1. Définir les objectifs

• Contourner le DPI pour navigation web et requêtes API.
• Résilience aux pertes et haute latence (réseau mobile ou route lointain).
• Faible profil détectable : port crédible, TLS valide, comportement discret.

Étape 2. Choix de plateforme et hébergement

• Serveur : VPS léger avec support garanti UDP, 1–2 vCPU, 1–2 Go RAM suffisent au départ. Stockage 10–20 Go.
• Système : Linux LTS récent, kernel actualisé (améliorations réseau et timers).
• Stack réseau : privilégier nftables, systemd-networkd ou NetworkManager, chrony/ntpd pour synchronisation précise.

Étape 3. Domaine, certificat, port

• Domaine : nom neutre sans « vpn » ni indices évidents. Idéalement hébergeant un site légitime pour masquerade.
• Certificat : valide, public, RSA ou ECDSA. Renouvellement automatique crucial.
• Port : 443/UDP par défaut pour crédibilité ; port secondaire type 8443/UDP ou autre discret.

Étape 4. Secrets et rotation

• Mot de passe/token dans config serveur et client — unique, complexe, distinct des autres services.
• Rotation régulière : tous les 1 à 3 mois ou à la moindre fuite.
• Secrets séparés par groupe d’utilisateurs facilitant la révocation.

Check-list conception

• UDP ouvert sur firewall et panneau fournisseur.
• Heure serveur synchronisée sans décalages majeurs.
• Certificat valide et auto-renouvelable.
• Ports 443/UDP principal et de secours configurés.
• Mots de passe définis et plan de rotation en place.
• Contenu masquerade prêt (page statique ou proxy inverse).

Pratique 2 : Configuration serveur Hysteria 2 sous Linux

Pré-requis

• Binaire 'hysteria' compilé ou installé avec support Hysteria 2.
• Certificat valide et clé privée en PEM.
• Droits d’exécution pour un utilisateur dédié sans shell.

Exemple de config serveur YAML

Exemple illustratif. Les noms de champs peuvent varier selon versions—référez-vous à votre build. Valeurs entre guillemets à adapter selon vos secrets et chemins.

• listen: ':443'
• tls:
•   cert: '/etc/hysteria/cert.pem'
•   key: '/etc/hysteria/key.pem'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• masquerade:
•   type: 'file'
•   dir: '/var/www/masq'
• quic:
•   alpn: ['h3']
•   max_idle_timeout: '30s'
•   disable_path_mtu_discovery: false
• bandwidth:
•   up: '50 Mbps'
•   down: '200 Mbps'

Système et sécurité

• Créer utilisateur : `useradd --system --no-create-home --shell /usr/sbin/nologin hysteria`.
• Droits sur clés : `chown -R root:hysteria /etc/hysteria` et `chmod 640` sur clé.
• Ouvrir port UDP 443 (et port secours) via nftables ou iptables.
• SELinux/AppArmor : donner les permissions nécessaires au binaire et configs.

Service systemd minimal

• [Unit] Description='Hysteria 2 Server' After=network.target
• [Service] User=hysteria Group=hysteria AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE ExecStart='/usr/local/bin/hysteria' 'server' '-c' '/etc/hysteria/config.yaml' Restart=on-failure
• [Install] WantedBy=multi-user.target

Activer au démarrage : `systemctl enable --now hysteria.service`. Vérifier logs : `journalctl -u hysteria -f`.

Optimisation réseau (kernel)

• net.core.rmem_max=67108864; net.core.wmem_max=67108864
• net.ipv4.udp_mem='262144 524288 1048576'
• net.ipv4.udp_rmem_min=4096; net.ipv4.udp_wmem_min=4096
• net.ipv4.ip_local_port_range='10000 65000'
• net.core.default_qdisc=fq (pour kerneles modernes)

Appliquer via sysctl.d puis recharger. Surveiller limites système avec `ss -u -a`, `ethtool -S`, `nstat`.

Masquerade : réponse crédible

• Type 'file' : fichiers statiques dans '/var/www/masq' (simples pages placeholders).
• Type 'proxy' : proxy inverse vers site externe (éviter surcharge, but réalisme pas trafic).

Vérifications

• Port UDP : `nmap -sU -p 443 votre_IP` doit être ouvert.
• Paquets QUIC : `tcpdump -ni any udp port 443` vérifier échanges Initial, Handshake.
• Certificat : outil de test TLS 1.3 sur port QUIC ou navigateur HTTP/3 en masquerade.

Pratique 3 : Configuration clients (desktop)

Option A : client 'hysteria' natif

Exemple de config client YAML :

• server: 'votre_domaine:443'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• tls:
•   sni: 'votre_domaine'
•   insecure: false
• quic:
•   alpn: ['h3']
• bandwidth:
•   up: '20 Mbps'
•   down: '150 Mbps'
• socks5:
•   listen: '127.0.0.1:1080'
• http:
•   listen: '127.0.0.1:8080'

Lancer avec : `hysteria client -c client.yaml`. Dans le navigateur, configurez proxy SOCKS5 local 127.0.0.1:1080 ou HTTP 127.0.0.1:8080.

Option B : sing-box (client universel)

Exemple JSON illustrant un outbound 'hysteria2' et un inbound SOCKS local. Guillemets simples pour lecture (remplacez par doubles dans JSON réel) :

• {
•  'inbounds': [ {'type':'socks','listen':'127.0.0.1','listen_port':1080} ],
•  'outbounds': [
•   { 'type':'hysteria2', 'server':'votre_domaine', 'server_port':443, 'password':'S3cure-Long-Secret-Token', 'obfs':'salamander', 'obfs-password':'Another-Obfs-Secret', 'tls':{'enabled':true,'server_name':'votre_domaine','alpn':['h3']}, 'udp_fragment':{'enabled':true,'length':1200,'interval':0}, 'multiplex':{'enabled':true,'max_streams':32} }
•  ]
• }

Démarrez sing-box avec ce fichier et configurez vos applications sur proxy SOCKS local. Si problèmes MTU, réduisez 'udp_fragment.length' à 1200 voire 1180.

Option C : v2rayN / Clash Meta / Nekoray

• Importer manuellement un profil Hysteria 2 : serveur, port, mot de passe, obfs 'salamander' et son mot de passe, SNI, activer ALPN 'h3' si pris en charge.
• Configurer SOCKS/HTTP local pour apps, ou activer mode TUN client pour intercepter tout le trafic.

Tests de vitesse et de stabilité

• Latence : `ping` serveur (estimation rapide), puis latence réelle des applis.
• Pertes : `mtr` vers serveur sans proxy et via tunnel (indirect).
• Débit : téléchargements lourds, streaming 1080p/4K, téléchargements parallèles ; noter stabilité plus que pics rapides.

Pratique 4 : Clients mobiles et routeur

Android : v2rayNG et similaires

• Créer profil Hysteria 2 : adresse serveur, port 443, mot de passe, obfs 'salamander' et son mot de passe, SNI=nom de domaine, options QUIC/HTTP3 si disponibles.
• Mode : privilégier TUN/VPN pour capture système, ou config proxy manuel dans apps.
• MTU : si pages bloquent, activer fragmentation ou réduire taille datagrammes à 1200.

iOS : Shadowrocket, FoXray, etc.

• Importer config Hysteria 2 ou saisir manuellement. S’assurer de la validité du certificat serveur ; éviter insecure=true sauf nécessité extrême.
• Profils contournement : ajouter exclusions pour domaines internes et réseaux locaux.

OpenWrt/routeur : proxy transparent

• Installer sing-box, configurer outbound hysteria2 et inbound TUN.
• Router tout le trafic via TUN en excluant sous-réseaux locaux, NTP, mises à jour.
• Tester clients : stabilité YouTube 4K, chargements app de messagerie, jeux en ligne (s’assurer du bon mode UDP).

Pratique 5 : Stratégies anti-DPI et masquage

Stratégie de base

• Port 443/UDP, certificat public valide, SNI cohérent.
• ALPN 'h3' si client supporte, masquerade 'file' ou 'proxy'.
• Obfuscation 'salamander' avec mot de passe distinct du mot de passe d’authentification.

Renforcement

• Rotation des ports et mots de passe tous les 1 à 3 mois.
• Double point d’entrée : port principal 443 et port secours (ex. 8443/UDP) en config client.
• IPv6+IPv4 : redondance contre blocages ciblés.
• Limiter taille datagrammes (1200) pour réduire patterns de fragmentation sur le chemin.

Framework de réaction en cas de blocage

1. Événement : dégradation ou coupure UDP 443 uniquement.
2. Diagnostic : test UDP sur port secours ; vérifier logs serveur ; capture pcap en entrée.
3. Réponse : basculer clients sur port secours ; changer mots de passe ; si besoin modifier SNI et domaine.
4. Consolidation : mise à jour masquerade, tuning MTU, redistribution trafic IPv4/IPv6.

Pratique 6 : Performance et stabilité

Optimisation kernel et réseau

• Augmenter valeurs rmem/wmem et buffers UDP selon charge.
• Activer fq comme qdisc par défaut pour un lissage fluide des queues.
• Vérifier gouverneur CPU — mode 'performance' réduit jitter sur serveurs chargés.
• IRQ affinity et NUMA : assigner IRQ réseau à un cœur dédié sous forte charge.

Paramètres client

• bandwidth up/down — définir des valeurs réalistes, sans surestimer.
• udp_fragment length — 1200 sur réseaux difficiles, 1250–1350 là où sûr (testez).
• multiplex max_streams — 16–64 pour charges web, moins pour jeux ou temps réel.

Observabilité

• Logs serveur : niveau warning/info en production, debug temporaire pour investigations.
• Captures pcap ciblées : filtrer UDP et port; observer tailles et intervalles.
• Métriques système : latence, pertes, CPU, softirq, drops NIC drivers.

Pratique 7 : Exploitation, mises à jour et sécurité

Check-list opérationnelle

• Renouvellement automatique certificat opérationnel, notifications d’erreur activées.
• Rotation mots de passe; révocation accès si client compromis.
• Port secours et profils clients prêts et testés.
• Logs sans fuites de secrets et rotation de fichiers.

Mises à jour

• Planifier redémarrages progressifs en période creuse.
• Garder une version binaire de secours.
• Comparer évolutions de format config avec exemples testés.

Sécurité

• Minimaliser droits processus, utilisateur et groupe dédiés.
• Firewall par défaut 'deny', whitelist ports indispensables uniquement.
• Surveiller pics UDP inhabituels et scans.

Erreurs fréquentes et anti-patterns

• Certificat ou SNI erroné : échec handshake et retentatives suspectes.
• TCP 443 seul ouvert : oublier UDP empêche connexion client.
• Bandwidth trop élevé : vitesse instable, chutes sous charge.
• Masquerade absent : port avec réponse vide attire scanners.
• Même mot de passe pour nombreux clients : gestion et investigation plus complexes.
• MTU trop grand : blocages PMTU blackhole, surtout sur réseaux mobiles.
• Horloge serveur incorrecte : erreurs TLS et échecs incompréhensibles.

Outils et ressources

Administration et diagnostic

• tcpdump, Wireshark : captures ciblées pour vérifier Initial/Handshake QUIC et tailles datagrammes.
• nftables, iptables : règles pour ports UDP et limites basiques.
• journalctl, systemd : gestion et consultation des logs service.
• iperf3 (UDP) : mesure brute débit et pertes.
• mtr : trace et analyse pertes vers serveur.

Applications clientes

• hysteria (serveur et client), sing-box (client universel avec TUN), v2rayN, Nekoray, Clash Meta, clients mobiles Android et iOS.
• OpenWrt : sing-box comme service système avec TUN pour réseau complet.

Alternative pratique au déploiement manuel

Si vous cherchez une alternative rapide et efficace à l’installation autonome, considérez le service vpn.how : serveur VPN personnel avec IP dédiée (non partagée), réduisant significativement les risques d’être listé sur des blacklists. Support des protocoles WireGuard, OpenVPN, IKEv2, L2TP, SSTP – selon besoins et environnement réseau. Datacenters à Moscou, Saint-Pétersbourg, Amsterdam, Francfort, Londres, New York, San José, Chicago, Singapour, Sydney, Madrid, Helsinki, Stockholm, Varsovie, Copenhague, Stavanger. Paiement par cartes russes (populaires), SBP, USDT/BTC. Tarifs dès 490 ₽ par jour et 2490 ₽ par mois avec remises longues durées. Installation automatique en quelques minutes après paiement, sans logs. Pour contourner DPI, utile d’utiliser des protocoles robustes comme WireGuard sur ports non standards ou IKEv2 sur 4500/UDP.

Cas pratiques et résultats

Cas 1 : réseau mobile avec pertes de 2–5 %

• Conditions : RTT 120–180 ms, pertes 2–5 %, VPN TCP basique plafonne à 2–6 Mbps de façon intermittente.
• Hysteria 2 : ALPN 'h3', udp_fragment 1200, bandwidth up/down 10/80 Mbps.
• Résultat : 12–18 Mbps stables sur trois téléchargements parallèles, vidéo 1080p sans mise en mémoire tampon, rarissimes micro-coupures résolues.

Cas 2 : Wi‑Fi d’entreprise avec DPI agressif

• Conditions : filtrage averti des empreintes TLS atypiques, bloc UDP sur la majorité des ports, 443/UDP ouvert.
• Hysteria 2 : certificat valide, masquerade 'file' avec site simple, obfs 'salamander'.
• Résultat : tunnel stable, scanner voit un 443 « normal » avec site fictif ; débit moyen 30–40 Mbps aux heures de bureau.

Cas 3 : routeur domestique sous OpenWrt

• Conditions : fournisseur bride régulièrement UDP aux pics, IPv6 dispo.
• Solution : sing-box sur routeur, outbound hysteria2, inbound TUN pour réseau complet, port secours 8443.
• Résultat : vidéos 4K stables, jeux UDP plus prévisibles, latence et jitter moindres comparés au VPN TCP.

FAQ

1) Hysteria 2 est-il HTTP/3 ou « son » QUIC ?

Hysteria 2 utilise QUIC et TLS 1.3 ; côté client, il peut annoncer ALPN 'h3' pour crédibilité HTTP/3. Le tunnel est une logique propre, non un proxy HTTP/3 complet.

2) Le port 443/UDP est-il indispensable ?

Non, mais il augmente la crédibilité. Gardez un port de secours en cas de blocage sélectif du 443/UDP. Testez selon votre réseau.

3) Peut-on utiliser un certificat auto-signé ?

Techniquement oui, en activant insecure sur client. En pratique, c’est moins bien masqué et plus détectable. Un certificat public valide est recommandé.

4) Qu’en est-il de l’ECH et de la dissimulation du SNI ?

ECH reste peu répandu et difficile à intégrer à des tunnels arbitraires. Considérez le SNI comme visible ; choisissez un domaine neutre et un masquerade adapté.

5) Hysteria 2 convient-il pour les jeux ?

Ça dépend du jeu. Si le trafic est TCP, Hysteria 2 améliore pertes et jitter. Pour du UDP peer-to-peer pur, le proxy UDP côté client est utile, mais tous clients ne le supportent pas nativement.

6) Y a-t-il un fallback TCP ?

Hysteria 2 ne propose pas de mode TCP en natif. Mettez en place le fallback au niveau client avec un profil alternatif (WireGuard/IKEv2/OpenVPN) ou un autre transport. Ayez toujours un plan B.

7) Peut-on mettre le serveur derrière un proxy inverse ?

Le proxy UDP est plus complexe qu’en TCP. Certains proxy QUIC existent, mais la solution la plus simple et fiable reste d’écouter directement le port UDP serveur. Utilisez alors le masquage intégré.

8) Pourquoi la vitesse est-elle inférieure aux attentes ?

Souvent à cause de bandwidth surévalués, buffers système trop petits, problème PMTU, ou limitation UDP fournisseur. Réduisez MTU à 1200, augmentez rmem/wmem, testez port secondaire.

9) Le multi-utilisateur est-il supporté ?

Oui, par mot de passe commun ou secrets distincts. Pour la gestion, mieux vaut distribuer des mots de passe séparés par groupe/utilisateur avec suivi.

10) IPv6 est-il nécessaire ?

Recommandé. Le double stack améliore la résilience : si un stack est dégradé ou filtré, l’autre peut rester fonctionnel.

Conclusion

Hysteria 2 est un transport QUIC mature et pratique face à l’ère des blocages agressifs et des réseaux instables. Il démarre vite, tolère bien les pertes, se masque naturellement en trafic classique avec une bonne configuration TLS et ALPN, et donne à l’administrateur de solides leviers : obfs avant handshake, masquerade, indications de bande passante, contrôle MTU et multiplexage. Nous avons exploré son architecture, les différences avec Hysteria 1, la configuration serveur/clients, l’optimisation, les stratégies anti-DPI, les erreurs fréquentes et les résultats concrets. À vous la pratique : installez un setup minimal, suivez les check-lists de conception et exploitation, faites plusieurs pcap, ouvrez un port secondaire, organisez la rotation des secrets et testez quelques jours en conditions réelles. La connexion stable est un processus, et Hysteria 2 rend ce processus plus clair et maîtrisable.