Cloudflare 讓流量變護城河

我把 Cloudflare 的新創操作手冊拆開來看，整理成一份能直接貼進團隊文件的設定模板。

我用 Cloudflare 這套東西一陣子了。介面很乾淨，功能也很多，聽起來像是把網站丟上去就能同時變快、變安全、還能少掉一堆麻煩。問題是，真的上線之後，事情從來不是這樣。你以為自己在做加速，結果先把 checkout 搞壞；你以為自己在擋 bot，結果把真客戶擋在外面；你以為 origin 很安全，結果只是把風險藏得比較深而已。

我最煩的就是這種假安心。工具看起來很完整，團隊也很容易被 dashboard 騙過去，最後才發現真正的洞根本沒補。這次讓我重新整理思路的來源，是 Violetta Bonenkamp 的 Cloudflare News | June, 2026 (STARTUP EDITION)。她不是在講「Cloudflare 很強」這種空話，而是在講創業團隊到底該怎麼把它當成營運層來用。

我先講結論：Cloudflare 不是單純 CDN，也不是單純資安工具。它比較像你網站前面的控制層，決定流量怎麼進來、哪些人可以進來、哪些請求該被擋掉、哪些頁面該快一點。這種東西如果只拿來做「網站加速」，真的太浪費，也太容易用錯。

別再把 Cloudflare 當 CDN，這樣會錯過一半價值

Cloudflare is no longer just a CDN or a security vendor. It is part of the hidden business infrastructure that decides whether your product feels fast, stays reachable, and survives hostile traffic.

翻譯一下就是：Cloudflare 不只是幫你把圖片送快一點，它站在使用者和你的服務中間，能管的事情比很多人想得多。DNS、DDoS、防火牆、Workers、Zero Trust、R2，這些都不是「附加功能」，而是它整套架構的一部分。你如果只把它當內容分發網路，等於把一個控制台當成加速器在用。

我之前看過不少新創一開始很自信，覺得主機商夠了、再加個 CDN 就很完整。結果真實流量一來，問題不是頻寬，而是 DNS 改版時出包、登入頁被打、API 被狂刷、某個舊子網域還留著沒人記得。這些都不是「效能問題」，是營運問題。

Cloudflare 官方也很明白地把它自己講成一整套平台，不是單一產品。你可以看它的 公司介紹、產品頁，以及 全球網路說明。這三頁連起來看，就知道它想賣的不是加速，而是控制權。

實操上，我會先畫一張「對外暴露面」清單，不要急著碰設定。先列出有哪些 domain、subdomain、API、admin panel、staging、media bucket。你不知道自己暴露了什麼，就不可能知道自己該擋什麼。

• 列出所有對外 domain 與 subdomain。
• 標記 public、internal、temporary 三種狀態。
• 把管理介面和測試環境先分級。
• 確認 origin 能不能繞過 Cloudflare 直接打到。

速度不是面子工程，它直接影響成交

很多 founder 喜歡說速度重要，然後把它丟給工程師、外包、或「之後再說」。我覺得這很常見，但也很偷懶。對新創來說，速度不是炫技指標，它是購買體驗的一部分。頁面慢、登入卡、產品示範載半天，使用者不會幫你找理由，他只會走。

Bonenkamp 的重點不是在講「Cloudflare 很快」這種空泛說法，而是在講它能把延遲壓到更靠近使用者的地方。Cloudflare 官方說它的網路覆蓋超過 330 個城市，並宣稱大約 95% 的網路使用者能在約 50 毫秒內碰到它的節點。你不一定要背數字，但你要懂意思：流量不一定非得全回 origin，很多事情可以先在 edge 做掉。

也就是說，靜態資產、TLS、路由、快取策略，這些都可以先在邊緣層處理，減少你的主機壓力。對跨區域賣產品的新創來說，這差很多。你如果只靠單一 region 的 origin，亞洲或歐洲的使用者常常就是被你拖慢，不是因為產品差，是因為架構懶。

