從網頁製作公司角度整理 Cloudflare | 主題

什麼是 Cloudflare？從網頁製作公司角度瞭解其特點、功能及適用場景

Cloudflare 這個名稱本身已經相當知名，但實際上它做什麼卻往往被籠統地理解。坦白說，不久前可能還有人只把它當成「CDN 公司」，也有人是透過去年的故障才認識它的。
雖然很多人都有所了解，但我想整理一下我們這樣的公司及製作人員究竟如何活用它。

Cloudflare 不僅僅是加快網站顯示速度的機制，它還具備 DNS、WAF、身份驗證控制、無伺服器執行、靜態網站配信、檔案儲存、日誌接收，甚至 AI 相關等眾多功能。

從製作公司的現場來看，這一點相當重要。
原因是專案並不是「只要顯示網站」就結束了。每次都會出現如何隱藏測試環境、日誌該發送到哪裡、圖片和附件該放在何處等細節問題。

Cloudflare 的方便之處在於相對容易將這些需求整合到單一的生態系統中。當然，不一定要把所有東西都集中在 Cloudflare，有些專案與 Supabase、AWS 的組合會更自然。
不過，當你想簡化架構或讓設計更容易解釋時，Cloudflare 就相當有力。

特別是對於企業網站、招聘網站、自有媒體，以及包含會員導向流程的網站，Cloudflare 往往能完美契合。對於以前端見長的公司而言，它不只是基礎設施的問題，還能作為實現的延伸來使用，這也是優勢。

一開始不需要記住 Cloudflare 的所有產品名稱。與其如此，不如把它看成「統一管理網路入口附近事務的平台」會輕鬆許多。

例如，從瀏覽器角度看，最先經過的 DNS、快速配送內容的 CDN、攔截可疑存取的 WAF、保護特定頁面的 Access、執行輕量處理的 Workers、靜態配信的 Pages、檔案儲存庫的 R2，Cloudflare 在網路周邊的各個要素上都有相當廣泛的涵蓋。

這可以稱為某種「橫跨整合感」。
在專案中，網站顯示、營運、安全性、更新流程、限制公開、日誌、AI 應用等方面往往存在相互連結的部分，而 Cloudflare 的強項在於能夠輕鬆整理這些部分。

Cloudflare 對於製作公司和前端實裝公司的相容性也相當不錯。
即使不進行厚重的雲端架構設計，也能自然地構建一個恰到好處的配置。

例如，用 Astro 製作企業網站並放在 Cloudflare Pages 上，某些限制頁面用 Access 進行閉鎖，問詢表單透過 Workers 發送電郵，附件存放在 R2，這樣的配置相當自然。
雖然也可以用不同的服務分別組合，但根據專案規模，有時會顯得過於複雜。

當服務增加過多時，在交接和維護階段會顯現出複雜性。轉向 Cloudflare 的話，能夠相對容易地抑制這種複雜性。

在這一點上應該要冷靜看待。
Cloudflare 固然方便，但將所有服務整合到 Cloudflare 並不總是最佳選擇。

在應用程式邏輯相當繁重的專案、複雜資料庫設計為主的專案，以及已經強烈確定採用其他雲端基礎設施的專案中，不以 Cloudflare 為主角有時更為自然。在某些情況下 Vercel 更符合開發體驗，在其他情況下 AWS 確實更容易用來思考整個後端架構。

與其說因為萬能而使用，不如說是根據「想要輕化、強化、整理的部分是什麼」來選擇。在網站配信、入口安全性、輕量級執行環境、限制公開、儲存空間等要素上，Cloudflare 的吸引力相當大。

Cloudflare 適合的案例如下。

對於成熟的 SaaS 或業務系統這類應用為主角的專案，我們不只考慮 Cloudflare 本身，而是看如何與其他基礎設施（如 Supabase）組合使用。

這部分以前得花大量時間對比服務資料和文件，然後在腦子裡整理，但最近情況改變不少。

用 Claude Code 或 Gemini 進行頭腦風暴，探討「這個需求涉及 Cloudflare 哪些功能」、「測試環境保護和表單基礎設施怎麼切分」等問題，初期整理速度快得多。
比較表的初稿和論點梳理變得輕鬆許多。

責任邊界、運營體系、審計要求、更新負責人的理解程度等，最後還是要人工審視，不能完全依賴。LLM 的角色是繪製初步地圖，人類則負責為實際情景選擇合適的路徑，這樣的分工最為恰當。

簡言之，Cloudflare 不只是單純的加速服務，而是能廣泛支撐 Web 周邊的平台。從製作公司的角度看，當我們希望「簡化架構」但又「確保必要的防護和實裝到位」時，它的效果相當顯著。

當然，不是一定要選 Cloudflare。
從網站配信、認證控制、輕量後端、儲存空間，到 AI 應用的入口，一應俱全——這確實是很大的吸引力。實際操作後，你會發現印象改觀不少呢！設定其實相當簡單！