OpenClaw LINE Webhook 404 怎麼查？從網址、外網到外掛逐層排除

先分清楚 404、400 與 401

結果	通常代表	先查哪裡
404 Not Found	目前路徑沒有 Webhook 處理器	Path、外掛載入、反向代理
400 Bad Request	路由存在，但請求格式或簽章不足	是否用 LINE 的正式驗證請求
401／403	授權或來源驗證未通過	Channel secret、Token、代理是否改寫內容
500	請求已進入服務，但內部處理失敗	Gateway 與佇列紀錄

用瀏覽器開啟網址得到 200 或看到控制台，也不能取代 Webhook 測試。瀏覽器多半是 GET；LINE Messaging API 傳入事件與驗證都是 POST，而且包含簽章。

第一層：LINE Console 裡的網址

網址必須是外部可連線的 HTTPS，不是 localhost 或區網 IP。
預設路徑通常是 /line/webhook；若設定了自訂 webhookPath，Console 也要完全一致。
Messaging API 頁面的 Use webhook 必須開啟。
網域後面是否多一個斜線、代理是否移除前綴，都要逐字核對。

OpenClaw 官方文件明確指出，它不會替你設定 LINE Console 的 Webhook URL 或開啟 Use webhook；這兩項仍需在 LINE Developers Console 完成。

第二層：公開網址有沒有把 POST 送到 Gateway

若前面有 Cloudflare Tunnel、Nginx、Caddy 或其他反向代理，先查看該層的存取紀錄。完全沒有請求，代表問題還在 DNS、HTTPS、防火牆或 LINE Console；有 POST 但上游回 404，才繼續往 Gateway 查。

代理不要先解析再重組 LINE 的 Request Body。LINE 簽章是對原始內容計算，OpenClaw 也會用原始位元組驗證；中間層若改寫 Body，即使路由正確也可能驗證失敗。

第三層：LINE 外掛是否真的註冊路由

確認安裝的是官方 LINE 外掛，且版本與目前 OpenClaw 相容。
檢查設定中的 LINE channel 是否啟用。
重新啟動或重新載入後，看啟動紀錄是否出現 LINE provider。
執行 openclaw channels status --probe，不要只看沒有 --probe 的本機狀態。
若有多個 LINE 帳號，確認每個帳號都有不同路徑，且 Console 指到正確那一條。

第四層：比對版本與已知問題

OpenClaw 曾出現特定版本在外掛已載入、channel 也啟動的情況下，POST 路由仍回 404 的問題回報。這類問題不能直接套用舊 workaround；先記下 OpenClaw、LINE 外掛、Node.js、作業系統與安裝方式，再查該版本的 release notes 與 issue。

排查時一次只改一件事。若升級前正常，保留升級前後版本與設定差異；若重新安裝外掛後恢復，也要再確認重開機與 Gateway 重啟後仍然可用。

一份可交接的排查紀錄

發生時間與最後一次正常時間。
公開 Webhook URL，隱去網域以外的敏感資料。
OpenClaw、LINE 外掛、Node.js 與作業系統版本。
LINE Console 驗證結果、代理狀態碼與 Gateway 對應紀錄。
每次變更前後的結果；不要貼 Channel secret 或完整 Token。

官方與原始資料

常見問題

LINE Webhook 顯示 404，是 Channel access token 錯了嗎？

通常不是第一個要查的方向。404 代表請求到達的網址沒有對應路由；先確認公開網址、路徑、反向代理與 LINE 外掛是否真的載入。Token 或 Channel secret 錯誤較常出現在驗證或授權階段。

瀏覽器打開 Webhook URL 有畫面，為什麼 LINE 還是驗證失敗？

瀏覽器通常送 GET，LINE 驗證使用簽名過的 POST。GET 能打開控制台，只能證明網域可到達，不能證明 POST 已送到 LINE 外掛的 Webhook 路由。

可以一直更換 Webhook Path 測試嗎？

可以，但 OpenClaw 設定、反向代理與 LINE Developers Console 必須同步修改。每次只改一層並記錄結果，否則最後很難知道是哪個變更讓服務恢復。

還沒開始串接的人

先看 OpenClaw 通訊平台選擇指南，確認 LINE 是否真的是合適入口；如果 Gateway、公開網址與 LINE Console 都還沒建立，可先從個人 AI 助理安裝服務了解準備範圍。