rathole vs. frp vs. ngrok : Ce que montrent vraiment les benchmarks

CGNAT et l’épuisement des IPv4 ont rendu “ouvrir un port sur votre routeur” inenvisageable pour la plupart des connexions domestiques et de nombreuses déploiements cloud aussi. Si vous testez des webhooks, gérez un service en homelab, ou administrez des appareils IoT distants, vous avez besoin d’un intermédiaire pour le NAT traversal. Trois noms reviennent constamment dans cette discussion : ngrok, frp, et le nouvel entrant en Rust, rathole. Voici ce que chacun fait réellement, et — puisque beaucoup d’enthousiasme autour de rathole en ligne est copié-collé des mêmes sources — ce que les chiffres derrière ces affirmations disent réellement.

ngrok : pratique, centralisé, et toujours avec limite de bande passante

L’argument d’ngrok n’a pas changé : lancez une commande, obtenez une URL HTTPS publique pointant vers votre serveur local, sans besoin de serveur personnel. Cette commodité vient du routage de votre trafic via le réseau edge d’ngrok, qui est aussi là où résident ses limitations.

En 2026, le niveau gratuit d’ngrok limite à 1 Go de bande passante par mois avec un seul point de terminaison actif, et il réattribue un sous-domaine .ngrok-free.app aléatoire à chaque redémarrage — un vrai problème si vous pointez un webhook dessus. Le trafic HTML en gratuit affiche aussi une page d’avertissement intermédiaire (pouvant être ignorée via un en-tête API, mais pas pour des démos côté navigateur). Les sous-domaines personnalisés nécessitent un plan payant, à partir du niveau Personal (8$/mois, 5 Go, puis 0,10$/Go supplémentaire), jusqu’au Pro (20$/mois, 15 Go) et Enterprise (39$/mois), avec une tarification à l’usage à partir de 18$/mois pour la production.

La limitation structurelle principale concerne le support des protocoles : ngrok ne supporte toujours pas le tunneling UDP natif, à aucun niveau. Cela l’exclut pour les serveurs de jeux, VoIP, et protocoles IoT comme CoAP ou MQTT-over-UDP — vous êtes limité à HTTP, HTTPS, TCP, et TLS. Ce qui fait la force d’ngrok, c’est la gestion du tunnel : rejouer des requêtes, inspection du trafic, vérification de webhooks, authentification OAuth/SAML/OIDC, et une API soignée pour gérer le cycle de vie du tunnel — rien de tout cela n’est tenté par frp ou rathole.

frp : mature, en développement actif, et plus vaste que ses alternatives

frp (Fast Reverse Proxy), écrit en Go, est l’option auto-hébergée de longue date : vous lancez frps sur un VPS avec une IP publique et connectez frpc derrière le NAT. Il est important d’être précis sur l’état actuel de frp, car beaucoup d’arguments du type “frp est lourd et peu sécurisé” datent de plusieurs années.

frp est en développement très actif — la version v0.70.0 est sortie le 11 juillet 2026, et le projet compte environ 106 000+ étoiles GitHub avec environ 15 000 forks, une taille d’ordre de grandeur supérieure à toute alternative Rust dans ce domaine. Le chiffrement TLS est activé par défaut depuis la v0.50.0, et les configurations modernes utilisent TOML, YAML ou JSON (l’ancien format INI est déprécié). L’authentification supporte à la fois des tokens statiques et OIDC.

Concernant la sécurité “les clients peuvent ouvrir des ports arbitraires” : c’est vrai uniquement dans le sens où frp ne limite pas la liaison des ports par défaut. La configuration du serveur supporte une directive allowPorts qui liste les plages de ports autorisées, ainsi qu’une limite maxPortsPerClient — mais c’est une option, pas la configuration par défaut. Si vous déployez frp sans définir allowPorts, un client avec un token valide peut demander n’importe quel port sur le serveur. C’est un vrai piège opérationnel à signaler dans toute documentation frp, mais ce n’est pas une faille architecturale.

Le reproche de collecte de déchets (GC) est vrai d’un point de vue architecture — le GC de Go introduit des pauses non déterministes que les langages sans GC évitent par conception — mais il faut le peser contre le fait que frp a été déployé à des centaines de milliers d’instances en production avec cette architecture. La question des pauses GC dépend fortement de votre pattern de trafic, pas seulement du choix du langage.

rathole : vraiment rapide, mais essentiellement abandonné depuis 2023

C’est ici que la narration de “dethronement” doit être corrigée. rathole, initialement développé par l’utilisateur GitHub rapiz1 et maintenant maintenu sous l’organisation rathole-org, est un reverse proxy en Rust conçu comme une alternative plus légère à frp : uniquement transfert TCP/UDP, pas de serveur web intégré, pas de load balancer, pas de système de plugins.

