Quick Tunnels 支援郵件白名單驗證
Cloudflare Blog · 2026-10-02
Cloudflare 的 Quick Tunnels 原本只要拿到網址就能開啟，現在多了 --allowed-mail 旗標，訪客必須用白名單內的信箱收到一次性 PIN 才能進入。這項功能需要 cloudflared 2026.9.3 以上版本，免費，雙方都不需要 Cloudflare 帳號。
原本的問題
Quick Tunnels 自 2021 年推出，一行指令就能把本機服務暴露到公網，但官方文章直言問題所在：「Anyone with the link can open it.」連結一旦被轉貼或被掃到，本機上的開發中應用就等於公開。
想加存取控制的人，過去只能改走需要帳號與固定主機名稱的正式 Cloudflare Tunnel 搭配 Access，或自己在應用裡寫一層登入。文章提到，9 月 18 日有一則 Hacker News 討論獲得 800 多分、300 多則留言，其中有人擔心 agent 工作流程隨手開出的 tunnel 會把私人資料或不安全的半成品直接曝光。
核心改動
用法是在原指令後加上信箱，可重複指定，也可用萬用字元開放整個網域。官方文件另列出逗號分隔的寫法。
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com \
--allowed-mail '*@example.com'
npx wrangler tunnel quick-start http://localhost:8080 \
--allowed-mail alice@example.com驗證流程分四步：
- 訪客開啟連結，
cloudflared發現沒有 session，把瀏覽器導向login.trycloudflare.com，並附上單次使用、綁定該瀏覽器、10 分鐘內有效的隨機 state。 - Cloudflare Access 寄出一次性 PIN，確認訪客擁有該信箱。
- 驗證 broker 回傳短效簽章憑證，瀏覽器以 form POST 送回，所以憑證不會出現在網址、瀏覽器歷史或 log。
- 本機的
cloudflared驗證簽章，並比對信箱是否符合你的規則。
設計取捨
白名單只存在你本機 cloudflared 的記憶體裡。文章說，Cloudflare 只知道這個 tunnel 要求信箱驗證，不知道你邀請了誰；broker 不儲存 tunnel 政策、訪客 session 或身分紀錄。代價是登入之後沒有中央政策服務可以即時撤銷，session 最長維持四小時（訪客的 Access 登入較早過期則提前結束），或直到你停掉 cloudflared。
失敗時一律拒絕：任何檢查不過，請求都不會到達本機服務；若 cloudflared 無法確認支援這個驗證模式，它會拒絕啟動，而不是給你一個公開網址。
| 以前 | 現在 | |
|---|---|---|
| 誰能開啟 | 任何拿到連結的人 | 白名單信箱（收 PIN） |
| 帳號需求 | 無 | 無 |
| 政策位置 | 無 | 本機 cloudflared 記憶體 |
影響範圍
會用 Quick Tunnel 給同事看 demo、接 webhook 或讓 agent 暫時暴露服務的人，應把 cloudflared 升到 2026.9.3 以上，並在指令加上 --allowed-mail。團隊共用時，一條 '*@example.com' 就能涵蓋整個網域。
要注意幾個限制。信箱驗證需要互動式瀏覽器，非互動的客戶端（腳本、webhook 呼叫端）無法通過，這類用途仍需公開 tunnel 或正式 Tunnel。文件另載明每個 Quick Tunnel 最多 200 個同時處理的請求，超過回傳 429，不支援 Server-Sent Events，也沒有 uptime SLA，每次新建 tunnel 網址都會變。
需要固定主機名稱或身分提供者群組等進階規則時，官方建議改用 Cloudflare Tunnel 加 Cloudflare Access。