Passer au contenu principal
Ces réponses couvrent les erreurs que vous pouvez rencontrer sur une application déployée. Pour un dépannage plus large, consultez Dépannage des déploiements.
Une erreur 403 sur une application déployée provient généralement de l’une de ces causes :
  • En-têtes de requête trop volumineux—un trop grand nombre de cookies peut rendre les en-têtes suffisamment grands pour être rejetés à la périphérie. Effacez les cookies de votre navigateur pour le domaine et testez à nouveau.
  • Authentification manquante—la requête n’inclut pas le jeton de connexion ou la session requis.
  • Une restriction d’accès—votre application peut être configurée pour bloquer certains trafics. Consultez les déploiements privés et les jetons d’accès externes.
Pour un diagnostic détaillé, collez vos journaux de déploiement dans un nouveau chat Agent.
Le processus de votre application n’écoute pas sur le port attendu par Replit. Replit transmet le port correct via la variable d’environnement PORT, donc liez-vous à elle plutôt qu’à une valeur codée en dur :
const PORT = process.env.PORT || 3000;

port = int(os.environ.get("PORT", 3000))
Votre application peut également s’être plantée avant la liaison—vérifiez vos journaux de déploiement pour les erreurs de démarrage. Avec les déploiements Autoscale, la première requête après une période de calme peut prendre quelques secondes (un démarrage à froid), ce qui est normal.
Une erreur CORS signifie que votre frontend et votre backend sont sur des origines différentes et que le backend n’a pas été configuré pour le permettre. S’ils font partie de la même application, utilisez des URL relatives comme /api/endpoint pour éviter entièrement les problèmes CORS.Sinon, configurez votre backend pour autoriser l’origine de votre frontend. Pour Express, par exemple :
const cors = require("cors");
app.use(cors({ origin: "https://your-frontend.replit.app" }));
N’autorisez que les origines spécifiques dont vous avez besoin avant le déploiement. Consultez Dépannage des déploiements.
Les applications déployées échouent lorsque l’environnement de production diffère de votre configuration locale. Vérifiez trois choses :
  1. URL localhost codées en dur—remplacez localhost:3000 ou 127.0.0.1 par des chemins relatifs ou des URL basées sur l’environnement, puis redéployez.
  2. Secrets de production manquants—confirmez que chaque clé requise est définie dans vos secrets de déploiement. Consultez Secrets.
  3. Migrations non exécutées en production—exécutez les migrations en attente contre la base de données de production avant de déployer.
Si les erreurs persistent, contactez le support Replit avec votre message d’erreur et les étapes que vous avez essayées.
Une erreur 502 signifie généralement que le processus de votre application s’est planté ou a renvoyé une sortie que le serveur ne pouvait pas utiliser. Vérifiez vos journaux de déploiement pour les erreurs de plantage juste avant que les erreurs 502 n’apparaissent—les rejets de promesses non gérés et les exceptions non capturées peuvent faire planter un processus Node.js silencieusement.Ajoutez un gestionnaire pour mettre en évidence les plantages :
process.on("uncaughtException", (err) => console.error("Uncaught:", err));
Une fois que vous pouvez voir l’erreur sous-jacente dans vos journaux, collez-la dans un nouveau chat Agent pour obtenir de l’aide pour la corriger.
Confirmez d’abord si la requête est bloquée plutôt qu’échouant dans votre code. Ouvrez vos journaux de déploiement et recherchez des messages concernant des requêtes sortantes bloquées ou redirigées.Causes courantes et solutions :
  • URL autoréférencées—si votre backend appelle sa propre URL publique (telle que fetch("https://myapp.replit.app/api/")), utilisez un chemin relatif comme fetch("/api/") à la place.
  • Requêtes pendant la phase de construction—effectuez des appels sortants à l’exécution, pas pendant la construction.
  • Restrictions réseau—sur un réseau d’entreprise ou scolaire, les connexions sortantes peuvent être bloquées ; vérifiez auprès de votre administrateur réseau.
Si aucune de ces raisons ne s’applique et que les requêtes sont toujours bloquées, contactez le support Replit avec les lignes de journal pertinentes.
Le sous-domaine .replit.app est dérivé du nom de votre projet et n’est pas garanti de rester le même lorsque vous dépubliez et republicez, surtout si le projet a été renommé.La solution permanente est un domaine personnalisé, qui reste le même à travers les redéploiements. Pour essayer de restaurer l’ancien sous-domaine, assurez-vous que le nom de votre projet correspond à l’original (renommez-le si nécessaire) et republicez—Replit ne peut pas réattribuer manuellement un sous-domaine libéré. Consultez Géographie de publication.

​
Vous avez encore besoin d’aide ?

Si votre erreur n’est pas couverte ici, contactez le support Replit.