L’état de maintenance est plus important que les benchmarks. La dernière version taguée de rathole, v0.5.0, date du 1er octobre 2023. À l’écriture de cet article (mi-2026), cela fait moins de trois ans sans nouvelle version, et c’est une préoccupation active : la communauté d’utilisateurs de rathole s’est demandée si une alternative mieux maintenue n’avait pas émergé depuis. Le dépôt affiche 13,9k étoiles et 791 forks — un projet réel et respecté, mais environ un dixième de la taille et de la communauté de frp, sans la cadence de releases de ce dernier. Ce n’est pas disqualifiant pour un projet hobby sur un Raspberry Pi, mais cela change le profil de risque par rapport à ce que la “norme moderne” laisse entendre, surtout pour une infrastructure de production.

Ce que rathole offre concrètement :

• Binary léger. Le guide officiel compile le binaire à environ 500 KiB pour des cibles embarquées — vraiment minuscule, un vrai avantage pour les routeurs à mémoire limitée.
• Tokens par service obligatoires. Chaque service côté client et serveur nécessite son propre token ; pas de “confiance par défaut” comme avec frp.
• Support du Noise Protocol, en alternative à TLS, évitant la gestion de certificats.
• Configuration à rechargement à chaud — on peut ajouter ou supprimer des services sans redémarrer.

Configuration

Le format de configuration réel de rathole (d’après la documentation officielle) est basé sur TOML, séparé entre fichiers client et serveur :

Serveur (server.toml, sur votre VPS public) :

[server]
bind_addr = "0.0.0.0:2333" # Port d’écoute de rathole pour le client

[server.services.my_nas_ssh]
token = "utilisez_un_secret_que_vous_connaissez"
bind_addr = "0.0.0.0:5202" # Port public exposant le service

Client (client.toml, derrière le NAT) :

[client]
remote_addr = "myserver.com:2333"

[client.services.my_nas_ssh]
token = "utilisez_un_secret_que_vous_connaissez" # Doit correspondre au serveur
local_addr = "127.0.0.1:22"

Lancez ./rathole server.toml sur le VPS et ./rathole client.toml sur la machine locale, et ssh myserver.com:5202 atteint le NAS. Le modèle de tokens par service est la vraie amélioration de sécurité par rapport à la configuration par défaut de frp.

Le benchmark cité par tous — et ses véritables limites

Les chiffres derrière “rathole écrase frp sous charge” sont réels, mais proviennent d’une seule source : le fichier docs/benchmark.md de rathole, daté du 28 décembre 2021, exécuté sur une seule machine (une machine Arch Linux avec un double Xeon E5-2620 et 16 Go RAM), comparant un commit de développement de rathole ancien avec frp v0.38.0 — une version environ 30 versions en retard par rapport à la v0.70.0 actuelle. C’est aussi un benchmark en boucle locale, ce que les docs de rathole eux-mêmes notent comme reflétant une performance CPU limitée plutôt que des conditions réseau réelles.

Avec ces précautions, voici le tableau de latence réel de ce benchmark, utilisant vegeta pour générer une charge HTTP contre les deux proxies :

QPS	latence rathole	latence frp
1	2.113 ms	2.55 ms
1000	1.723 ms	1.742 ms
2000	1.845 ms	1.749 ms
3000	2.064 ms	2.011 ms
4000	2.569 ms	7,907 ms

Jusqu’à 3 000 QPS, les deux sont pratiquement indiscernables. À 4 000 QPS, frp 0.38.0 s’est écroulé dans ce test précis, tandis que la latence de rathole a à peine bougé. C’est un résultat vraiment spectaculaire, et c’est à l’origine de presque toutes les affirmations “rathole est plus rapide” que vous verrez sur les blogs et forums. Ce que ces répétitions ne mentionnent pas, c’est que personne n’a semble-t-il relancé cette comparaison avec une version actuelle de frp, sur du matériel différent, ou dans des conditions réseau réelles depuis. Considérez le plafond de débit comme valable pour une version frp de 2021 en laboratoire, pas comme un verdict définitif sur le code actuel.

La comparaison mémoire du même benchmark est plus crédible : sous une attaque vegeta de 30 secondes à 1000 QPS, la consommation mémoire de frp augmente significativement plus que celle de rathole, cohérente avec l’utilisation d’un runtime avec GC qui tamponne les connexions, contre l’allocation en Rust basée sur la propriété. C’est l’argument qui tient le mieux pour rathole sur du matériel très limité — un routeur OpenWrt 128 Mo ou un VPS à 3$/mois sera bien plus susceptible de rencontrer un OOM avec frp qu’avec rathole.

Noise Protocol : ce qu’il remplace réellement, et qui l’utilise

