Le 29 avril, ma mère a déclenché le workflow à partir de la page web, mais cette exécution n’apparaît pas dans n8n et elle n’a pas fonctionné correctement non plus. Cependant, quand j’exécute le même workflow à partir de la page web moi-même, il fonctionne sans aucun problème.
J’aimerais comprendre pourquoi cela peut se produire :
pourquoi une exécution peut ne pas être sauvegardée ou affichée,
pourquoi cela fonctionne pour moi mais pas pour une autre personne,
et si cela pourrait être lié aux permissions, à l’authentification, à la session, ou à la façon dont le workflow est déclenché.
Si quelqu’un a vécu une situation similaire, j’apprécierais vraiment toute aide.
C’est un scénario courant en automatisation où « ça marche sur ma machine » devient une réalité de dépannage. Puisque l’exécution n’apparaît pas du tout dans l’historique n8n, cela suggère que le problème se produit avant que la logique du flux de travail ne soit complètement traitée ou lors du transfert entre la page web et le webhook n8n.
Voici une ventilation des raisons possibles, catégorisées par l’endroit où la défaillance s’est probablement produite.
1. Pourquoi une exécution peut ne pas être enregistrée ou affichée
Si une exécution n’apparaît pas dans l’onglet « Exécutions » de n8n, cela signifie généralement l’une de ces trois choses :
o La requête n’a jamais atteint n8n : Le déclencheur (nœud Webhook) n’a jamais reçu avec succès la requête HTTP. Si la requête a été bloquée par un pare-feu, une erreur CORS ou un problème réseau, n8n ne l’a jamais « vue », donc il n’a pas pu créer un enregistrement d’exécution.
o Erreur pendant la phase « Déclencheur » : Si l’erreur se produit au sein du nœud Webhook lui-même (par exemple, une incompatibilité dans les en-têtes attendus ou un échec d’authentification au niveau du serveur), n8n peut rejeter la requête avec une erreur 401, 403 ou 404 avant même que le moteur de flux de travail ne démarre une « exécution » formelle.
o Paramètres de configuration n8n : Dans n8n, il existe un paramètre pour « Enregistrer les exécutions réussies ». Si le flux de travail a réussi mais avait un bogue qui l’a fait paraître comme s’il avait échoué, et que vous avez désactivé « Enregistrer les exécutions réussies », vous ne le verrez pas. Cependant, puisque vous avez mentionné qu’il « n’a pas fonctionné correctement », il s’agit plus probablement d’une défaillance.
2. Pourquoi ça marche pour vous mais pas pour une autre personne
Cela indique des différences dans le Côté client (le navigateur/l’appareil) ou l’Environnement réseau.
o Problèmes CORS (Cross-Origin Resource Sharing) : C’est le coupable le plus probable. Si la page web est hébergée sur domain-a.com et votre n8n sur domain-b.com, le navigateur effectue une vérification « preflight ». Si votre navigateur a une permission mise en cache ou une configuration de sécurité différente, il peut passer, tandis que son navigateur (peut-être avec des paramètres de confidentialité plus stricts ou des extensions différentes) bloque la requête.
o Différences de charge utile/données : Lorsque votre mère déclenche le flux de travail, entre-t-elle exactement les mêmes données que vous ? Si la page web envoie un formulaire et qu’elle entre un caractère spécial, laisse un champ vide ou entre une valeur qui viole un schéma (par exemple, une chaîne alors qu’un nombre est attendu), le flux de travail peut s’arrêter au premier nœud.
o Authentification et sessions :
o Cookies/Jetons : Si la page web s’appuie sur un cookie de session ou un jeton Bearer pour autoriser le déclencheur, et que sa session a expiré ou qu’elle n’est pas correctement connectée, la requête sera rejetée.
o Liste blanche des adresses IP : Si votre instance n8n est derrière un pare-feu qui n’autorise que certaines adresses IP, votre adresse IP pourrait être autorisée, tandis que la sienne (sur un réseau différent ou un VPN) est bloquée.
o Extensions de navigateur/Bloqueurs de publicités : De nombreux bloqueurs de publicités ou extensions de confidentialité (comme uBlock Origin ou les shields du navigateur Brave) interceptent les requêtes sortantes « inhabituelles ». Si l’URL du webhook ressemble à un script de suivi pour son navigateur, elle sera supprimée avant de quitter son ordinateur.
3. Liste de contrôle récapitulative pour le dépannage
Pour trouver la cause exacte, je vous recommande d’enquêter dans cet ordre :
Très complet, @Rafael_Van_Meerbeek je suis à 95% certain que si vous suivez les recommandations de @kjooleng vous résoudrez votre problème. Quant aux 5% restants, vous pourriez essayer de supprimer le nœud de déclenchement et recommencer avec un nouveau.
hey merci beaucoup, cela m’a beaucoup aidé, maintenant ça fonctionne à nouveau mais j’ai remarqué que quand j’ai le workflow ouvert, il bascule entre connexion perdue et normal à chaque seconde, comme dans les captures d’écran et les exécutions en prod. Peux-tu m’expliquer pourquoi cela se produit ?
la perte de connexion avec scintillement pendant que le flux de travail est ouvert est généralement un problème de stabilité websocket. les causes courantes sur docker auto-hébergé : nginx non configuré pour les mises à niveau websocket, ou un délai d’expiration de proxy plus court que l’intervalle keepalive.
vérifiez que votre config nginx a proxy_http_version 1.1 et les en-têtes Upgrade et Connection configurés correctement. si vous avez un équilibreur de charge ou un proxy inverse avec un délai d’expiration court, c’est presque toujours la cause. la connexion se ferme, se reconnecte, se ferme à nouveau à quelques secondes d’intervalle.
Le message « Connexion perdue » qui clignote est un symptôme classique d’un canal de communication en temps réel instable entre votre navigateur et le serveur n8n.
n8n ne se contente pas de « rafraîchir » la page pour vous montrer les mises à jour ; il utilise une technologie appelée WebSockets (ou parfois Server-Sent Events) pour maintenir un « tuyau » actif. Cela permet au serveur de vous envoyer les mises à jour immédiatement (par exemple, quand un nœud finit de s’exécuter ou qu’une nouvelle exécution commence).
Quand vous le voyez clignoter chaque seconde, cela signifie que le « battement de cœur » (le signal qui dit « je suis toujours là ! ») est interrompu.
Voici les raisons les plus probables pour lesquelles cela se produit :
1. Configuration du proxy inverse (La #1 cause)
Si vous exécutez n8n derrière un proxy inverse comme Nginx, Traefik, Apache ou Cloudflare, le proxy en est probablement responsable.
-
Support WebSocket : Les WebSockets nécessitent des en-têtes spécifiques (
UpgradeetConnection) pour fonctionner. Si votre proxy n’est pas configuré pour « autoriser » ces en-têtes, il fermera la connexion dès qu’elle tentera de s’établir. -
Paramètres de délai d’expiration : Les proxies ont souvent un « délai d’expiration de lecture » ou un « délai d’expiration d’inactivité ». Si le proxy pense que la connexion est restée silencieuse trop longtemps (même si elle attend juste une tâche), il la fermera. Le navigateur essaie alors immédiatement de se reconnecter, créant cette boucle de « clignotement ».
-
Cloudflare/WAF : Si vous utilisez Cloudflare, ses paramètres de sécurité ou « Rocket Loader » peuvent parfois interférer avec les connexions WebSocket persistantes.
2. Épuisement des ressources du serveur
La capture d’écran « Prod. executions » montrant une baisse de -98.46% est un indice significatif. Cela suggère que le système connaît une instabilité majeure.
-
Pics CPU/RAM : Si le serveur exécutant n8n atteint 100 % de CPU ou manque de RAM, le processus n8n devient « sans réponse » pendant des millisecondes. Pendant ces millisecondes, il ne répond pas au signal de « battement de cœur » du navigateur, ce qui provoque l’erreur « Connexion perdue ».
-
Goulots d’étranglement de base de données : Si votre base de données (PostgreSQL/SQLite) a du mal à écrire les données d’exécution, l’ensemble du processus n8n peut se bloquer momentanément, cassant la connexion active.
3. Instabilité du réseau
-
Perte de paquets : Si votre connexion Internet locale ou le chemin réseau vers votre serveur perd même un petit pourcentage de paquets de données, le WebSocket—qui est très sensible aux interruptions—se déconnectera et se reconnectera constamment.
-
VPN/Pare-feu : Si vous êtes sur un VPN d’entreprise, il inspecte peut-être agressivement le trafic et interrompt les connexions longue durée qu’il perçoit comme « suspectes » ou « inactives ».
4. Ce que signifie la baisse « Prod. executions »
La baisse massive du pourcentage dans votre capture d’écran signifie généralement l’une de deux choses :
-
Lacune de données : Parce que la connexion est instable, le tableau de bord ne parvient pas à récupérer l’historique récent, ce qui fait sembler que les exécutions ont chuté.
-
Défaillance du système : Le problème sous-jacent causant le clignotement de la connexion (comme un CPU élevé ou un service qui plante) empêche réellement les workflows de s’exécuter correctement, ce qui entraîne une baisse réelle des exécutions de production réussies.
Étapes de dépannage recommandées :
-
Vérifier l’état du serveur : Exécutez
topouhtop(sur Linux) pour voir si le CPU ou la mémoire augmente quand le clignotement se produit. -
Vérifier les journaux du proxy : Si vous utilisez Nginx, vérifiez
/var/log/nginx/error.log. Recherchez « upstream timed out » ou « connection reset by peer ». -
Tester la connexion « directe » : Si possible, essayez d’accéder à n8n via son adresse IP et son port (par exemple,
http://your-ip:5678) en contournant le domaine/proxy. Si le clignotement s’arrête, le problème vient définitivement de votre configuration de proxy. -
Inspecter la console du navigateur : Appuyez sur
F12dans votre navigateur, allez à l’onglet Console, et recherchez des erreurs commeWebSocket connection to 'wss://...' failed. Cela confirmeront s’il s’agit d’une erreur de connexion.