Ngrok vs. frp (Fast Reverse Proxy) : La bataille ultime entre tunnels gérés et souveraineté auto-hébergée

Exposer un serveur de développement local, un appareil IoT ou un environnement de staging en local à Internet public nécessitait autrefois des configurations de routeur fastidieuses. Il fallait naviguer à travers le NAT de niveau opérateur (CGNAT), demander des IP publiques statiques, et ouvrir manuellement des ports sur les pare-feu grand public.

L’ingénierie moderne a dépassé cette friction. Aujourd’hui, les outils de reverse tunneling créent des chemins entrants sécurisés via des connexions sortantes, contournant complètement les restrictions de pare-feu.

Lors du choix d’une architecture pour le reverse tunneling, deux philosophies dominent. D’un côté, ngrok, le service cloud entièrement géré, orienté développeur, qui privilégie la simplicité plug-and-play et des fonctionnalités d’edge instantanées. De l’autre, frp (Fast Reverse Proxy), la solution open-source auto-hébergée, avec plus de 107 000 étoiles sur GitHub.

Choisir entre eux ne se limite pas à un simple outil ; c’est une décision architecturale fondamentale concernant la souveraineté des données, l’efficacité des coûts et la surcharge opérationnelle. Ce guide décompose les différences clés, les profils de performance, les implémentations de sécurité et les stratégies de configuration de ngrok et frp pour vous aider à sélectionner la meilleure option pour votre infrastructure.

1. Philosophies architecturales : SaaS vs. Auto-hébergement

Comprendre la divergence structurelle entre ngrok et frp révèle comment chacun gère le routage du trafic et la gestion de l’infrastructure.

Le paradigme ngrok : Edge-as-a-Service géré

Ngrok fonctionne comme une plateforme SaaS commerciale. Lorsqu’on exécute l’agent ngrok sur une machine locale, il initie une connexion sortante chiffrée vers le réseau d’edge cloud distribué mondialement de ngrok.

[Application locale]
       │
       ▼ (Connexion sortante via l’agent ngrok)
[Réseaux Edge cloud de ngrok] ◄───── (Requête publique via Internet) ─── [Utilisateur externe]

Le trafic provenant d’Internet arrive sur les nœuds d’entrée de ngrok, passe à travers leurs pare-feu applicatifs (WAF) et couches de protection DDoS, puis est routé dans le tunnel établi vers votre machine locale. Vous ne gérez pas les serveurs, les certificats ou les tables de routage ; tout est géré via une API cloud gérée.

Le paradigme frp : Délégation de trafic auto-hébergée

Frp supprime l’infrastructure tierce. Il divise le processus de tunneling en deux binaires légers :

• frps (serveur frp) : hébergé par vous sur une machine accessible publiquement, généralement un VPS à faible coût comme DigitalOcean, Linode ou AWS Lightsail.
• frpc (client frp) : exécuté dans votre réseau privé local, à côté de l’application cible. [Application locale] │ ▼ (Connexion sortante via frpc) [Votre VPS cloud (frps)] ◄───── (Requête publique via Internet) ─── [Utilisateur externe]

Le client frpc se connecte en sortie à votre instance de serveur frps. Lorsqu’un client externe se connecte à un port ou domaine désigné sur le VPS, le serveur frps encapsule ce trafic et le pousse via la connexion active vers frpc, qui le mappe directement à votre port d’application local. Vous êtes le fournisseur d’infrastructure, l’opérateur réseau, et le seul dépositaire des données.

2. Analyse approfondie des fonctionnalités

La divergence architecturale entraîne des ensembles de fonctionnalités très différents. Ce tableau reflète l’état actuel, vérifié en juillet 2026.

Capacité / Fonctionnalité	ngrok (Cloud géré)	frp (Fast Reverse Proxy)
Modèle principal	SaaS commercial / Edge cloud géré	Open-source auto-hébergé (Go)
Popularité GitHub	Client propriétaire (agent fermé)	107 000+ étoiles, 15 100+ forks
Dernière version stable	N/A (service cloud déployé en continu)	v0.69.1 (juin 2026)
Support des protocoles	HTTP, TCP (tous niveaux) ; TLS (payant uniquement)	TCP, UDP, HTTP, HTTPS, STCP, XTCP (P2P)
Souveraineté des données	Transit tiers (réseau edge ngrok)	Absolue — vous contrôlez 100 % du chemin du trafic
Bande passante	Selon le plan (1 Go–5 Go inclus, puis 0,10 $/Go)	Illimitée — limitée uniquement par votre uplink VPS
Gestion TLS/SSL	Certificats automatisés et gérés	Manuels ou automatisés via plugins ACME
Inspection du trafic	Console web en temps réel avec rejouer requêtes/réponses	Tableau de bord web basique ; métriques Prometheus disponibles
Contraintes tarifaires	Niveau gratuit limité à 1 Go/mois, 3 points d’accès	Pas de barrières tarifaires — coût VPS uniquement
Support UDP	Non supporté sur aucun niveau	UDP natif, plus options KCP et QUIC

