Oxaa
Se connecterTéléchargement
  1. Votre localhost en ligne. Sans ouvrir votre réseau.
  2. Documentation
  3. Centre de dépannage et erreurs
  4. Limites, 429 et troncature de capture

Endpoints publics sécurisés pour le développement local

Limites, 429 et troncature de capture

Limites, 429 et troncature de capture : workflow pratique, comportement produit, limites, preuves et prochaine étape précise avec Oxaa.

Réponse rapide

Partez du symptôme visible et de l’identifiant d’erreur stable. Testez d’abord la couche la plus probable, utilisez des commandes sûres avec sortie attendue, appliquez une modification à la fois, puis confirmez la récupération par une route edge-ready et une vraie requête externe.

Parcours de diagnostic

  1. Relever l’identifiant d’erreur exact, la version de l’agent, l’OS, l’état de route et l’heure.
  2. Vérifier indépendamment le service local sur loopback.
  3. Exécuter oxaa routes list et oxaa diagnose --network.
  4. Comparer la sortie réelle à l’état attendu documenté.
  5. Appliquer la correction sûre la plus limitée.
  6. Envoyer une nouvelle requête externe et confirmer la réponse locale.
  7. Escalader avec des diagnostics relus et masqués si la récupération échoue.

Détails techniques

  • Symptôme ou identifiant d’erreur stable
  • Causes probables classées par probabilité
  • Commande de diagnostic sûre et sortie attendue
  • Correction et sécurité de la nouvelle tentative
  • Vérification par edge-ready et requête externe
  • Dossier d’escalade sans données sensibles

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.

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 ».

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.