n8n 爬蟲的穩定性基石：一篇精通錯誤處理( Error Handling )，打造永不中斷的數據採集流程

你是否曾滿心期待地執行一個準備抓取數百個頁面的 n8n 爬蟲工作流，然後去泡了杯咖啡，回來後卻發現流程早已被一個紅色的錯誤訊息無情地中斷？更糟的是，它可能只處理了前 20 個頁面，就因為其中一個網址失效或網路暫時抖動，而導致後續數百個任務全部停擺。

這，是所有大規模爬蟲任務都會遇到的夢魘——脆弱性 (Fragility)。一個沒有錯誤處理 (Error Handling) 機制的爬蟲，就像一輛沒有避震器和備胎的賽車，雖然在完美的賽道上能跑得飛快，但只要遇到一顆小石子，就可能立刻車毀人亡。

一個「能動」的爬蟲和一個「可靠」的爬蟲，天差地遠。而它們之間最大的區別，就在於後者擁有強固的錯誤處理機制。n8n 提供了視覺化且功能強大的工具，讓你能為你的爬蟲流程，建立起一套能夠預期失敗、隔離錯誤、自動重試、並記錄問題的完整防護網。

這篇文章將是你的 n8n 爬蟲穩定性終極指南。我們將帶你深入分析爬蟲最常見的三大類錯誤，並手把手教你如何活用 Continue on Fail 與 Retry on Fail 這兩大核心戰術，最終打造出一個能夠在面對零星失敗時，依然能完成大部分任務、永不輕易中斷的專業級數據採集流程。

零基礎帶你完成屬於自己的n8n自動化流程

內容目錄

為什麼你的爬蟲總是不堪一擊？認識爬蟲的三大類常見錯誤

在建構防護網之前，我們必須先了解我們要防禦的敵人有哪些。爬蟲流程的錯誤，大致可以分為三種類型：

網路與連線錯誤 (Network/Connection Errors):
- 原因： 這是最常見的「暫時性」錯誤。可能是你的 n8n 伺服器網路暫時不穩、DNS 解析失敗、或是你使用的 Proxy 代理伺服器突然失效。
- 特徵： 錯誤訊息通常包含 Timeout, ECONNRESET, ENOTFOUND 等關鍵字。這種錯誤的特點是，如果立刻重試一次，很有可能就會成功。
HTTP 狀態碼錯誤 (HTTP Status Code Errors):
- 原因： 目標伺服器明確地告訴你請求出了問題。
- 特徵：
  - 404 Not Found: 你要抓取的網址本身就不存在。
  - 403 Forbidden / 401 Unauthorized: 你的 IP、User-Agent 或 Cookie 驗證失敗，被反爬蟲機制擋下。
  - 429 Too Many Requests: 你的請求過於頻繁，觸發了速率限制。
  - 5xx Server Error: 對方伺服器內部發生了暫時性錯誤。
- 判斷： 404 和 403/401 通常是「永久性」錯誤（除非你更換策略，否則重試也沒用），而 429 和 5xx 則通常是「暫時性」的。
資料解析錯誤 (Parsing Errors):
- 原因： 你的 HTTP Request 成功抓回了 HTML，但在後續的 HTML Extract 節點中，因為目標網站改版，導致你設定的 CSS Selector 或 XPath 找不到對應的元素。
- 特徵： 這是一種「永久性」錯誤，除非你手動更新你的 Selector，否則它永遠都會失敗。

核心戰術 (一)：用 `Continue on Fail` 建立「Try/Catch」防護網

這是錯誤處理的基石。Continue on Fail 的功能，是讓你在某個節點失敗時，不中斷整個工作流，而是將錯誤資訊，導向一個專門的「錯誤處理路徑」。

為什麼這對爬蟲至關重要？ 在一個需要處理 500 個 URL 的迴圈中，如果沒有它，只要第 21 個 URL 是個 404 死連結，那麼後續的 479 個 URL 就全部不會被處理。但啟用了 Continue on Fail 後，n8n 會「捕捉」到第 21 個 URL 的失敗，將其記錄下來，然後繼續處理第 22 個 URL，確保任務的最大完成率。

