電子郵件觸發器 (IMAP) 造成 WorkflowActivationError 並觸發錯誤觸發器，但手動執行正常運作

Sokol · 2026年08月04日19:51

嗨大家，

我遇到一個問題，當我嘗試開啟含有 Email Trigger (IMAP) 節點的工作流程時，它會立即自動停用，並拋出 WorkflowActivationError，該錯誤被工作流程的 Error Trigger 捕獲。

但是，手動執行運作完美無誤，沒有任何錯誤。

錯誤詳情（由 Error Trigger 捕獲）：

[
  {
    "trigger": {
      "error": {
        "message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
        "timestamp": 1785767782822,
        "name": "WorkflowActivationError",
        "context": {}
      },
      "mode": "trigger"
    },
    "workflow": {
      "id": "zTAdqKiYBPODh3yr",
      "name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
    }
  }
]

n8n · 2026年08月04日19:52

嘿 @Sokol，在等待回覆的同時，這些資源可能對你有幫助：

建議的資源

自動符合您的問題。

文件：

論壇：

@ctrlaltdylan、@Anshul_Namdev、@Gallo_AIA — 你們之前幫助解決過類似的問題，能看一下嗎？

由 n8n 社群機器人自動建議。這是一個試驗 — 請在此分享反饋。

Anshul_Namdev · 2026年08月04日19:54

Hi @Sokol
WorkflowActivationError 是 n8n 在觸發節點失敗時傳遞給 Error Trigger 的包裝器，觸發節點錯誤總是帶著 context: {} 且沒有原因到達，所以真正的 IMAP 故障永遠無法到達 UI，反而會進入實例日誌。手動執行會執行單次擷取並關閉，啟動則會保持連接開啟，這就是為什麼只有啟動會觸發。打開工作流並在之後立即讀取日誌：

docker logs -f <your-n8n-container> 2>&1 | grep -i imap

以「Email Read Imap:」開頭的行包含實際原因，通常是連接意外關閉、伺服器的驗證拒絕或信箱錯誤，這決定了修復方案。在 Cloud 上，這些日誌無法從您這邊存取，help@n8n.io 可以為工作流 zTAdqKiYBPODh3yr 提取它們。
錯誤承載中缺失的詳細資訊已在此追蹤：

github.com/n8n-io/n8n

Email Trigger (IMAP) node does not clear report the error: "Imap connection closed unexpectedly" in the UI

opened 09:34AM - 18 Sep 25 UTC

closed 09:18AM - 30 Jun 26 UTC

craftiqflow

team:nodes status:in-linear status:team-assigned

### Bug Description There are kind of "magical" Error -Trigger-Events from one …of my Workflows with IMAP Node. There is no Error Data from this node in the n8n UI -> "Executions" or "Error Trigger Node". My Error Trigger Node (V. 1.0) was triggered by the following: > [ { "trigger": { "error": { "message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated", "timestamp": 1758180732473, "name": "WorkflowActivationError", "context": { } }, "mode": "trigger" }, "workflow": { "id": "....", "name": "... (Email->incoming)" } } ] In the container logs is a Warning (see debug info). Try to force reconnect in the imap node was not activated. ### To Reproduce 1. Create a new workflow (A) with Email Trigger (IMAP) node (V 2.1) connected with IMAP Service Provider like ionos 2. Simple inbox setting (Credentials, Mailbox Name: inbox, Action: Mark as Read, Format: resolved, Property Prefiy Name: attachment_) + option: Fetch Only New Emails + standard settings like "On Error: Stop Workflow" 3. Create a new workflow (B) with Error-Trigger and use this for the "Set up error notifications" in A 4. Activate both workflows (A, B) and wait (e.g. over night), do nothing, there should also no Email coming in the inbox (no IMAP activities) 5. The "magical Error" comes without any details -> Error Node -> Table -> "context:{empty object}" 6. Check n8n Log Output -> see debug data ### Expected behavior Clear Info in context field. ### Debug Info Docker Compose log output: ... n8n-1 | Email Read Imap: Connected closed unexpectedly n8n-1 | The trigger node "Email Trigger (IMAP)" of workflow "... (Email->incoming)" failed with the error: "Imap connection closed unexpectedly". Will try to reactivate. n8n-1 | Try to activate workflow "... (Email->incoming)" (...) n8n-1 | Activation of workflow "... (Email->incoming)" (...) was successful! n8n-1 | Email Read Imap: Connected closed unexpectedly n8n-1 | The trigger node "Email Trigger (IMAP)" of workflow "... (Email->incoming)" failed with the error: "Imap connection closed unexpectedly". Will try to reactivate. n8n-1 | Try to activate workflow "... (Email->incoming)" (...) n8n-1 | Activation of workflow "... (Email->incoming)" (...) was successful! n8n-1 | Email Read Imap: Connected closed unexpectedly ... Seems to be every 3h. ### core - n8nVersion: 1.110.1 - platform: docker (self-hosted) - nodeJsVersion: 22.19.0 - database: sqlite - executionMode: regular - concurrency: -1 - license: enterprise (production) ### storage - success: all - error: all - progress: false - manual: true - binaryMode: memory ### pruning - enabled: true - maxAge: 336 hours - maxCount: 10000 executions ### Operating System Ubuntu 24.04.3 LTS ### n8n Version 1.110.1 ### Node.js Version 22.19.0 ### Database SQLite (default) ### Execution mode main (default) ### Hosting self hosted

n8n · 2026年08月04日20:00

我們已經查看過這個問題，看起來可能在最近的版本中已經修復了。請更新並查看您是否仍然遇到同樣的問題。

Sokol · 2026年08月05日07:47

