UptimeFlare 實測，免費開源監控與狀態頁架在自己的 Cloudflare

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

先講一個掃描結果：2026-10-05 這天，我把 UptimeFlare 官方 demo 狀態頁載入後瀏覽器會拿到的 12 個 JavaScript 檔全部抓下來，在裡面搜尋 api.telegram.org、Bearer、checkProxy 這幾個會出現在監控設定與通知權杖裡的字串，命中數是 0。這件事值得做，是因為這套工具在 2025-09-21 到 2026-03-04 之間的版本，曾把整包監控設定連同通知權杖直接打包進狀態頁的前端程式碼，任何訪客打開瀏覽器開發者工具就能看光。官方安全通報編號 CVE-2026-29779，嚴重度 HIGH。

所以這篇要回答的問題很具體：把網站監控和對外的狀態頁，自架在自己的 Cloudflare 帳號裡跑 UptimeFlare，現在是不是一個安全的選擇，部署前有哪些事要先想清楚。我的接觸範圍包括讀完它的主要原始碼與官方文件、對兩個線上實例做 API 實測、下載前端程式碼掃描，以及點算它的地區監控節點清單；我沒有實際部署一份自己的實例，部署體驗相關的說法都會標明出處。

打開官方 demo：一分鐘檢查是真的，狀態頁直接講繁中

UptimeFlare 是 GitHub 上 3,848 顆星、610 次 fork 的開源專案，作者 lyc8503 一人維護，授權 Apache-2.0。它做的事情是把兩件事搬進你自己的 Cloudflare 帳號：每分鐘一次的伺服器存活監控，以及一個可以對外分享的狀態頁。

官方 demo 在 uptimeflare.pages.dev。我實際打它的 JSON API（路徑 /api/data），回傳 8 個監控項目全數正常，每個項目帶著這次檢查的回應時間與檢查點代碼：多數項目顯示 KIX（大阪），一個 SSH 監控顯示 SIN（新加坡），另一個 homelab 監控顯示 WAW（華沙）。這三個代碼直接證明了它的地區監控不是行銷話術，同一輪檢查確實從不同地理位置出發。它還有一個徽章 API，我用 ?id=blog 測試，回傳一個 shields.io 格式的 JSON，label 是該監控的識別名、message 是 UP、顏色亮綠，可以直接嵌進 README 當狀態燈。

Pin

狀態頁本身的介面語言清單裡有 zh-TW。我把 repo 裡的 locales/zh-TW/common.json 抓下來看過，翻譯是完整的繁體中文，例如「所有服務皆正常運作」「部分服務停止運作…」「最後更新於…」。對外要放一個狀態頁給台灣訪客看的場景，這一頁不用自己再翻譯。密碼保護、用自己的網域 CNAME 指過去、事件歷史頁、維護公告，這些狀態頁該有的都在。

你的 GitHub repo、你的 Cloudflare、訪客的瀏覽器：三段信任鏈

要看懂接下來的安全事件，得先知道這套工具的鑰匙放在哪裡。UptimeFlare 沒有官方託管服務，每個使用者都自己跑一份，部署流程照官方文件的設計是這樣：在 GitHub 按 Use this template 建一份自己的 repo，到 Cloudflare 開一支 API Token（用 Edit Cloudflare Workers 模板再手動補 D1 編輯權限），存進 repo 的 Actions Secrets。接著編輯根目錄的 uptime.config.ts，定義要監控什麼、斷線要通知誰。之後每次改設定，GitHub Actions 會自動用 Terraform 把整套東西部署到你的 Cloudflare 帳號：一支每分鐘觸發的 Worker、一個 D1 資料庫、一個 Pages 狀態頁。

關鍵在那個設定檔。uptime.config.ts 裡寫的是你的監控目標（內部主機名、IP、TCP port）、自訂的 HTTP 標頭（例如 Authorization: Bearer 權杖）、通知用的 webhook 網址（Telegram Bot 的 API token 就嵌在網址裡）。官方文件在快速開始的步驟裡明講：可以把 repo 設成 private，因為設定檔裡可能直接放了權杖。也就是說，這套系統的機密分布在三個地方：存放設定的 GitHub repo、執行與儲存的 Cloudflare 帳號，以及每一個打開狀態頁的訪客瀏覽器。前兩段的邊界你自己管，第三段就是出事的那段。

看門的狗曾把鑰匙攤在門口：CVE-2026-29779

2026-03-04 早上 10 點（UTC），有人向作者回報 issue #198，標題寫得很直白：通知機密正在洩漏到客戶端。當天下午 1 點 39 分，修補 commit 進了 main 分支；傍晚 5 點 55 分，官方安全通報正式發布。一個單人維護的專案，從接獲通報到修補加上發布公告，在一個工作天內完成。