設定方法： 在你的爬蟲迴圈中，為最可能失敗的節點（通常是 HTTP Request 和 HTML Extract）都進行以下設定：

點開節點，進入 Settings 分頁。
將 Continue on Fail 開關打開。
現在，你可以從該節點下方的紅色錯誤輸出點，拉出一條連接線，開始建立你的錯誤處理流程（例如，將失敗的 URL 和錯誤訊息寫入一個「失敗紀錄」的 Google Sheets）。

核心戰術 (二)：用 `Retry on Fail` 應對「暫時性」網路與伺服器問題

對於那些「重試一次可能就好了」的錯誤，Retry on Fail 是你的最佳武器。它能讓 n8n 自動化地進行重試，幫你處理掉大部分的暫時性問題。

判斷何時使用：

應該使用 Retry on Fail 的錯誤：
- 網路與連線錯誤 (Timeout, ECONNRESET)
- 429 Too Many Requests (可以設定等待 60 秒後重試)
- 5xx 系列的伺服器內部錯誤
不應該使用 Retry on Fail 的錯誤：
- 404 Not Found (頁面不存在，重試一萬次也不會出現)
- 403 Forbidden / 401 Unauthorized (你的偽裝被識破，重試只會讓你更快被封鎖)
- 資料解析錯誤 (Selector 失效，重試也沒用)

最佳組合： 最專業的做法，是將 Retry on Fail 與 Continue on Fail 同時啟用。

流程： n8n 會先根據你的設定，嘗試重試 2-3 次。如果經過所有重試後，該節點依然失敗，Continue on Fail 機制才會生效，將最終的失敗結果，送往你的錯誤處理路徑。

終極實戰架構：打造一個能「隔離錯誤」並「記錄失敗」的強固型爬蟲

目標： 每天定時爬取一個包含 100 個 URL 的列表，將成功抓取的資料存入 A 表，將失敗的 URL 與原因存入 B 表，並在全部完成後發送一個總結報告。
流程設計：
1. Schedule -> Set (準備 URL 列表) -> Split In Batches (Size: 1):
  - 建立一個逐一執行的迴圈。
2. HTTP Request 節點:
  - Settings: 啟用 Retry on Fail (2 次，間隔 30 秒) 和 Continue on Fail。
  - 錯誤路徑 (紅點): 連接到一個 Set 節點 (命名為 Format Error Log)，組合出錯誤訊息，然後再連接到 Google Sheets (命名為 Log Failed URLs)，將 url, error_message, timestamp 寫入。
  - 成功路徑 (綠點): 連接到 HTML Extract 節點。
3. HTML Extract 節點:
  - Settings: 只啟用 Continue on Fail (因為 Selector 錯誤重試無效)。
  - 錯誤路徑 (紅點): 同樣連接到 Format Error Log -> Log Failed URLs。
  - 成功路徑 (綠點): 連接到 Google Sheets (命名為 Save Successful Data)，寫入抓取到的資料。
4. NoOp 節點 (流程匯合):
  - 在迴圈的外部，新增一個 NoOp 節點 (命名為 Wait for All)。
  - 將 Log Failed URLs 和 Save Successful Data 這兩個迴圈內的「終點節點」，都連接到這個 NoOp 節點。這能確保在所有迴圈都執行完畢後，才繼續後續步驟。
5. Item Lists -> Slack (總結報告):
  - 在 NoOp 之後，用 Item Lists 等節點，分別計算成功和失敗的數量，並發送一則總結通知到 Slack：「今日爬蟲任務完成：成功 98 筆，失敗 2 筆。詳情請見 Google Sheets。」

爬蟲錯誤處理的最佳實踐與監控

日誌比數據更重要： 在開發初期，一個詳細的錯誤日誌（記錄了哪個 URL、在什麼時間、因為什麼原因失敗），比你抓取到的成功數據更有價值。
為失敗定義備用方案： 在錯誤處理路徑中，你除了記錄錯誤，還可以設計備用方案。例如，如果 Proxy A 失效，流程可以自動切換到 Proxy B 再重試一次。
設定超時 (Timeout): 在 HTTP Request 或 Browserless 節點的 Options 中，設定一個合理的超時時間（例如 30 秒）。這可以防止你的流程因為某個網站一直無回應，而被無限期地卡住。