Du service local à une vraie requête externe
- Installez et vérifiez le paquet Oxaa signé et approuvé.
- Exécutez
oxaa loginet enrôlez l’appareil. - Démarrez le service local sélectionné et vérifiez son état.
- Exécutez
oxaa http <port>et attendez l’état edge-ready. - Envoyez une requête depuis un sandbox fournisseur, un navigateur distant, un téléphone ou un second réseau.
- Confirmez la requête et la réponse dans l’application locale et l’Inspector.
- Arrêtez la route et supprimez callbacks, captures et identifiants de test une fois terminé.
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 ».
Choisir le besoin à accomplir
- Recevoir et vérifier les webhooks dans le véritable handler local.
- Terminer les callbacks OAuth et tiers via une vraie URL HTTPS.
- Partager une branche ou un prototype sans le déployer.
- Ouvrir une application locale depuis un téléphone ou un autre réseau.
- Tester WebSocket et Server-Sent Events via un edge public.
- Centraliser routes, appareils et propriétaires quand le workflow devient partagé.
Plus qu’une URL jetable
Oxaa gère le TLS public, le routage par nom d’hôte exact et la route authentifiée active dans les limites prises en charge. La page relie ce workflow à l’inspection locale, au diagnostic réseau et aux routes reproductibles.
Utilisez des fixtures testés et une revue datée avec la version du produit. Les adjectifs ne remplacent pas une preuve.
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.
Alternatives honnêtes
Un utilitaire jetable peut suffire pour une URL unique à faible risque. Un connecteur d’infrastructure convient à l’accès réseau privé ou de production. Un gateway de webhooks convient aux retries, au fan-out et aux opérations de livraison. Un environnement de développement cloud convient à un workspace hébergé à distance. Oxaa vise un endpoint local sélectionné, l’inspection locale et un workflow reproductible.
Choisir selon le workflow, pas selon une allocation vague
Les cartes d’offre doivent afficher précisément endpoints actifs, appareils approuvés, domaines, transfert, capture, audit, concurrence, avertissements, remise à zéro et résiliation depuis une seule source de facturation. Aucun « illimité » non défini.
Disponibilité et éligibilité commerciale
La langue, le pays du compte, le pays de facturation, la région de service, l’éligibilité au paiement et la langue de support sont des valeurs distinctes. Affichez le résultat actuel avant inscription ou checkout et ne déduisez jamais la disponibilité commerciale de la seule langue de la page.
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.
Questions fréquentes
Oxaa déploie-t-il mon application ?
Non. L’application continue de s’exécuter sur l’appareil enrôlé. Oxaa transfère les requêtes uniquement vers le service local sélectionné tant que la route authentifiée est active.
Dois-je ouvrir un port entrant ?
En principe non. L’appareil enrôlé initie la session. Un réseau restrictif peut toutefois bloquer DNS, UDP/443, TCP/443 ou intercepter TLS.
Où résident les copies de body de l’Inspector ?
Lorsque la capture limitée est activée explicitement, la copie affichée dans l’Inspector local reste sur l’appareil du développeur. Oxaa traite toujours le trafic public et conserve des métadonnées opérationnelles limitées.
S’agit-il d’un hébergement de production ?
Non. Utilisez une application déployée, un ingress de production ou une plateforme de livraison d’événements pour le trafic de production.
Effectuer la prochaine étape réelle
Poursuivez avec Commencer gratuitement lorsque le produit, l’offre et le pays prennent réellement en charge cette action. Utilisez Voir le fonctionnement pour examiner auparavant le parcours technique, de confiance ou de support précis.
oxaa login
oxaa http 3000