問題的根源講起來一點都不神秘。設定檔同時匯出兩種資料：給狀態頁用的公開設定，以及只有後端該看的私密設定（workerConfig，監控目標、權杖、通知網址全在裡面）。事件歷史頁的程式碼犯了 Next.js 的經典錯誤，在前端元件裡直接 import 了這份私密設定，打包器於是把整包內容連同頁面一起送進瀏覽器。影響範圍是 2025-09-21 到 2026-03-04 之間部署的版本：那段時間任何打開你狀態頁的訪客，都能從原始碼裡撿到你的監控清單、內部主機位址、Bearer 權杖，以及 Telegram 或 Discord 的通知憑證。修補方式是把私密設定改成只在伺服器端以動態載入的方式讀取，並加了一條 ESLint 規則防止同樣的寫法再出現。

開頭講的掃描就是在驗證這件事的現況。demo 首頁的 12 個前端檔案，加上事件歷史頁的全部檔案，我逐一下載搜尋，權杖相關的標記都是 0 命中。修補是真的上線了。但通報裡有一句對舊使用者更重要的話：那段期間設定過的任何憑證，都應該當成已經外洩，逐一輪替。如果你的 UptimeFlare 是 2025 年 9 月到 2026 年 3 月之間部署的，而且用過自訂權杖或通知 webhook，官方通報的處理順序是先升級到修補版、再輪替所有暴露過的憑證；順序顛倒，新權杖會在升級前又進一次公開的前端檔案。

Pin

地區監控的實話：內建 11 個位置參數，城市級要靠第三方

README 對地區監控的宣稱是「超過 310 個城市」，連結過去是 Cloudflare 的網路介紹頁。實際動手查證後，這個數字需要拆開看。內建的地區檢查走的是 Cloudflare Durable Objects 的位置提示，我到 Cloudflare 開發文件把位置參數表整張點算過，能當位置提示用的實數是 11 個，而且是區域等級：weur 是西歐、eeur 是東歐、apac-ne 是東北亞太，依此類推。設定方式是在監控項目加一行 checkProxy: ‘worker://weur’，部署在你自己帳號裡，不依賴任何第三方。310 是 Cloudflare 網路頁標的節點城市數（同一頁現在標 330+），不是你能指定的檢查點數。

要真正做到城市粒度，文件提供的第二條路是 globalping://，背後是 Globalping 這個由社群探針組成的量測網路。我呼叫它的探針清單 API 點算：目前 5,202 個探針、分布在 1,071 個城市。台灣的份量出乎意料地好，60 個探針分布在台北、新北、台中、台南、高雄、新竹、宜蘭、屏東，供應者包括台大、陽明交大、設在台南的國家高速網路與計算中心，以及多家電信業者。想從台灣的視角量一個服務的回應時間，這條路是通的。但它的限制要照抄給你：HTTP 監控只支援 GET、HEAD、OPTIONS，不能帶自訂請求 body，指定的檢查點失效時沒有自動退回本地的機制，而且你的 Globalping API 權杖要寫進設定檔，也就是又多了一把鑰匙要保管。文件標明這條路還在實驗階段。

通知怎麼送：100+ 管道是遺產數字，直連 webhook 才是主路

斷線通知的現行設計是一個通用 webhook 模板。你在設定檔描述一個網址、編碼方式（放在網址參數、JSON、或表單編碼）和訊息模板，$MSG 變數會被換成人類可讀的狀態訊息，可以一次設多組，也能定義緩衝期，連續幾次檢查失敗才送通知，避免網路抖動就半夜炸手機。原始碼裡這條路很乾淨，Worker 直接呼叫你指定的 API，中間沒有別人。

README 上「支援 100+ 通知管道」這個數字，對應的是 Apprise 這個通知聚合器的管道清單。查官方文件後發現它在 2025-10-15 之後已經從預設路線降級為替代方案：想用它，得另外在 Vercel 部署一份 Apprise 服務再填進設定檔。文件現在的建議很明確，主流管道（Telegram、企業微信機器人、Pushover 等）直接用對方自己的 HTTPS API 就好，文件裡附了三種管道的完整設定範例。對大多數人來說 100+ 是個遺產數字，真正的主路是你自己的 webhook。

免費的形狀：限制都長在你的 Cloudflare 帳號上

