同仁開啟網址
在家裡或手機輸入公司核准的 APP 網址。
CLOUDFLARE 入門第一課
把網址、入口與保護，
一次分清楚
Cloudflare 整體不是單一資料庫，比較像公司大樓外面的「門牌、警衛與安全通道」。 D1 是其中一項資料庫服務；Supabase 則是另一套獨立資料庫，兩者不會自動互相取代。
01
同仁從外地打開 APP 時
四個步驟看懂 Cloudflare 放在哪裡
DNS 找到入口
像通訊錄一樣，把網址帶到正確的 Cloudflare 服務。
入口先驗身分
可用簡單密碼，或 Zero Trust 逐人確認公司身分。
Tunnel 連回 APP
走加密通道到 Mac Studio，不直接公開 Supabase 連接埠。
最短記法：
DNS 負責帶路，Zero Trust／密碼負責看門，Tunnel 負責安全連回公司主機。
02
網址與部署
先分清楚名字、位置與 Cloudflare 上的服務
Cloudflare
位在使用者與公司系統之間的網路服務，可管理網址、安全入口、網站部署與流量保護。
本案目前用於公開進度頁、遠端 APP 入口與回公司主機的私有連線；公司自訂網域仍待後續設定。網域
網站的主要名稱，例如 ladylike.com.tw；網址使用權屬於網域持有人。
是否讓內部電商 APP 掛在萊可正式網域，仍待內部會議決定。子網域
主網域下面提供特定服務的網址前綴，例如 ecommerce.ladylike.com.tw。
未來可分開 APP 與 Webhook 入口，目前都只是提案名稱。網址通訊錄
把好記的網址指向實際服務位置；它負責帶路，不負責登入或資料權限。
沒有 DNS 也能完成本機 Production 架構；需要固定正式網址時再設定。網域管理區
Cloudflare 裡集中管理某個主網域 DNS、安全與路由設定的範圍。
新增萊可子網域前，操作帳號必須取得 ladylike.com.tw Zone 的核准權限。Cloudflare Workers
在 Cloudflare 網路上執行的小型後端程式，像接到操作後負責辦事的櫃台人員。
Worker 可以去查 D1，也可以轉接 Supabase；它去找哪一套資料庫，就由哪一套計算資料用量。預設 Worker 網址
Cloudflare 提供給 Worker 的預設網址，不需要先使用公司正式網域。
適合逐區預覽與測試，不是已核准的萊可正式網址。Cloudflare Pages
用來部署靜態網站與前端頁面的服務，適合不直接連正式資料庫的說明頁。
你現在閱讀的專案進度與名詞庫，就是部署在 Pages。自訂網域
讓 Cloudflare 服務改用公司自己的網址，而不是 pages.dev 或 workers.dev。
需先核准網域用途與 DNS 權限，才會正式綁定。Workers Route／路由
指定某個網址或路徑要交給哪個 Worker 處理，就像大樓裡的指路牌。
正式設定只允許 APP 與 Webhook 必要路徑，不公開 Supabase 管理介面。03
資料庫與額度
分清楚 Workers、D1、Supabase，以及什麼時候會扣用量
Cloudflare D1
Cloudflare 提供的雲端資料庫，可以把它想成網站背後的一份大型雲端 Excel。
D1 不是上傳下載必經的暫存區。只有程式真的去查詢或修改 D1，才會使用 D1 額度。Supabase
另一套獨立的資料庫與後端系統，像公司另外一個資料倉庫。
系統接上 Supabase，不代表其他專案會自動停止使用 D1；每個專案要看程式實際連到哪裡。Workers 呼叫次數
每當網站請 Worker 處理一件事，例如登入、查資料或送出表單，就會產生一次或多次 Workers 呼叫。
Workers 呼叫次數與 D1 讀寫列數是兩本不同的帳，不能把兩者當成同一個額度。D1 讀取列數
系統為了找答案，實際翻過多少列資料，就計算多少列讀取。
畫面最後只顯示 20 筆，背後若翻過 10,000 筆，仍可能計算 10,000 列；重新整理、篩選與自動同步都可能再次讀取。D1 寫入列數
新增、修改或刪除多少列資料，就計算相應的寫入量。
例如新增案件、修改案件狀態或同步更新資料，通常會同時先讀舊資料，再寫入新資料。檔案上傳與下載
圖片、PDF 或附件不一定經過 D1，檔案本體可以直接放在 Google Drive、Supabase Storage 或其他檔案空間。
D1 可能只記錄檔名、案件編號與連結，因此上傳動作仍可能產生少量 D1 讀寫，但檔案本體不是先塞進 D1。用目前兩個部門的資料流來看
同仁 → Worker → D1
旅遊業績儀表板與業務／業助交付平台，目前會直接讀寫 D1。
所以開啟儀表板、篩選、同步、查看案件或修改狀態，都可能產生 D1 用量。同仁 → Worker／私有連線 → Supabase
電商 APP 的主要正式資料放在 Supabase，Cloudflare 負責提供入口與安全連線。
這條資料流本身不會使用 D1；只有某項功能另外查詢 D1 時，才會再計算 D1 用量。
最短記法：
程式查 D1，就扣 D1；程式只查 Supabase，就不扣 D1。D1 不是所有資料的必經站。
04
連線與登入
安全通道、來源主機與兩種看門方式
Cloudflare Tunnel
由公司主機主動建立加密連線到 Cloudflare，外部不必直接連公司主機連接埠。
本案目前已用於遠端連回 Mac Studio 的 Admin APP，Supabase 資料庫與管理介面不直接公開。來源主機
真正執行網站或 API 的主機；Cloudflare 位在使用者與來源主機中間。
本案正式來源主機是 Mac Studio，Production Supabase 連接埠不直接公開。Zero Trust
每次存取都先驗證身分與規則，不因為網址或網路位置看似可信就直接放行。
像 APP 前門的公司警衛；純本機／內網可暫緩，敏感資料或遠端使用再啟用。Cloudflare Access
Zero Trust 裡負責登入與允許名單的功能，可限制特定帳號、群組或公司網域。
它負責「誰能進 APP」，不能取代 APP 角色權限與 Supabase RLS。Basic Auth／簡單密碼保護
開啟網站前先輸入一組共用帳號密碼，像一把大家共用的門鎖。
適合少量人員與短期預覽；不能逐人撤權，也無法辨識真正操作者。05
傳輸與防護
加密連線、攻擊阻擋與嘗試次數限制
加密傳輸
把瀏覽器與網站之間的資料加密，避免密碼或內容在網路途中被直接看見。
遠端入口或簡單密碼保護上線時的基本要求；它本身不判斷使用者權限。網站防火牆
檢查並阻擋常見惡意網站請求，像入口的危險物品檢查。
能加強公開入口防護，但資料授權仍由 APP 權限與 Supabase RLS 負責。Rate Limiting／頻率限制
限制同一來源在一段時間內可嘗試登入或呼叫 API 的次數。
能降低密碼暴力嘗試與 API 濫用，使用共用密碼時也應一起設定。06
常見問題
依目前內部使用方式回答
公司已經有 Supabase，為什麼還會用到 D1？
因為兩者是不同資料庫。電商 APP 主要使用 Supabase，但旅遊業績儀表板與交付平台目前仍使用 D1；只有把該專案的資料與程式正式搬走，才會停止產生 D1 用量。
D1 是不是所有資料都要經過的暫存區？
不是。D1 是一套可直接存放正式資料的資料庫，不是 Cloudflare 的必經站。程式沒有查詢或修改 D1，就不會因為經過 Cloudflare 而自動產生 D1 用量。
上傳或下載附件，都會消耗 D1 嗎？
檔案本體不一定會經過 D1。若附件放在 Google Drive 或其他檔案空間，D1 可能只記錄檔名、案件編號與連結，因此通常只會產生少量資料紀錄的讀寫。
目前只在公司內部使用，現在一定要接 DNS 嗎？
不用。Production Supabase、同步、備份與 APP 都可以先在 Mac Studio 正式運作。DNS 是固定網址與遠端入口層，不是正式資料架構的必要條件。
只想加一組簡單密碼，還需要 Zero Trust 嗎？
少量人員、短期使用且不含顧客敏感資料時，共用密碼加 HTTPS 與頻率限制即可。需要逐人停權、外地長期登入或開放訂單個資時，再改用 Zero Trust。
接上 DNS，資料庫就會公開嗎？
不會。正式規劃只公開受保護的 APP 與必要 Webhook 路徑；Supabase API、資料庫、Studio 與 Mailpit 都不直接公開。
Zero Trust 可以取代 Supabase RLS 嗎？
不行。Zero Trust 決定誰能進入 APP；APP 角色決定能操作什麼；Supabase RLS 決定能讀哪些資料。三層各自負責不同範圍。