Réponse rapide
Comparez Oxaa à Cloudflare Tunnel selon le workflow que le développeur doit accomplir, et non selon une grille de fonctionnalités copiée. La page exige sources officielles actuelles, tests à conditions égales, hypothèses datées de plan/région, migration et rollback.
Décision d’adéquation
Oxaa: Choisissez Oxaa lorsque le besoin concerne la boucle de débogage locale plutôt que la connectivité d’infrastructure.
Cloudflare Tunnel: Choisissez le concurrent si votre organisation standardise déjà DNS, connectivité privée, politiques d’accès ou ingress de production sur cette plateforme.
Méthode de comparaison reproductible
- Afficher date de recherche, versions, offres, régions et sources officielles.
- Décrire chaque produit de façon neutre avant le choix d’adéquation.
- Utiliser le même fixture local, réseau source et jeu de requêtes.
- Mesurer installation, edge-ready, première requête, localisation des données, Host/en-têtes, WebSocket/SSE, limites, récupération et nettoyage.
- Ne pas transformer un test en affirmation universelle de latence, fiabilité, sécurité ou confidentialité.
- Afficher les dimensions tarifaires actuelles avec date ; ne pas produire un score faux entre offres non équivalentes.
- Fournir migration, changements fournisseur/domaine, rollback, contact de correction et journal des modifications.
Traitement du trafic et des données de l’Inspector
L’edge public d’Oxaa termine le TLS public afin de résoudre le nom d’hôte exact, d’identifier la route authentifiée en cours et de transférer la requête. La session entre l’appareil enrôlé et Oxaa est chiffrée ; elle remet la requête uniquement au service local sélectionné.
Oxaa conserve des métadonnées limitées de compte, route, usage, sécurité, facturation, support et diagnostic nécessaires au fonctionnement et à la protection du service. La capture de body dans l’Inspector est une action de débogage distincte et explicite : la copie limitée du body de la requête ou de la réponse affichée dans l’Inspector local reste sur l’appareil du développeur et peut être masquée, supprimée immédiatement ou expirer automatiquement. Le trafic public doit néanmoins être traité par l’edge ; la formulation exacte est donc « copies de l’Inspector conservées localement », et non « Oxaa ne peut pas voir le trafic ».
Identité de la route et périmètre du service sélectionné
La connexion est initiée par l’appareil enrôlé. L’identité générée localement, la preuve de possession, les générations de route de courte durée et la correspondance exacte du nom d’hôte lient l’adresse à la route active. Une propriété inconnue, malformée, révoquée ou obsolète est rejetée en mode fail-closed.
Oxaa ne publie que la cible locale configurée. Les destinations de réseau privé nécessitent une autorisation explicite ; les classes publiques, metadata, link-local, multicast et autres destinations dangereuses restent bloquées par la politique.
Nettoyage et passage en production
Supprimez le callback externe, l’URL de prévisualisation ou l’association DNS ; faites tourner les identifiants de test ; supprimez les captures locales ; arrêtez la route ; puis révoquez l’appareil ou la session si nécessaire. Le trafic de production doit être confié à l’application déployée, à un ingress de production ou à une plateforme de livraison d’événements adaptée.
Ce qu’Oxaa est - et ce qu’il n’est pas
Oxaa fournit une connectivité de développement vers un service HTTP ou HTTPS local sélectionné tant que l’appareil enrôlé et la route authentifiée restent actifs. Ce n’est ni un hébergement applicatif, ni un VPN généraliste, ni un forward proxy, ni un déploiement permanent de production, ni un tunnel raw TCP/UDP, ni un passthrough TLS arbitraire, ni un substitut de CDN/WAF, ni une plateforme de livraison de webhooks de production.