你好，
我在通过网页界面使用 n8n Cloud 时遇到了反复出现的
歡迎來到 n8n 社群 @Raul_Martin_Acebes
首先，我建議將瀏覽器的「離線」訊息與工作流程執行分開，避免從編輯器直接執行長時間的網頁爬取工作。改為使用排程觸發保持它們運作中，然後在執行完成後檢查執行歷史。如果瀏覽器斷線但執行仍在繼續，通常是 UI/工作階段問題。
對於 HTTP Request 部分，我建議添加批次處理/分頁並使用較小的資料塊，而不是在單一請求中提取過多資料。n8n 的文檔提到使用批次處理來減少請求大小，並在呼叫之間增加暫停。同時在步驟之間存儲進度，這樣失敗的執行可以繼續而不必從零開始。
如果執行確實因記憶體/中斷錯誤而停止，我會擷取執行 ID、時間戳記、工作流程名稱和失敗的節點，然後比較是否每次都在相同的 HTTP 回應大小或端點上發生。
歡迎加入社群 @Raul_Martin_Acebes！你描述的設置經過深思熟慮，而且你顯然已經在隔離問題方面做得很好。
基於 @tamy.santos 所說的，我想針對 n8n Cloud 網頁爬蟲工作流程補充幾點：
1. n8n Cloud 有執行逾時限制
在 Starter 方案上，工作流程會在 1 小時後逾時。如果你的爬蟲工作流程在迴圈中命中多個端點，它們可能會無聲地達到此限制並停止。瀏覽器顯示「離線」通常只是 WebSocket 工作階段中斷，但真正的原因是執行逾時。檢查設定 > 執行中的執行歷史，看是否顯示「錯誤」且有逾時訊息。
2. 在 HTTP Request 呼叫之間新增 Wait 節點
針對爬蟲工作流程，在一批 HTTP 呼叫之間新增 Wait 節點（設定為 1-2 秒）。這可以防止記憶體尖峰，並減少單一重請求造成執行器停滯的機率：
Loop > HTTP Request > Wait (1s) > next iteration
3. 在 HTTP Request 節點上使用「Continue on fail」選項
啟用「Continue on fail」+ 勾選「Always Output Data」後，單一失敗的請求不會中止整個執行。你可以在之後篩選失敗的項目。
4. 將大型爬蟲工作拆分成較小的定時執行
與其讓一個工作流程爬取 1000 個項目，不如將其拆分成每次 100-200 個項目的批次，並使用每 15 分鐘執行一次的 Schedule Trigger。在 Cloud 上穩定性高得多。
你能分享大約單次工作流程執行中有多少個 HTTP 請求，以及你使用的是哪個方案嗎？這樣可以幫助我們縮小範圍。
非常感謝你的建議。
我已經用「Loop Over Items（逐項循環）+ Wait（等待）」節點實現了批處理，工作流現在肯定穩定多了。自從這樣做之後，它們不再自動取消發布，即使某些項目失敗，大多數執行也能正確完成。
不過，我還是偶爾會看到另一個似乎與工作流記憶體/負載無關的問題：
-
編輯器突然顯示「離線」，即使我沒有在執行任何工作流。
-
我有時會收到隨機的 502 錯誤，例如：
-
「無法擷取工作流」
-
「執行載入出現問題」
-
-
在此期間，我暫時無法存取工作流清單/使用者介面
-
即使沒有工作流在執行，這種情況也會發生
所以在這一點上，這感覺更像是雲端/使用者介面/工作階段/後端不穩定的問題，而不是工作流耗盡記憶體。
你知道這是什麼原因嗎？我在白天經常遇到這個問題，而且我的網際網路連線很好。
@Raul_Martin_Acebes
看起來更像是瀏覽器、n8n 前端、後端和代理/雲端之間的暫時故障,或是雲端環境本身的某種不穩定性。我會嘗試捕捉問題發生的確切時間、瀏覽器控制台/網路錯誤,並驗證這是否也發生在另一個瀏覽器或無痕視窗中。如果仍然出現錯誤,我會將這些資訊發送給支援團隊,因為他們能夠檢查他們這邊與 502 錯誤相關的後端/代理日誌。
我如何聯絡支援？我一直在試著解決這個錯誤，但我無法解決。
這裡發生了兩件不同的事情，值得將它們分開討論，因為其中一個可能根本不是真正的問題。
編輯器中的「離線」橫幅只是你的瀏覽器失去了與 n8n Cloud 的即時連線——那個將執行進度串流到使用者介面的 WebSocket。它不會停止執行。排程執行是在伺服器端進行的，無論你的分頁是否連線，所以你可以基本上忽略許多「它離線了」的雜音。真正重要的部分是記憶體／中斷執行的錯誤。
這聞起來像是觸及了記憶體上限，而在 Starter 方案中這個上限相當低。網路爬蟲是典型的觸發因素：HTTP Request 拉取整個 HTML 頁面或大型 JSON 回應會將其全部保留在記憶體中，如果這經過幾個下游節點——或幾個排程執行重疊——你就會超出上限，執行會被中止。這也解釋了為什麼一次手動執行一個反而有效：沒有重疊，低峰值記憶體。
我建議依序嘗試以下方法：
- 在每個 HTTP Request 之後，放置一個 Set/Edit Fields（或小型 Code 節點），只保留你實際需要的欄位並丟棄原始回應。將整個頁面內容拖過整個工作流通常是吃掉記憶體的原因。
- 分批處理——Loop Over Items／Split in Batches——而不是一次拉取並保留所有內容。保持峰值記憶體恆定。
- 確保兩個排程執行無法重疊。錯開時間有幫助，但如果執行所花時間超過到下一個觸發的間隔，它們就會堆疊。擴大間隔。
如果你做了所有這些仍然碰到問題，那就真的是方案限制了——Pro 提供更多 RAM 空間。但我會先壓縮承載量；網路爬蟲流程一旦停止攜帶原始回應，通常會大幅縮小。