這套工具標榜完全免費，也確實不需要綁信用卡，Cloudflare 免費方案就跑得動。但它的免費跟 SaaS 的免費層不一樣：帳單不會寄給你，限制卻都長在你自己的帳號上，而且真的曾經撞到牆。原始碼註解裡留著一段誠實的歷史：免費方案跑 10 個以上監控項目時，Worker 會撞上 CPU 時間上限（CPULimitExceeded）。作者的解法是 2026-01-03 把儲存層從 Workers KV 整個搬到 D1 資料庫，並把狀態資料改成欄位壓縮格式。註解裡記著實測數字：同一份真實資料從 433KB 縮到 181KB（小了 59%），P50 CPU 時間從 11.24 毫秒降到 6.36 毫秒（快了 43%）。

檢查的節奏也有平台痕跡。cron 設定是每分鐘觸發一次，程式裡用註解寫明 Cloudflare Workers 的併發連線上限是 6，所以它自我節流到 5。一分鐘間隔在 SaaS 免費層通常要付費才有（常見是 5 分鐘起跳），這是自架方案實實在在的優勢；代價是你對平台配額的感受會比用 SaaS 直接得多。README 宣稱部署全程不用本機工具、10 分鐘內完成，這句我沒有親自驗證，就標明是作者宣稱；從部署腳本看，流程確實全在 GitHub Actions 上跑，本機只需要一個瀏覽器改設定檔。

和 UptimeRobot 怎麼選

TechMoon 之前介紹過 UptimeRobot 這類 SaaS 監控服務，兩者的分野剛好把「要不要自架」這個問題講清楚。UptimeRobot 五分鐘註冊就有免費監控與警報，維運、升級、安全修補都是對方的事；UptimeFlare 的每一分「免費」都來自你自己的 Cloudflare 額度與你自己的 GitHub repo，安全通報要自己盯，權證要自己管，CVE-2026-29779 就是這段信任鏈的實兵演練。反過來說，資料落地在你自己帳號、狀態頁客製深度、一分鐘檢查間隔、原始碼全部可審計，這些是 SaaS 免費層給不了的。如果你要的是單機流量觀察而不是對外狀態頁，Sniffnet 這類桌面工具是另一個方向；想多認識 UptimeFlare 賴以運作的底層，可以先看我們寫的 Cloudflare Workers 介紹。

我的判斷是：有在顧自己的網站或服務、願意開一個 Cloudflare 帳號並管理一個 GitHub repo 的人，UptimeFlare 值得架，尤其適合本來就有對外狀態頁需求的個人專案或小團隊。判斷成功的標準很簡單：狀態頁上線後，你真的在斷線的第一時間收到通知，而且你知道權杖放在哪三個地方。如果不想管這些，留在 SaaS 那側完全合理，那是另一種花錢買省心的選擇。

部署前的三個檢查

我的部署如果落在 2025-09 到 2026-03 之間怎麼辦？ 官方通報給的順序是先升級到修補後的版本，再把這段期間在設定檔放過的所有權杖與通知 webhook 網址視為已外洩、逐一輪替。順序不能顛倒：未升級前先把新權杖寫進設定檔，下一次部署又會把它送進公開的前端檔案。狀態頁的密碼保護功能也在洩漏範圍內，升級後一併換掉。

GitHub repo 一定要設 private 嗎？ 官方文件把 private 列為選項而非必要，理由很實際：設定檔裡可能直接有權杖。用 template 建的新 repo 預設是 public，等你把監控目標與通知網址填進去，repo 的可見度就等於這些機密的可見度。除非你的監控項目完全不含敏感資訊，否則 private 是比較穩的預設。

地區監控要選哪條路？ 先問自己要的是區域還是城市。驗證「歐洲使用者連不連得上」用內建的 worker:// 區域參數就夠，鑰匙不出自己的帳號；要量特定城市（例如台灣各家電信的眼睛看到什麼）再上 globalping://，並接受它的方法與 fallback 限制。兩條路都寫進同一個設定檔，管理負擔是同一套。

授權與專案狀態

授權是 Apache-2.0，商用修改再散布都在條款允許範圍（須依條款保留授權與版權聲明等義務），屬於寬鬆的開源授權。專案由 lyc8503 一人主要維護（GitHub 追蹤者 796 人，個人簡介寫著「Truth above all」），main 分支最後一次 commit 在 2026-06-01，法文與德文介面是 2026 年 2 月由社群貢獻合併，2026 年 9 月還有社群提交新功能的 PR，安全事件當天修補的紀錄前面提過。單人專案的 bus factor 是真實存在的採用風險，但這個 repo 展現的維護紀律，比很多掛著公司名義的倉庫要清楚。要動手的人，從 GitHub 上的 lyc8503/UptimeFlare 出發，照 wiki 的 Quickstart 走，十分鐘的說法就留給你自己驗證了。