Localhost désigne l’environnement qui émet la requête. Si Codex Cloud la lance depuis un environnement hébergé, http://localhost:3000 désigne cet environnement. La requête n’atteint pas le serveur qui écoute sur la boucle locale de votre ordinateur.
Un utilisateur de Reddit raconte que l’aperçu ouvrait à plusieurs reprises un port inutilisé par son projet. Relevez d’abord la destination réelle.
Commencez par identifier où s’exécute le navigateur ou la commande. Ensuite, utilisez un navigateur local, démarrez l’application dans l’environnement hébergé ou donnez un aperçu accessible. Le comparatif Tabbit et Codex explique le rôle des produits. La limite réseau dépend du lieu d’exécution.
À retenir
Un port désigne un service dans l’environnement auquel appartient l’adresse.
Un terminal hébergé et un navigateur local peuvent recevoir des réponses différentes pour la même URL.
Changer l’adresse d’écoute ne crée pas de route jusqu’à votre poste.
Vérifiez l’aperçu depuis l’environnement qui l’utilisera.
Même avec un statut 200, cherchez un marqueur propre à l’instance.
Situer la requête avant de modifier le serveur
| Origine de la requête | Signification de localhost | Premier contrôle |
|---|---|---|
| Navigateur sur votre poste | Pile réseau du poste | Port d’écoute du serveur |
| Navigateur ou commande sur VM hébergée | Boucle locale de la VM | Service présent dans cet environnement |
| Navigateur ou commande dans un conteneur | Espace réseau du conteneur en mode isolé | Emplacement réel du service |
| Navigateur ouvert sur un aperçu HTTPS | Le domaine de l’aperçu est la destination | Accès, version et résultat |
IANA classe 127.0.0.0/8 parmi les adresses de boucle locale. OpenAI décrit des environnements hébergés avec leurs propres règles d’accès à Internet et au réseau privé. L’environnement ne reprend pas l’accès réseau local du poste. Registre IANA, environnements OpenAI, administration de l’espace.
Identifiez le processus qui émet la requête. Si un outil distant pilote un navigateur autorisé sur votre poste, le navigateur envoie la requête localement. S’il lance un navigateur hébergé, la requête part de la VM. Voir le guide des navigateurs virtuels et celui des agents de navigateur.
La même adresse, deux réponses
L’essai local associait un Mac hôte à un système Alpine Linux dans Apple Virtualization. Le serveur Node de l’hôte écoutait sur 127.0.0.1:61616 et renvoyait host-loopback. La connexion à la même adresse a été refusée dans la VM. Après ouverture d’un service invité sur le même port, elle a reçu guest-loopback. L’hôte a continué à renvoyer son propre texte.
| Émetteur | Service dans cet environnement | Résultat |
|---|---|---|
| Mac hôte | Service hôte | host-loopback |
| Invité Alpine | Aucun | Connection refused |
| Invité Alpine | Service invité | guest-loopback |
| Mac après démarrage de l’invité | Service hôte | host-loopback |
C’était une vraie pile réseau séparée sur le même Mac. L’invité n’avait pas d’adaptateur réseau externe. L’essai montre l’isolation des boucles locales. Aucune tâche Codex Cloud ni aucun aperçu distant n’a été exécuté.
Vous pouvez répéter avec une VM ou un conteneur isolé. Choisissez un port libre, laissez Node tourner sur l’hôte et exécutez curl depuis un second terminal. Lancez ensuite la même requête dans l’invité.
node -e "require('node:http').createServer((_, res) => res.end('host-loopback\n')).listen(61616, '127.0.0.1')"
curl --noproxy '*' -fsS http://127.0.0.1:61616/probeDémarrez le même service côté invité avec la réponse guest-loopback, puis comparez. Le mode réseau hôte peut partager l’espace réseau dans certaines configurations de conteneurs. Utilisez un environnement isolé. Le nom host.docker.internal est un accès à l’hôte propre à Docker Desktop. Voir la documentation Docker.
Choisir où exécuter l’application et le navigateur
| Besoin | Premier choix | Contrôle |
|---|---|---|
| Examiner le serveur de votre poste | Navigateur autorisé sur le même poste | Port exact et version locale |
| Lancer des tests en environnement hébergé | Démarrer le serveur dans la tâche | Client et service dans le réseau prévu |
| Faire examiner une copie de test par le cloud | Aperçu HTTPS autorisé | Accès distant et version attendue |
| Joindre un service privé | Route privée approuvée si disponible | Identité, route, domaine et droits |
Pour vérifier une interface locale, laissez le navigateur et le serveur sur le même poste. Le guide du navigateur de bureau OpenAI décrit l’ouverture d’une application locale. Tabbit Browser peut aussi ouvrir une page de test sur ce poste et l’examiner si l’accès est autorisé. Voir le fonctionnement de Tabbit. Lors d’un contrôle distinct, Tabbit Tango a ouvert une URL de test dans Tabbit Browser et lu le marqueur local attendu.
Un aperçu distant doit pointer vers une copie de test avec un accès limité. Vérifiez séparément la connectivité, l’authentification et la politique réseau. Un 200 confirme qu’un service a répondu. Repérez la version ou l’état d’écran attendu.
Diagnostiquer dans l’environnement qui a vu l’erreur
« Connection refused » indique souvent que le client ne trouve aucun service sur cette adresse et ce port. Un délai, une interdiction de politique, un écran de connexion ou un certificat en erreur appellent un autre contrôle. Relevez l’émetteur, la destination sans secret, l’erreur et l’instance attendue. Le guide de débogage distingue la page de ses appels.
Un développeur qui utilisait des environnements Python locaux demandait quelles parties de Codex s’exécutaient sur son poste et dans le cloud. Pour diagnostiquer le navigateur, situez séparément la commande, le navigateur et le serveur.
Demandez l’URL sélectionnée et un marqueur sans donnée privée. Pour un simple contrôle d’affichage, commencez en lecture seule. Voir la liste de première tâche, le guide d’automatisation et le guide de sécurité. Choisissez le chemin le plus étroit et vérifiez que la bonne copie a répondu.
Questions fréquentes
Codex Cloud peut-il ouvrir le localhost de mon ordinateur ?
Une requête localhost partie du cloud reste dans l’environnement hébergé. Utilisez un navigateur autorisé sur votre poste, lancez l’application dans l’environnement qui doit la joindre ou fournissez un aperçu autorisé.
Quel localhost est utilisé quand Codex ouvre un navigateur ?
Celui du processus qui envoie la requête. Le navigateur de votre poste utilise sa boucle locale. Un navigateur ou une commande hébergée utilise celle de son environnement.
Écouter sur 0.0.0.0 permet-il l’accès depuis Codex Cloud ?
Cela ajoute des interfaces d’écoute dans le même environnement. Cette adresse ne crée ni itinéraire depuis le cloud ni autorisation.
host.docker.internal désigne-t-il mon ordinateur depuis Codex Cloud ?
C’est un nom prévu pour qu’un conteneur Docker Desktop joigne son hôte. Il ne fournit pas une route générale depuis un environnement Codex Cloud.
Quand choisir un aperçu distant ?
Lorsqu’un navigateur ou une commande hébergée doit examiner une copie de test déployée. Vérifiez l’accès et le marqueur de compilation depuis ce même environnement.
Comment savoir si le bon serveur a répondu ?
Comparez l’URL finale, la réponse et un identifiant de l’instance ou de la compilation. Un 200 peut provenir d’un autre service sur le même port.