在4月29日，我的母親從網頁觸發了工作流程，但該執行在n8n中並未出現，而且運行也不正常。不過，當我自己從網頁執行同一個工作流程時，它運行得沒有任何問題。
我想理解為什麼會發生這種情況：
為什麼執行可能不會被保存或顯示，
為什麼它對我有效但對另一個人無效，
以及這是否可能與權限、身份驗證、工作階段或工作流程的觸發方式有關。
如果有人經歷過類似的情況，我真的很感謝任何幫助。
這是自動化中的常見情況，「在我的機器上可以運作」變成了實際的故障排除問題。由於執行記錄根本沒有出現在 n8n 的歷史紀錄中，這表示問題發生在工作流程邏輯完全處理之前或網頁與 n8n webhook 的交接期間。
下面是可能原因的細項分解，按照失敗最可能發生的位置進行分類。
1. 為什麼執行可能不會被保存或顯示
如果執行記錄沒有出現在 n8n 的「執行」標籤中，通常表示以下三種情況之一：
o 請求從未到達 n8n： 觸發器（Webhook 節點）從未成功接收到 HTTP 請求。如果請求被防火牆、CORS 錯誤或網路問題阻止，n8n 就不會「看到」它，因此無法建立執行記錄。
o 「觸發」階段期間出錯： 如果錯誤發生在 Webhook 節點本身（例如預期的標頭不匹配或伺服器層級的身分驗證失敗），n8n 可能會以 401、403 或 404 錯誤拒絕該請求，甚至在工作流程引擎開始正式「執行」之前。
o n8n 組態設定： 在 n8n 中，有一個「保存成功的執行」設定。如果工作流程實際上成功了但有一個讓它看起來失敗的錯誤，而你將「保存成功的執行」設定關閉了，你就不會看到它。不過，既然你提到它「無法正常運作」，更有可能是失敗了。
2. 為什麼它在你身上有效，但對另一個人無效
這指向用戶端（瀏覽器/設備）或網路環境中的差異。
o CORS（跨源資源共享）問題： 這是最可能的原因。如果網頁託管在 domain-a.com，而你的 n8n 在 domain-b.com 上，瀏覽器會執行「預檢」檢查。如果你的瀏覽器有快取的權限或不同的安全配置，它可能會通過，而她的瀏覽器（可能具有更嚴格的隱私設定或不同的擴充程式）可能會阻止該請求。
o 承載資料/資料差異： 當你的母親觸發工作流程時，她輸入的資料與你完全相同嗎？如果網頁發送表單，而她輸入了特殊字元、留下空白欄位，或輸入了違反架構的值（例如期望數字的地方輸入了字串），工作流程可能會在第一個節點就崩潰。
o 身分驗證和工作階段：
o Cookie/Token： 如果網頁依賴工作階段 cookie 或 Bearer token 來授權觸發器，而她的工作階段已過期或她未正確登入，請求將被拒絕。
o IP 白名單： 如果你的 n8n 執行個體在防火牆後面，只允許特定 IP 位址，你的 IP 可能被允許，而她的（在不同的網路或 VPN 上）被阻止。
o 瀏覽器擴充程式/廣告攔截器： 許多廣告攔截器或隱私擴充程式（如 uBlock Origin 或 Brave Browser 的防護盾）會攔截「不尋常」的傳出請求。如果 webhook URL 在她的瀏覽器中看起來像追蹤指令碼，它將在離開她的電腦之前被終止。
3. 故障排除檢查清單摘要
若要找到確切原因，我建議按照以下順序進行調查：
非常詳細，@Rafael_Van_Meerbeek 我有95%的把握，如果你按照 @kjooleng 的建議做，就能解決你的問題。至於剩下的5%，你可以試試刪除觸發節點，然後重新開始一個新的。
當工作流程開啟時連線中斷閃爍通常是 websocket 穩定性問題。自託管 docker 的常見原因：nginx 未設定 websocket 升級，或代理逾時短於 keepalive 間隔。
檢查你的 nginx 設定是否有 proxy_http_version 1.1 以及正確設定 Upgrade 和 Connection 標頭。如果你有負載平衡器或反向代理且逾時較短，那幾乎總是問題所在。連線會中斷、重新連線、再中斷，每隔幾秒重複發生。
「連線已中斷」訊息閃爍出現和消失，是瀏覽器與 n8n 伺服器之間不穩定的即時通訊通道的典型症狀。
n8n 不只是「重新整理」頁面來顯示您的更新；它使用一項稱為 WebSocket（或有時是伺服器傳送的事件）的技術來維持「即時」管道。這讓伺服器能夠立即將更新推送到您的螢幕（例如當節點完成執行或新執行開始時）。
當您看到它每秒閃爍時，這表示「心跳」（表示「我還在這裡！」的訊號）被中斷了。
以下是這種情況發生最可能的原因：
1. 反向代理設定（最主要原因）
如果您在反向代理（例如 Nginx、Traefik、Apache 或 Cloudflare）後方執行 n8n，代理很可能就是罪魁禍首。
-
WebSocket 支援： WebSocket 需要特定的標頭（
Upgrade和Connection）才能運作。如果您的代理未設定為「允許」這些標頭，它會在連線試圖建立時立即終止連線。 -
逾時設定： 代理通常有「讀取逾時」或「閒置逾時」。如果代理認為連線已經太久沒有任何動作（即使只是等待工作），它就會關閉連線。然後瀏覽器會立即嘗試重新連線，造成該「閃爍」迴圈。
-
Cloudflare/WAF： 如果您使用 Cloudflare，其安全設定或「Rocket Loader」有時會干擾持久的 WebSocket 連線。
2. 伺服器資源耗盡
「生產執行」螢幕截圖顯示 -98.46% 下降，這是一個重要的線索。這表明系統正經歷大規模的不穩定。
-
CPU/RAM 尖峰： 如果執行 n8n 的伺服器達到 100% CPU 或 RAM 耗盡，n8n 程序會在數毫秒內變得「沒有反應」。在這些毫秒內，它無法回應瀏覽器的「心跳」訊號，導致「連線已中斷」錯誤。
-
資料庫瓶頸： 如果您的資料庫（PostgreSQL/SQLite）在寫入執行資料時掙扎，整個 n8n 程序可能會短暫掛起，中斷即時連線。
3. 網路不穩定
-
封包遺失： 如果您的本機網際網路連線或通往伺服器的網路路徑遺失了哪怕是小部分的資料封包，對中斷非常敏感的 WebSocket 將不斷斷開和重新連線。
-
VPN/防火牆： 如果您在公司 VPN 上，它可能會積極檢查流量，並終止它認為「可疑」或「閒置」的長期連線。
4. 「生產執行」下降的含義
您螢幕截圖中的大幅百分比下降通常表示以下兩種情況之一：
-
資料缺口： 由於連線不穩定，儀表板無法擷取最近的歷史記錄，使得看起來像是執行已大幅下降。
-
系統故障： 導致連線閃爍的基礎問題（例如高 CPU 或服務崩潰）實際上正在阻止工作流程成功執行，導致成功的生產執行真正下降。
建議的故障排除步驟：
-
檢查伺服器健康狀況： 執行
top或htop（在 Linux 上）以查看閃爍發生時 CPU 或記憶體是否尖峰。 -
檢查代理日誌： 如果使用 Nginx，請檢查
/var/log/nginx/error.log。尋找「upstream timed out」或「connection reset by peer」。 -
測試「直接」連線： 如果可能，嘗試透過其 IP 位址和連接埠（例如
http://your-ip:5678）存取 n8n，繞過網域/代理。如果閃爍停止，問題絕對是您的代理設定。 -
檢查瀏覽器主控台： 在您的瀏覽器中按下
F12，前往主控台標籤，並尋找類似WebSocket connection to 'wss://...' failed的錯誤。這將確認是否是連線錯誤。