Cloudflare 支援批次建立 Tunnel 與 Mesh 路由：擴容前先完成驗證
Cloudflare 於 2026 年 9 月 2 日宣布，儀表板現在可以一次建立多條 Cloudflare Tunnel 與 Cloudflare Mesh 路由。維運人員可同時輸入多個 CIDR 網段或主機名稱，暫存不同的「路由—連接器」組合，並只重試驗證失敗的項目；建立成功的項目會從表單移除，方便繼續修正其餘失敗項目。
對經由私有網路連接代理閘道、合規蒐集任務、廣告驗證瀏覽器或市場研究工作的團隊，這能減少重複設定，但單次操作的影響範圍也更大。一批語法正確的路由，仍可能指向錯誤連接器、覆蓋既有前綴、繞過預期檢查路徑，或造成回程流量不對稱。
公開來源說明： Cloudflare，《Create multiple Cloudflare Tunnel and Cloudflare Mesh routes at once》，2026 年 9 月 2 日。
新功能改變了什麼
這次更新改變的是批次操作方式，而不是單條路由的意義。一個目的地仍需映射到確定的連接器與路由類型。新儀表板允許：
- 為同一連接器一次輸入多個主機名稱或 CIDR；
- 在提交前繼續加入其他路由組；
- 在一個暫存批次中使用不同連接器或路由類型；
- 保留失敗項目供修正，同時從表單移除已完成項目；
- 採用與批次 WAN 靜態路由相近的操作方式。
「只重試失敗項目」很實用，卻帶來對帳要求。部分成功後，原批次已分成「已生效」與「尚未建立」兩組。變更單和自動化記錄必須保存兩組狀態，否則再次提交可能產生重複設定或留下涵蓋缺口。
為何代理與蒐集團隊需要關注
代理出口常依地區、客戶、工作或合規邊界隔離。路由變更會影響認證流量進入哪個閘道、哪些出口群組可達，以及日誌能否把工作與真實網路路徑關聯。錯誤路由因此可能被誤判為「代理品質差」，即使供應商與出口位址本身完全健康。
應特別觀察四類現象：
- 地區或 ASN 不符。 請求成功，但實際經過錯誤區域的連接器。
- 直連回退。 路由未匹配時，流量繞開指定代理或私有路徑。
- 部分可達。 IPv4 正常，但 IPv6、特定前綴或一組主機名稱失敗。
- 重試放大。 工作節點把路由故障當成出口故障，輪替大量健康 IP。
可搭配代理直連回退偵測指南驗證故障閉鎖，並用代理重試預算指南避免單一路由錯誤耗盡整個位址池。
提交批次前先做預檢
點擊建立前，把暫存項目整理成可審閱清單。每列至少包含目的地、前綴長度或主機名稱、路由類型、連接器、環境、負責人、預期出口區域、變更單與回復路由。
接著檢查：
- 正規化 CIDR，拒絕前綴之外仍帶主機位元的輸入；
- 展開別名，讓審閱者看到真實目的地集合；
- 偵測完全重複和網段重疊；
- 不只比較本批次，還要與既有路由表比較；
- 確認更具體的路由不會意外搶占共用路徑；
- 驗證目標區域連接器的健康度與容量；
- 分別證明 IPv4 與 IPv6 遵循既定策略；
- 標記任何失敗後可能允許直接上網的路由；
- 從截圖與工單清除代理密碼和客戶識別資料。
主機名稱路由屬於動態狀態，還應記錄 DNS 變化如何影響匹配，以及連接器與工作節點看到的解析結果是否一致。
採用分階段上線
不要在批次建立後立即恢復全部並行量。先選擇一個受控路由組，用自有或明確獲准的目的地執行一個合成工作。
每次測試記錄：
- 工作節點和連接器識別碼；
- 預期路由與實際連接器；
- 代理閘道群組與預期地區；
- 實際出口國家、地區、ASN 與 IP 協定族；
- DNS 解析方與回傳位址族；
- 通道建立結果；
- 應用狀態與內容驗證結果；
- 重試次數、延遲與傳輸位元組。
通過條件不能只是「連線成功」。請求必須使用預期私有路徑、到達獲准目的地、經過正確代理出口，並回傳應用上有效的內容。錯誤地區或直連路徑回傳的 200 頁面仍然是失敗。
對帳部分成功的批次
如果多條路由成功而一條失敗，先凍結部署記錄再重試。匯出或複製已建立清單，標記未完成項目，並把兩組都與原始清單比較。只修正失敗列。
重試後執行三次集合檢查：
- 預期減實際： 找出缺少的路由。
- 實際減預期： 找出意外或陳舊路由。
- 重疊的有效路徑： 找出雖存在、卻不會依預期勝出的路由。
儀表板把成功項目移出表單，不等於提供稽核日誌。應另外保存帶時間與負責人的不可變更記錄。
回復與故障邊界
提交前就定義回復方案：舊連接器或舊路由、最大可接受錯誤率、觀察期間，以及有權撤銷變更的負責人。
依最先出現異常的邊界分類：
- 設定拒絕： 目的地格式錯誤或不受支援；
- 路由選擇失敗： 預期路由沒有勝出；
- 連接器失敗： 已選連接器不健康或不可達；
- 代理邊界失敗： 閘道認證或通道建立失敗；
- 目的地回應： 路徑正常，但目標拒絕或限流；
- 內容失敗： 傳輸成功，但語言、時效、結構或頁面身分錯誤。
只有代理邊界證據應影響代理健康評分。路由或連接器故障不應導致出口 IP 被隔離。
發布檢查清單
- [ ] 已在內部記錄官方更新、日期與來源 URL。
- [ ] 每個 CIDR 或主機名稱都有負責人和環境標記。
- [ ] 已審閱完全重複與網段重疊。
- [ ] 衝突分析包含既有路由。
- [ ] 已檢查連接器健康度與地區容量。
- [ ] 直連回退已禁止或可明確偵測。
- [ ] IPv4 與 IPv6 已分別測試。
- [ ] 單一工作灰度證明實際連接器與出口地區正確。
- [ ] 已驗證應用內容，而非只看狀態碼。
- [ ] 部分成功項目已與原始清單對帳。
- [ ] 回復門檻與負責人已記錄。
- [ ] 日誌和截圖不含密碼或個人資料。
合規與安全
私有路由和代理基礎設施只能用於你獲准存取的系統、帳號和資料。遵守目標條款、robots 指引、速率限制、隱私要求和資料最小化原則。批次建立提升的是操作效率，不代表可以擴大目標範圍。目標拒絕或限流時應停止並解決授權或容量問題，不得透過改路由或輪替 IP 繞過控制。
常見問題
批次建立會改變路由優先順序嗎？
官方更新描述的是儀表板工作流程，而不是新的路由模型。仍需根據完整路由表評估前綴具體度和選擇規則。
一條失敗時是否應刪除所有成功項目？
不應自動刪除。先把部分結果與核准清單對帳，再依預先核准的變更計畫決定保留或回復成功子集。
連線成功是否足以核准整個批次？
不夠。還要驗證連接器身分、代理路徑、出口地區、IP 協定族和應用內容。在錯誤路徑上成功仍是路由缺陷。
首次灰度應多大？
每類路由先用一個受控目的地和一個低並行工作。只有路由、代理與應用證據都符合清單後再擴大。