這些是我看到的日誌。我已將 n8n 版本更新至 2.33.3
如何修復這些錯誤？

另外，今天收到新電郵時流程沒有啟動；我假設它被強制關閉了。

Sokol · 2026年08月05日08:08

我將 n8n 更新到 2.33.3 版本，但問題仍然存在。

Hammad_gaming · 2026年08月05日08:26

嗨，
仍在 2.33.3，升級前後的 ECONNRESET/EPIPE 模式相同，沒有改變。

我注意到一件事，它不限於一個郵箱，mail@、deleted@ 和 notification@ 在同一個 VPS 上都在同一時間、在同一個緊密循環系統中斷開連線。這讓我想知道這是否真的是網路層的問題，而不是 Yandex 或 n8n 針對每個帳戶所做的事情。像是 VPS 防火牆或 conntrack 表在 n8n 有機會重新連線之前殺死閒置連線。

我還沒有檢查 conntrack 超時，將運行
sysctl net.netfilter.nf-conntrack-tcp-timeout-established 並發佈該值。我也會查看這些節點上目前設定的 Force Reconnect 是什麼，因為我不確定它是否已配置。

Sokol · 2026年08月05日09:00

強制重新連接間隔 = 15 分鐘

Hammad_gaming · 2026年08月05日09:11

為什麼 15 分鐘的設定與我在日誌中看到的不符？
感謝你分享。有一項突出的地方：雖然強制重新連接設定為 15 分鐘，但根據你之前提供的日誌，ECONNRESET/EPIPE 問題是在緊密迴圈中連續發生，而不是大約每 15 分鐘發生一次。如果強制重新連接是驅動因素，你會預期故障大約間隔 15 分鐘，而不是突然出現尖峰。因此，這個選項很可能不是主要原因；連接在分配的 15 分鐘之前就被終止了。
值得驗證其他郵箱（mail@、notification@）的值是否相同，或其中一個設定不同或未設定。這樣會更容易判斷是否是針對各節點的設定，或是對所有節點都有相同的影響。
仍計劃檢查 conntrack 逾時，一旦取得該值就會發佈 — 那才是真正能告訴我們這是 VPS/防火牆問題還是 n8n 重新連接處理中的某個問題的部分。

Sokol · 2026年08月05日09:17

如果您需要任何其他數據或我發送的內容有誤，請告訴我。我會發送額外的信息，以便我們能夠找到解決方案。

Hammad_gaming · 2026年08月05日09:31

執行 docker logs n8n-n8n-worker-1 2>&1 | grep -i imap 並查看返回的結果。請提供給我結果。
另外，EXECUTIONS_MODE 設定為什麼（或者你是否使用了 N8N_DISABLE_PRODUCTION_MAIN_PROCESS）。
也請提供來自你的 docker ps/日誌截圖中其中一個故障時間窗口附近的工作程序日誌輸出，這樣時間戳就能實際對齊主進程故障。

Sokol · 2026年08月05日09:45

我提供的資料正確嗎？

Hammad_gaming · 2026年08月05日09:54

無論該 LOGIN 錯誤是否在不同郵箱中反覆出現，以及時間戳是否集中在一起，因為如果同一網域/IP 上的多個郵箱都在大約相同的時刻重試 LOGIN，這看起來像是 Yandex 的反濫用/速率限制因為從一個 VPS IP 重複登入嘗試而被觸發，而不是每個帳戶的問題。

我的建議：

那個 sc= 代碼是 Yandex 端的追蹤/支援識別碼，值得你直接將它帶到 Yandex 支援部門，因為如果這是速率限制，那不是純粹從 n8n 設定端可以修復的東西。

Hammad_gaming · 2026年08月05日10:10

這有幫助嗎？

Anshul_Namdev · 2026年08月05日10:35

@Sokol 失敗的呼叫是 LOGIN，而不是 socket。“LOGIN internal server error sc=…_imap-production-main-623” 是 Yandex 拒絕工作階段，而 ECONNRESET 和 EPIPE 配對是這些工作階段在之後立即被丟棄。沒有任何 n8n 設定變更可以改變這種情況，修復需要在郵箱端進行。
對於每個 deleted@、mail@ 和 notification@：

在 mail.yandex.com 登入該郵箱一次。根據郵箱，使用者協議會在首次網頁登入時被接受，而服務郵箱通常從未登入過。
在「設定 > 電子郵件用戶端」中，確認「來自 imap.yandex.com 伺服器的 IMAP」已開啟，且授權方法設定為應用程式密碼。
在 Yandex ID 中為該郵箱產生應用程式密碼，並在 n8n IMAP 認證中使用它，而不是帳號密碼。
Yandex 也會阻止其安全系統標記為可疑的郵箱，通常是那些沒有真實姓名或連結電話的郵箱，該阻止會在幾小時內自動解除，這符合在手動執行仍然有效時出現和消失的錯誤。
Troubleshooting email client issues | Yandex Mail

話題		回覆	觀看
There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated Questions imap-email , error-trigger	0	265	2025年10月02日
Email Trigger (IMAP) had to be deactivated Questions node , imap-email	5	391	2025年06月24日
After the workflow setting node Email_trigger_IMAP runs normally for a few days, an error as shown in the figure often occurs. Close the active and reopen it, and it will return to normal Questions	1	247	2023年05月22日
IMAP Email Node No Longer Triggering Workflow Questions imap-email	49	4316	2025年10月11日
Warning "Workflow is activated, but could not be started." Questions core	9	1231	2022年08月03日

電子郵件觸發器 (IMAP) 造成 WorkflowActivationError 並觸發錯誤觸發器，但手動執行正常運作

錯誤詳情（由 Error Trigger 捕獲）：

Related topics