大家好,
我還在學習 n8n,有一個小專案。
我想監控一個政府預約頁面(類似於 NBI 預約頁面),並且只在發生重要變化時收到通知,例如新增預約時段或狀態更新。
我不想過度爬取資料或違反任何網站規則。我只需要每隔幾分鐘檢查一次,如果有真正的變化就發送 Telegram 或電子郵件通知。
在 n8n 中最好的方法是什麼?HTTP Request + HTML Extract + 與之前結果比較?還是有更好的工作流程?
想聽聽其他人如何處理這類監控而不被限制請求次數。
謝謝!
大家好,
我還在學習 n8n,有一個小專案。
我想監控一個政府預約頁面(類似於 NBI 預約頁面),並且只在發生重要變化時收到通知,例如新增預約時段或狀態更新。
我不想過度爬取資料或違反任何網站規則。我只需要每隔幾分鐘檢查一次,如果有真正的變化就發送 Telegram 或電子郵件通知。
在 n8n 中最好的方法是什麼?HTTP Request + HTML Extract + 與之前結果比較?還是有更好的工作流程?
想聽聽其他人如何處理這類監控而不被限制請求次數。
謝謝!
嘿 @jozerizzel,在等待回應的同時,以下是一些可能對你有幫助的資源:
自動匹配到你的問題。
文件:
論壇:
@Yo_its_prakash、@mohamed3nan —你們之前在處理過類似問題,能幫忙看一下嗎?
由 n8n 社群機器人自動建議。這是試用版 —請在此分享你的意見回饋。
你可以試試這個方法
排程觸發器(每5分鐘)
→ HTTP 請求(取得頁面)
→ HTML 節點(提取目標部分)
→ 程式碼節點(雜湊/正規化提取的文字)
→ 移除重複項(與前次執行比較)
→ [IF 偵測到變更] → Telegram / Email 節點
嗨 @jozerizzel 歡迎!
將 HTTP 請求指向預約日曆本身呼叫的 JSON 端點,而不是呈現的 HTML,然後將回應中的 ETag 儲存在工作流程靜態資料中,並在下次輪詢時將其作為 If-None-Match 發送回去。未變更的輪詢會返回 304,沒有主體,因此開啟「包含回應標頭和狀態」以讀取 ETag,並選擇「永不出錯」,這樣 304 就不會導致執行失敗。
靜態資料只會在由其觸發器發佈的工作流程執行時保存,因此每次手動測試執行看起來都像是第一次輪詢。
感謝你詳細的說明,真的很感謝。
我沒想過可以用 JSON 端點搭配 ETag 和 If-None-Match。這聽起來比每次都比較整個 HTML 好多了。
也感謝你解釋靜態資料的行為。我之前很困惑,因為每次手動測試看起來都像首次執行,現在我知道原因了。
我會更新我的工作流程,並在發布的觸發器上測試它。希望這能減少不必要的請求,避免被限制。
再次感謝你的幫助!![]()
謝謝,這個工作流看起來更容易理解。
我認為在用 ETags 進行更高級的設置之前,我會先試試這個方法。我的主要目標只是在 NBI online 預約頁面有變化時收到通知,這樣我就不需要整天手動檢查了。
我會構建這個工作流並查看它的表現如何。如果網站變得太沉重而無法輪詢,那麼我會考慮之前提到的 JSON/ETag 方法。
感謝你分享這個,真的很有幫助!
嗨 @jozerizzel,你有機會試用這個工作流程嗎?它有通知你需要的約會變更,還是你遇到了任何困難?
我正在建立一個小型的 n8n 網站變更起始程式,想了解現有方法還有哪些不足之處。謝謝!
我在做類似的事(跨幾個平台監控清單頁),有幾點影響最大:
1. 頻率才是主要變數,不是技巧。 我看過的封鎖多半來自「查太頻繁」,不是請求本身有問題。如果底層資料一天才變幾次,每 5 分鐘查一次不會得到更多東西,只會賠掉連線。我改成固定排程之後就不再被擋。
2. 比對欄位,不要比對整頁。 比對整頁 HTML,對方每次調版面你就收到一次假警報。把你真正在乎的那幾個欄位抓出來、做雜湊、跟上一次比。警報變少,而且每一次都是真的。
3. 留一份「看過什麼」的台帳。 每筆存一個 ID,新的一輪跑完先比對。這一步是把「這頁上的所有東西」變成「跟上次比多了這三筆」的關鍵——後者通常才是看報表的人真正要的。
4. 沒有變化也要通知。 如果連續幾輪都回傳零變化,可能是對的,也可能是選擇器壞了。兩種情況都值得發一則通知。
如果對方有官方 API 或 feed,就算第一天看起來爬蟲比較快,通常還是值得多花那個設定時間。
有幾件事對我來說很關鍵,我在多個列表網站上運行類似的監控器:
頻率是主要變數,而不是技術。
我看到的大多數封禁都來自輪詢過於頻繁,而不是來自請求本身。如果基礎數據一天只變化幾次,每5分鐘檢查一次對你毫無幫助,反而會消耗連接。我從頻繁輪詢改為固定時間表,封禁就停止了。
比較欄位,而不是整個頁面。
比較完整的頁面 HTML 每次他們進行佈局調整時都會給你誤報。提取你真正關心的少數幾個欄位,對這些欄位進行雜湊,然後與上次運行進行比較。警報減少了,你收到的警報都是真實的。
保存一份你已經看過的內容記錄。
為每個項目存儲一個ID,並將新運行與之進行比較。這會將「這是頁面上的所有內容」轉變為「這是自上次以來新增的三項」——這通常是閱讀輸出的人實際想要的。
也要對沉默發出警報。
如果監控器在連續多次運行中返回零變化,這可能是正確的,也可能是選擇器已損壞。無論哪種方式,都值得發送通知。
如果網站有官方API或訂閱源,即使在第一天看起來網頁抓取更快,進行額外的設置幾乎總是值得的。