3. La puissance de l’auto-hébergement : capacités de frp

Frp a acquis son statut d’outil auto-hébergé de niveau entreprise grâce à un ensemble de fonctionnalités étendu, activement maintenu, qui supprime les restrictions des alternatives commerciales.

Souveraineté totale des données

Lorsqu’on utilise un service proxy commercial, les payloads HTTP non chiffrés, les en-têtes d’autorisation et les webhooks transitent par des nœuds proxy externes. Pour les équipes soumises à des cadres de conformité comme HIPAA, GDPR ou SOC 2, cette exposition tierce introduit une considération sur la chaîne de traitement des données.

Avec frp, les données ne quittent jamais votre périmètre d’infrastructure — elles passent directement de l’utilisateur final, via votre instance cloud, à votre architecture locale.

Pas de barrières tarifaires

Frp n’a pas de concept de paywall. Si votre hébergeur dispose d’un port non mesuré de 1 Gbps, vos tunnels héritent de cette capacité. Vous pouvez faire fonctionner des centaines de proxies simultanés, lier des domaines apex personnalisés, et réserver des mappages de ports TCP/UDP sans atteindre de limites arbitraires — le plafond pratique étant votre VPS, pas le niveau de licence de frp.

Traversée NAT avancée : STCP et XTCP

Les reverse proxies traditionnels acheminent toutes les données via le serveur public, limitant la vitesse effective par la bande passante du serveur. frp propose deux modes de connexion supplémentaires pour contourner cela :

• STCP (TCP secret) : cache un proxy de l’internet ouvert. Un client doit présenter une secretKey correspondante via un bloc [[visitors]] sur son propre frpc pour accéder au service — pas de port public à scanner ou deviner.
• XTCP (P2P traversal) : utilise le trou de serrure UDP basé sur STUN pour tenter une connexion peer-to-peer directe entre le visiteur et le client local. frps est toujours nécessaire pour la poignée de main initiale et la signalisation, mais une fois établie, les données peuvent circuler directement entre les points, contournant le serveur pour le transfert réel. La documentation de frp indique que cela ne fonctionne pas avec tous les types NAT et recommande de revenir à STCP en cas d’échec.

Nouvelles fonctionnalités de frp jusqu’à mi-2026

frp a déployé plusieurs mises à jour significatives dans ses dernières versions mineures, qu’il est utile de connaître si vous y avez touché il y a plus d’un an :

• Politique de compatibilité formelle (à partir de v0.69.0) : chaque version mineure est désormais supportée jusqu’à la sortie de neuf versions mineures plus récentes — par exemple, v0.69.0 reste supportée jusqu’à v0.78.0 — offrant aux opérateurs une fenêtre de mise à jour plus claire.
• Protocole en wire v2 (v0.69.0+) : un nouveau protocole versionné frpc↔frps avec chiffrement AEAD négocié (xchacha20-poly1305 ou aes-256-gcm) sur le canal de contrôle, destiné à remplacer le protocole legacy. Activation via transport.wireProtocol = "v2", pas encore par défaut.
• Gestion dynamique des proxies (“Store”) (v0.68.0+) : frpc peut maintenant créer, mettre à jour et supprimer des proxies et visiteurs à l’exécution via son interface web ou API, en les sauvegardant sur disque sans redémarrage complet.
• Passerelle SSH Tunnel (v0.53.0+) : frps peut accepter directement des connexions ssh -R en clair, permettant de créer un proxy TCP sans installer frpc.
• VirtualNet (alpha, v0.62.0+) : une fonctionnalité basée sur une interface TUN qui étend frp du port forwarding au routage IP entre clients et visiteurs — encore en alpha, désactivée par défaut via un drapeau de fonctionnalité.

