Réponse rapide
Domaines personnalisés présente la fonctionnalité comme un workflow visible et testable : actions possibles, états et limites, comportement en échec et preuves de chaque affirmation importante.
Détails techniques
Cette page couvre :
- Résultat précis de la fonctionnalité et transitions d’état visibles
- Prérequis, plateformes prises en charge et périmètre offre/région
- Comportement du protocole ou du contrôle avec limites publiées
- États d’échec, diagnostic et récupération
- Limites de sécurité et de traitement des données
- Preuves de test, nettoyage et prochaine action produit
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.
Dépannage
Commencez par vérifier le processus local, le port et le schéma. Contrôlez ensuite l’authentification et l’horloge, DNS, UDP/443, le fallback TCP/443, le proxy d’entreprise ou l’interception TLS, la propriété de la route et l’état edge-ready. Utilisez oxaa routes list, oxaa diagnose --network et des identifiants d’erreur stables ; relisez les diagnostics avant partage et retirez les secrets, bodies et chemins privés.
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.
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.