TLS et le Noise Protocol Framework résolvent le même problème — chiffrer le tunnel entre client et serveur — mais Noise évite totalement le modèle d’autorité de certificats au profit de clés pré-partagées ou échangées. Le pattern Noise par défaut de rathole est Noise_NK_25519_ChaChaPoly_BLAKE2s.

Noise est un cadre crédible, pas une invention spécifique à rathole : la poignée de main de WireGuard est basée sur le pattern IKpsk2 de Noise, et WhatsApp utilise Noise pour son chiffrement transport client-serveur. Slack a aussi utilisé des implémentations basées sur Noise. Une correction importante : le protocole de messagerie de Signal (X3DH + Double Ratchet) est une conception différente, plus ancienne — malgré une certaine filiation conceptuelle, Signal n’utilise pas le Noise Protocol Framework, donc il ne faut pas le citer aux côtés de WireGuard et WhatsApp comme un utilisateur de Noise.

Où chaque outil trouve sa place

ngrok — vous voulez une URL publique en dix secondes, vous ne voulez pas gérer un VPS, et UDP n’est pas une nécessité. Son inspection des requêtes et ses outils de débogage webhook restent les plus avancés des trois, et c’est la vraie raison pour laquelle on paie.

frp — vous cherchez un outil auto-hébergé, en développement actif, avec une grande communauté, support HTTP/TCP/UDP, équilibrage de charge, et tableaux de bord, et vous êtes prêt à configurer explicitement allowPorts et à laisser TLS activé par défaut plutôt que de s’y fier uniquement.

rathole — vous utilisez du matériel réellement limité en mémoire (un routeur OpenWrt, un VPS 512 Mo) où la petite empreinte et les tokens par service sont un vrai avantage, et vous acceptez que le projet n’ait pas publié de nouvelle version depuis près de trois ans. C’est un compromis raisonnable pour un homelab ; c’est beaucoup plus risqué pour une infrastructure de production sans plan pour gérer une faille de sécurité.

---

Changelog

• Supprimé tout le contenu SEO, les affirmations non étayées sur la part de marché ou la disruption violente, et les artefacts de balises de code “Ini, TOML” qui s’étaient glissés dans le corps du texte.
• Corrigé la narration centrale : le brouillon initial présentait rathole comme en train de “dethroner” frp. En réalité, la dernière version taguée de rathole est la v0.5.0 du 1er octobre 2023 (~13.9k étoiles GitHub, 791 forks), alors que frp a publié la v0.70.0 le 11 juillet 2026 et compte environ 106k+ étoiles et 15k forks — frp est plus grand et beaucoup plus actif. (releases rathole, releases frp)
• Vérifié et actualisé le tableau de benchmarks QPS/latence (précédemment sans attribution) directement à partir du docs/benchmark.md de rathole, en ajoutant le contexte que c’est daté du 28 décembre 2021, utilisé frp v0.38.0 (environ 30 versions en retard), tourné sur une machine de laboratoire, et un test en boucle locale — pas un benchmark indépendant ou récent. (rathole benchmark.md)
• Corrigé la déclaration de sécurité de frp : frp supporte une liste blanche allowPorts en option et une limite maxPortsPerClient, et a activé TLS par défaut depuis la v0.50.0 — le brouillon initial laissait penser qu’aucun contrôle n’existait. (frp GitHub, frp config)
• Corrigé la taille du binaire, passant d’un vague “bien en dessous de 1 Mo” à la valeur précise de ~500 KiB issue de la documentation officielle de rathole.
• Corrigé la liste des adopteurs du Noise Protocol : enlevé Signal (qui utilise le protocole Signal basé sur X3DH et Double Ratchet, pas Noise) et confirmé que WireGuard (pattern IKpsk2), WhatsApp (transport client-serveur), et Slack sont de vrais adopteurs de Noise. (overview Noise Protocol Framework, Wikipedia: Noise Protocol Framework)
• Corrigé et actualisé les détails sur ngrok : limite gratuite à 1 Go/mois, 1 point de terminaison actif, sous-domaine aléatoire, support UDP absent à tous les niveaux, et tarification actuelle (Personal 8$/mois, Pro 20$/mois, Enterprise 39$/mois, paiement à l’usage à partir de 18$/mois). (ngrok limits, ngrok blog)
• Remplacé l’exemple de configuration TOML fictif par la syntaxe réelle et les noms de champs documentés dans le README du projet.
• Adouci la formulation sur la gestion de la mémoire : passant d’une affirmation absolue à une description des compromis architecturaux, en notant que le design avec GC de frp n’a pas empêché sa large adoption en production.
• Réécrit la conclusion pour refléter la constatation sur l’état de maintenance : rathole est recommandé pour du matériel hobby contraint, avec une mise en garde explicite sur son cycle de release obsolète, plutôt que comme la “norme moderne” universelle.