我之前看過一個團隊拼命優化後端，改 query、加索引、升級機器，結果真正的瓶頸是所有請求都打回同一台 origin。前端每個請求都要繞遠路，難怪看起來像壞掉。Cloudflare 可以幫你遮掉一部分痛，但前提是你要把快取和路由想清楚。

實操上，我會先從靜態資產和行銷頁開始，不要一口氣全站 aggressive cache。那種做法很容易把登入後頁面、購物車、個人化內容一起弄壞。最穩的方式是把 marketing site 和 app route 分開處理。

• 行銷頁與靜態資產先快取。
• 登入後頁面與 checkout 一律 bypass cache。
• 至少用兩個地區測試首屏與互動速度。
• 看真實使用者速度，不要只看實驗室數據。

安全不是附加價值，是你第一天就該做的事

Cloudflare 這套東西真正厲害的地方，不是「有資安功能」，而是它把資安放在流量入口。這件事很現實。以前很多團隊的做法是先把產品做完，上線之後再補防護。那套路現在很危險，因為你一旦有真流量，就已經有真攻擊面了。

Cloudflare 能做的事包括 DDoS mitigation、WAF、bot filtering、HTTPS 控制。白話講，就是先把一堆爛流量擋在外面，讓你的 app 不用每次都親自接球。對 founder 來說，這不只是「比較安全」，而是少掉一堆莫名其妙的事故：登入被刷、API 被爆、惡意流量把成本打爆。

但我也要講難聽一點：Cloudflare 不會幫你修爛架構。你的 origin 如果直接暴露、admin panel 如果公開、API 如果沒認證紀律，Cloudflare 只是幫你多一道關卡，不是幫你變無敵。

我很常看到團隊講一句話就覺得結案：「我們已經放到 Cloudflare 後面了。」沒有，這只是降低風險，不是消滅風險。真正該做的是把 origin 隱起來、把權限收緊、把高風險路徑先管起來。

實操上，先盯最會燒錢的路徑：登入、註冊、忘記密碼、API 寫入、admin 存取。這些地方先做 rate limit、WAF review、HTTPS 全站強制，再往外擴。

• 全站強制 HTTPS。
• 盡量限制 direct origin access。
• 登入與 API 寫入路徑加 rate limit。
• 啟用 WAF 後先看 log，再調規則。

Zero Trust 不是大公司玩具，遠端團隊其實更需要

Cloudflare 的 Zero Trust 之所以值得講，是因為現在新創團隊本來就分散。外包、顧問、兼職、遠端員工，大家都要碰內部工具，但不是每個人都該有同樣權限。以前那種「大家都進 VPN」的思路，真的又重又粗。

翻譯一下就是：你不該把整個內網開給每個人，而是該讓每個人只碰自己需要的東西。Cloudflare 可以站在內部應用前面，根據身分、裝置、位置、政策去決定能不能進。這比單純切一條 VPN tunnel 更接近實務。

我自己看過最常見的問題是權限失控。自由接案的人只需要 staging，不需要 payroll；客服只需要 ticketing，不需要 production DB；創辦人出差時想從飯店 Wi-Fi 看內部工具，不代表整個內網都該對外敞開。Zero Trust 的價值就在這裡：它讓權限變細，而不是變大。

實操上，我會先拿一個內部工具試，不要一口氣重做全公司。先選 wiki、dashboard、admin panel 其中一個，要求 identity-based access，跑順之後再擴。你如果一次改太多，最後通常不是安全提升，而是自己把自己鎖在門外。

還有一件很煩但很重要的事：權限政策要寫 owner。沒有 owner 的政策很快就會變成沒人敢動的垃圾設定。那種東西看起來很穩，其實只是大家都懶得碰。

AI 產品最怕的不是模型慢，是 bot 和濫用

這篇裡我最有感的是 AI traffic 這段。只要你有公開 AI 產品，機器流量就會很快出現：抓 prompt、掃 endpoint、重放請求、試 rate limit、洗免費額度。你如果沒先想 bot control，基本上就是等著被教育。

Cloudflare 在這裡的價值，不是幫你把模型跑更快，而是幫你把流量分乾淨。哪些是人、哪些是機器、哪些請求該限速、哪些 endpoint 該加保護，這些都是 edge 層很適合做的事。對 AI 產品來說，這不是額外裝飾，這是基本盤。

