嗨各位，
我對 n8n 還算新手，最近一直在試驗如何自動化本機運行應用程式的通知功能。我目前的目標是偵測背景行程是否仍在回應，如果意外停止就傳送 Discord 訊息。
現在我想監控一個本機服務，該服務透過 API 定期回報其狀態。我可以在瀏覽器中存取該端點，但當我在 n8n 中使用 HTTP Request 節點時，要不就收到逾時回應，要不就是 403 錯誤。我也嘗試過用 Cloudflare Tunnel 公開本機服務，但結果不一致。
我監控的應用程式位於 https://dltaexecutor.com/，我想知道是否有人有從 n8n 工作流程輪詢本機執行應用程式的經驗。HTTP Request 節點是否是正確的方法，還是更好的做法是使用 Webhooks 或其他方法來觸發工作流程？
如果你曾經為監控本機應用程式或服務建立過類似的系統，我會很感謝你提供任何建議或最佳做法。謝謝！
描述問題/錯誤/問題
錯誤訊息是什麼（如果有的話）？
請分享你的工作流程
(在畫布上選擇節點，並使用鍵盤快速鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製和貼上工作流程。)
分享最後一個節點傳回的輸出
關於你的 n8n 設定的資訊
- n8n 版本：
- 資料庫（預設：SQLite）：
- n8n EXECUTIONS_PROCESS 設定（預設：own、main）：
- 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：
- 作業系統：
1 個讚
歡迎 @jamielanister！
關鍵問題是 n8n（特別是 n8n Cloud，或在 Docker 中運行時）無法直接連接到 localhost 或本地服務 - n8n 是一個獨立的進程/容器，沒有網路路徑連接到你機器上的本地端口。
修復方式取決於你的設置：
- 透過 Docker 自我託管的 n8n： 將 HTTP Request URL 中的
localhost 替換為 host.docker.internal（例如 http://host.docker.internal:PORT/status）。這是 Docker 內部的主機名，指向你的主機。
- n8n Cloud 或遠端 VPS： 你需要將本地服務公開暴露。Cloudflare Tunnel 是正確的方法 - 你看到的不一致可能是因為隧道未完全啟動或 URL 不穩定。確保隧道作為後台服務運行（不只是一次性的 CLI 命令），並使用固定的
.trycloudflare.com 或你自己的域名 URL。
對於 403 特別是：某些本地服務會拒絕不包含類似瀏覽器的 User-Agent 標頭的請求。在 HTTP Request 節點的標頭中新增 User-Agent: Mozilla/5.0 作為快速測試。
這個問題是 n8n 中自託管雲端連接的衝突。你遇到的 403 問題是 n8n 無法到達 localhost，但由於你在 Docker 上執行 n8n，情況可能不完全是這樣。Cloudflare tunnel 是個不錯的想法，但由於結果不一致，它可能無法保持活躍。
你可以繼續使用 Cloudflare Tunnel，但需要確保 tunnel 以持久服務的形式執行，而不是簡單地以終端工作階段的形式執行並關閉。如果可能的話，在本地應用中包含一個簡單的 ‘/health’ 端點來防止 403 錯誤。
既然你對 Discord 警報感興趣，可以將 Schedule Trigger 與檢查回應代碼的 IF 節點配對。任何不是 200 的代碼都可以發送 Discord 訊息。
嗨 @jamielanister,
這裡的問題是網路可見性。如果你在 Docker 或雲端上執行 n8n，它無法直接路由到 localhost 或你的本機私人網路。
以下是解決連線問題的方法：
-
如果使用 Docker（自託管）：將 HTTP 請求 URL 中的 localhost 替換為 host.docker.internal。這允許容器解析主機的迴路介面。
- 範例：
http://host.docker.internal:PORT/status
-
如果使用 n8n 雲端 / 遠端 VPS：你必須公開服務。如果 Cloudflare Tunnel 看起來不穩定，請驗證它是否作為持久背景服務（例如透過 systemd 或 Docker 容器）執行，而不是臨時 CLI 工作階段。確保通道指向應用程式的正確內部通訊埠。
-
修復 403 禁止存取：本機 API 通常會阻止缺少適當瀏覽器標頭的請求。在 HTTP 請求節點中，新增一個標頭：
使用「執行命令」節點在 n8n 環境本身中 curl 該端點。這有助於隔離故障是網路路由、通訊埠繫結問題還是標頭要求。
逾時/403 是架構的症狀，而不是節點的問題。你要求 n8n（在雲端）深入你的本機——通過 Cloudflare Tunnel、繞過機器人規則等。這個路徑本質上很脆弱，這正是你看到的不一致現象。對於「我的流程還活著嗎？」這個問題，你幾乎總是想反轉做法：採用死人開關（心跳）模式而不是輪詢。
- 讓本機流程本身每分鐘打一次 n8n Webhook（計時器上的單行
curl，或流程中的小迴圈）。這是來自你機器的出站呼叫——沒有入站暴露，沒有隧道，沒有 403。
- 每次 ping，儲存「最後看到 = 現在」（資料表、Redis，甚至靜態檔案）。
- 一個獨立的排程觸發器每 2-3 分鐘檢查一次：如果
現在 - 最後看到 > 閾值，觸發 Discord 警報（當 ping 恢復時，可選地發送「已恢復」訊息，這樣你不會對波動視而不見）。
這樣「流程已死」和「網路/隧道已死」就分不開了——沉默就是信號。如果你必須直接輪詢應用程式，403 通常是 Cloudflare 阻止非瀏覽器請求：設定真實的 User-Agent 標頭並打隧道主機名，而不是原始本機 URL——但說實話，心跳更可靠且維護成本更低。
我們為客戶構建類似的監控/警報流程，所以如果你想要的話，我可以分享確切的心跳 + 死人開關工作流結構——只需說一聲。
— Daniel，Linkrra