À noter : la refonte architecturale “v2” de frp (un core proxy à quatre/sept couches, à la Envoy) est un effort séparé, beaucoup plus vaste que le protocole en wire v2 ci-dessus. En mi-2026, le mainteneur a indiqué que sa complexité est plus grande que prévu et que le développement continue de manière opportuniste, sans calendrier précis — ne prévoyez donc pas une sortie imminente.

4. La proposition de valeur de ngrok

Bien que l’auto-hébergement offre des avantages clairs, ngrok reste un choix solide pour les équipes valorisant la simplicité zéro-ops et des fonctionnalités d’edge prêtes pour la production plutôt que la maîtrise complète de l’infrastructure.

Gestion d’infrastructure zéro

Configurer frp nécessite de provisionner un VPS, de configurer des règles de pare-feu, et de gérer un daemon systemd. Ngrok supprime tout cela — exposer une instance locale ne demande qu’une commande :

ngrok http 8080

Il n’y a pas de serveurs à provisionner ni de correctifs de sécurité à suivre de votre côté.

Inspection avancée du trafic et rejouer les requêtes

L’inspecteur web local de ngrok (servi à http://127.0.0.1:4040) vous permet de voir les requêtes HTTP entrantes jusqu’au header complet et au corps JSON, et sa fonction Replay vous permet de réexécuter un webhook capturé sans relancer l’événement en amont.

Protection d’identité et de l’edge, intégrée

Ngrok intègre l’authentification dans sa configuration d’edge via Traffic Policy — OIDC, SAML, et limitation de taux par requête sont configurables, pas des infrastructures séparées à déployer et maintenir.

Nouveautés 2026 : ngrok en tant que passerelle AI/MCP

C’est la nouveauté la plus significative depuis la dernière comparaison de tunneling, et elle est directement pertinente si vous évaluez aussi une infrastructure AI-agent. En 2026, ngrok a étendu sa plateforme d’edge en ce qu’il appelle une “Universal Gateway” avec deux composants spécifiques à l’IA :

• ngrok en tant que passerelle MCP : vous pouvez placer un Endpoint Agent ngrok devant un serveur MCP local et utiliser Traffic Policy pour authentifier, autoriser, et auditer chaque requête MCP avant qu’elle n’atteigne votre processus — par exemple, restreindre les connexions entrantes aux plages IP d’Anthropic ou d’OpenAI, et limiter le débit par clé API, sans toucher au code de votre serveur MCP.
• ngrok.ai (Passerelle IA) : une couche de routage séparée, compatible OpenAI (lancée le 1er juillet 2026 à app.ngrok.ai), qui se place devant vos appels de modèles plutôt que vos tunnels. Elle supporte la gestion de clés fournisseur, le basculement automatique entre fournisseurs, et le routage vers des modèles auto-hébergés (Ollama, vLLM) ou hébergés — tout en modifiant simplement un baseURL, sans autre changement de code. Depuis avril 2026, cette fonctionnalité est aussi accessible aux comptes Free-tier.

Aucune de ces fonctionnalités ne remplace le cas d’usage de frp — c’est un produit parallèle pour le trafic LLM plutôt que pour le tunneling TCP/UDP brut — mais cela explique pourquoi ngrok reste pertinent pour les équipes construisant des outils agentiques, et cela s’aligne directement avec le terrain de tunneling AI à zéro confiance couvert par ce blog avec zrok/OpenZiti.

Tarification actuelle de ngrok (vérifiée sur ngrok.com, juillet 2026)

Plan	Prix	Transfert de données	Requêtes HTTP/S	Points d’accès en ligne	Protocoles
Gratuit	0 $	1 Go inclus	20k/mois	3	HTTP, TCP (requiert vérification de carte)
Hobbyiste	8 $/mo, facturé annuellement (10 $/mo mensuel)	5 Go inclus, puis 0,10 $/Go	100k inclus, puis 1 $/100k	3	HTTP, TCP
Pay-as-you-go	20 $/mo + usage	5 Go inclus, puis 0,10 $/Go, illimité	100k inclus, puis 1 $/100k, illimité	Illimité	HTTP, TCP, TLS

UDP n’est pas disponible sur aucun niveau ngrok — cela reste une lacune architecturale, non tarifaire, et c’est la raison principale pour laquelle les développeurs se tournent vers d’autres solutions quand la charge implique des serveurs de jeux, VoIP ou protocoles IoT UDP comme CoAP ou DTLS. Si UDP est une exigence absolue et que l’auto-hébergement avec frp n’est pas une option, c’est une lacune réelle dans l’offre ngrok, à connaître — cela explique aussi la montée en traction d’alternatives gérées natives UDP (Localtonet, LocalXpose, Pinggy, Playit.gg) jusqu’en 2026, bien que leur évaluation dépasse le cadre de cette comparaison.

5. Guide étape par étape : Construire un réseau privé frp

Voici un guide complet pour déployer un réseau de tunneling frp sur une instance cloud Ubuntu standard, en utilisant la version stable actuelle (v0.69.1) et une syntaxe TOML corrigée et vérifiée.

Étape 1 : Configuration du nœud serveur (frps)

Connectez-vous à votre VPS via SSH, téléchargez le binaire de la dernière version, et extrayez-le :

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar -zxvf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

Copiez le binaire serveur dans /usr/local/bin et créez un répertoire de configuration :

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp

Créez /etc/frp/frps.toml. Notez que les clés vhostHTTPPort et vhostHTTPSPort utilisent une majuscule HTTP/HTTPS — vhostHttpPort et vhostHttpsPort (avec un “ttp” en minuscule) ne sont pas valides en TOML dans frp et échoueront silencieusement à la liaison :

# /etc/frp/frps.toml
bindPort = 7000

# Configuration du virtual host pour le routage web HTTP/HTTPS
vhostHTTPPort = 80
vhostHTTPSPort = 443

# Couche d’authentification pour éviter les connexions non autorisées
auth.method = "token"
auth.token = "LONG_CRYPTO_TOKEN_SUPER_SECURE"

# Activer le tableau de bord de surveillance intégré
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "CHOISISSEZ_UN_MOT_DE_PASSE_COMPLEXE"

Encapsulez l’exécution dans une unité systemd située dans /etc/systemd/system/frps.service :

[Unit]
Description=Démon Serveur frp
After=network.target

[Service]
Type=simple
User=nobody
Restart=on-failure
RestartSec=5s
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml

[Install]
WantedBy=multi-user.target

Rechargez systemd, activez et démarrez :

sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps

Étape 2 : Configuration du nœud client (frpc)

Sur votre machine locale, créez frpc.toml. La clé est localIP (avec un I majuscule), pas localIp — le parser de frp est sensible à la casse, et la variante en minuscule utilisée dans les versions antérieures échouera à la validation :

# frpc.toml
serverAddr = "VOTRE_IP_PUBLIQUE_VPS"
serverPort = 7000

auth.method = "token"
auth.token = "LONG_CRYPTO_TOKEN_SUPER_SECURE"

# Exemple 1 : Redirection du service SSH local
[[proxies]]
name = "tunnel-ssh-securisé"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6022

# Exemple 2 : Exposition d’une application web locale
[[proxies]]
name = "web-dev-local"
type = "http"
localIP = "127.0.0.1"
localPort = 8080
customDomains = ["dev.votredomaine.com"]

Lancez le client :

./frpc -c ./frpc.toml

Une fois connecté, les requêtes HTTP publiques arrivant sur dev.votredomaine.com (pointé via DNS vers votre IP VPS) seront routées directement vers votre port local 8080.

Vous pouvez vérifier qu’un fichier de configuration ne comporte pas d’erreurs de syntaxe avec frpc verify -c ./frpc.toml, et recharger un ensemble de proxies frpc en cours sans redémarrage avec frpc reload -c ./frpc.toml (nécessite que le bloc webServer soit configuré).

6. Matrice de décision pratique : Que choisir ?

                  La souveraineté totale des données est-elle requise ?
                                 │
                   ┌─────────────┴─────────────┐
                  OUI                          NON
                   │                           │
              [Utiliser frp]           La stack est-elle complexe, et
           (Auto-hébergé)          avez-vous besoin de UDP ou d’outils AI/MCP ?
                                   ┌────────────┴────────────┐
                                   ▼                         ▼
                              SIMPLE, HTTP/TCP,        COMPLEXE, ou
                              nécessite une passerelle AI/MCP ?
                                   │                         │
                              [Utiliser ngrok]          [Utiliser frp]
                             (Configuration rapide)    (Échelle/UDP/P2P)

Choisissez ngrok si : - Vous travaillez dans un environnement dynamique où la gestion de l’infrastructure détourne de l’ingénierie produit. - Vous avez besoin d’inspecter et de rejouer des webhooks complexes en temps réel. - Vous souhaitez une authentification intégrée OIDC/SAML sans déployer votre propre reverse proxy. - Vous construisez des outils agentiques et souhaitez une politique de trafic MCP ou un routage multi-fournisseurs LLM sans infrastructure séparée. - Votre charge ne nécessite pas UDP.

Choisissez frp si : - Vous exigez une souveraineté totale des données et souhaitez que les flux internes non chiffrés ne touchent jamais une infrastructure tierce. - Vous avez besoin de domaines apex personnalisés, de mappages de ports TCP/UDP dédiés, ou de charges à haut débit sans plan SaaS mesuré. - Vous tunnelisez des protocoles natifs UDP — serveurs de jeux, VoIP, IoT. - Vous êtes à l’aise avec la gestion d’un VPS et souhaitez un projet avec un cycle de release actif et transparent.

Verdict final

Le débat entre ngrok et frp réside dans le classique compromis infrastructure : commodité contre contrôle. Ngrok transforme le routage réseau complexe en une utilité abstraite — et en 2026, il a étendu cette abstraction au routage AI et à la fonction de passerelle MCP, ce qui est important si votre flux de travail est agentique. Frp reste la référence pour les ingénieurs infrastructure qui privilégient la propriété, le support UDP, et l’absence de plafond de licence, avec un projet qui — selon son historique récent de releases — continue d’être activement développé plutôt que de stagner.

---

Historique des modifications

Corrections (erreurs factuelles dans la version originale) : - Le nombre d’étoiles GitHub de frp a été arrondi à “108 000” dans l’original ; la vérification actuelle via GitHub indique 107 000+ étoiles (105k–108k dans les snapshots récents), avec 15 100+ forks. Mise à jour pour refléter cela. - Le guide de déploiement original mentionnait frp v0.70.0, qui n’existe pas en version publiée. Vérifié sur la page officielle des releases : la dernière version stable est v0.69.1 (1er juin 2026). Mise à jour des références de version et des commandes de téléchargement. - L’exemple frps.toml original utilisait vhostHttpPort / vhostHttpsPort. Ces clés sont invalides — les clés correctes sont vhostHTTPPort / vhostHTTPSPort (avec majuscule HTTP/HTTPS). La configuration initiale échouait silencieusement à la liaison. Correction. - Les exemples frpc.toml utilisaient localIp. La clé correcte est localIP (sensible à la casse). Correction dans tous les blocs. - Confirmation que ngrok n’a pas de support UDP sur aucun niveau — vérifié directement sur la page de tarification (ngrok.com/pricing), qui liste uniquement HTTP, TCP, et TLS.

Ajouts (informations nouvelles, sourcées) : - Remplacement de la description vague des tarifs ngrok par un tableau précis, actuel, directement extrait de ngrok.com/pricing (noms des plans, prix, données incluses, limites de requêtes, protocoles par niveau). - Ajout d’une section spécifique sur les capacités de l’AI Gateway et MCP Gateway de ngrok en 2026 (authentification MCP via Traffic Policy, relancement de ngrok.ai, et accès AI Gateway en avril 2026) — nouveau depuis la dernière comparaison de tunneling, et directement pertinent pour la couverture de ce blog sur l’infrastructure AI à zéro confiance. - Ajout d’une section “Nouveautés dans frp jusqu’à mi-2026” couvrant la politique de compatibilité formelle (introduite en v0.69.0), le protocole wire v2 avec chiffrement AEAD, la fonctionnalité Store (v0.68.0), le Gateway SSH Tunnel (v0.53.0), et VirtualNet (alpha, v0.62.0) — vérifié via la documentation officielle et notes de version. - Clarification que la refonte architecturale “v2” de frp est distincte de “wire protocol v2”, et mention de la déclaration du mainteneur en 2026 sur le calendrier indéfini de cette refonte. - Ajout des commandes de vérification (frpc verify, frpc reload) dans le guide de déploiement comme éléments pratiques, non présents dans l’original.

Changements structurels : - Suppression de tous les artefacts de métadonnées/formatage résiduels de la version originale. - Reformattage de tous les exemples shell et config en blocs de code correctement balisés, avec syntaxe indiquée.

---