也就是說，你不是在保護一個網站而已，你是在保護 prompts、API、inference endpoint、demo flow，還有那些你以為「大概夠用」的限制。通常都不夠。

我看過不少團隊先做 demo，結果 demo 一公開就被 scrape、被 replay、被濫用。團隊第一反應是怪模型品質，實際上問題常常是曝光面太大。只要 endpoint 公開，流量型態就會立刻變質。

實操上，我會把 AI 產品當成公開服務來設計，不要當成內部實驗。匿名請求要硬限速，付費動作要強制驗證，demo 與 production key 要分開，還要持續看異常重試和重複 prompt pattern。

• 有意義的 AI 動作一律要求登入。
• 匿名流量先重度限速。
• demo、staging、production keys 分開。
• 追蹤重複 prompt、異常頻率、失敗重試。

Cloudflare 不是替你補爛架構，它只會放大你做對的部分

這是我最想提醒 founder 的地方。Cloudflare 很強，但它不會替你解決流程混亂、文件缺失、權限失控、回滾機制不存在這些老問題。你如果本來就沒有架構觀念，工具只會讓你看起來比較專業，實際上還是亂。

翻譯一下就是：你還是得知道哪些 request 可以 cache、哪些 route 絕對不能 cache、哪些 endpoint 是 public、哪些是 internal、哪些子網域可以退役。這些問題沒有答案，你只是在收 dashboard 噪音而已。

我對這件事很有意見，因為我看過太多團隊把工具堆上去，卻沒有營運模型。結果沒人說得清楚某條規則為什麼存在、某張憑證為什麼過期、某個 contractor 為什麼失去存取、某個 API 為什麼被限流。那不是精實，那是混亂。

實操上，我會做一頁 Cloudflare operating sheet，內容不用漂亮，但一定要完整。把 domain、owner、關鍵規則、回滾步驟、緊急聯絡人放在同一頁。新同事看一眼就知道怎麼接，不需要去問三個人。

而且這份文件要每次 launch 後都更新。Cloudflare 設定很容易悄悄腐爛。第一版合理的規則，到了第三版通常就不一定對了。這很正常，放著不管才是問題。

可抄的模板

# Cloudflare startup operating sheet

## 1) What is behind Cloudflare
- Primary domain:
- Subdomains:
- Public APIs:
- Admin panels:
- Staging environments:
- Static assets / media buckets:

## 2) Business goal
- Faster pages for:
- Revenue-critical routes:
- Internal apps to protect:
- AI endpoints to protect:

## 3) Security baseline
- HTTPS enforced: yes/no
- Origin hidden from direct access: yes/no
- WAF enabled: yes/no
- Bot protection enabled: yes/no
- Rate limits on login/API: yes/no
- Zero Trust for internal tools: yes/no

## 4) Caching rules
- Cache marketing pages: yes/no
- Cache static assets: yes/no
- Bypass cache for checkout: yes/no
- Bypass cache for authenticated pages: yes/no
- Regional testing done: yes/no

## 5) AI / bot controls
- Anonymous request limit:
- Auth required for paid actions: yes/no
- Demo environment separated: yes/no
- Suspicious pattern logging enabled: yes/no

## 6) Access control
- Who owns Cloudflare admin access:
- Who can change DNS:
- Who can change WAF rules:
- Who can change Zero Trust policies:
- Emergency rollback contact:

## 7) Monitoring
- Checkout conversion:
- Login failure rate:
- 4xx / 5xx spikes:
- Bot traffic percentage:
- Origin request count:
- Median page load time:

## 8) Change process
- What changed:
- Why it changed:
- How it was tested:
- Rollback plan:
- Date reviewed:

這份模板我會直接拿去當團隊文件的底稿。它不華麗，但很實用。對新創來說，實用比漂亮重要太多。

原始來源是 blog.mean.ceo 的這篇文章，Cloudflare 官方資料則可參考 公司介紹、產品頁、網路說明。上面的觀點拆解是我自己的整理，模板則是我根據原文延伸成可直接使用的版本。