Azure Front Door (BYOCDN)
此設定會將代理式流量 (來自 AI 機器人和 LLM 使用者代理的要求) 路由至 Edge Optimize 後端服務 (live.edgeoptimize.net)。 真人訪客和 SEO 機器人仍照常由您的來源伺服器提供服務。 若要測試設定，在完成設定之後，請於回應中尋找 x-edgeoptimize-request-id 標頭。
Azure Front Door 不會在邊緣執行自訂程式碼。 路由是使用 規則集 以及 Edge Optimize 專用的 來源群組 進行設定。 容錯移轉是透過 Azure Front Door 以優先順序為基礎的來源群組健康狀態探查來處理。
先決條件
設定 Azure Front Door 路由規則之前，請確定您已準備好以下項目：
步驟 1：為 Edge Optimize 建立來源群組
您的 Azure Front Door 設定檔已有預設來源群組指向您的來源。 為 Edge Optimize 建立 新 來源群組：
-
名稱：
edge-optimize-origin-group -
來源 (基於優先順序的容錯移轉)：
- 優先順序 1 —
live.edgeoptimize.net(來源主機標頭：live.edgeoptimize.net) - 優先順序 2 — 您的網域端點 (例如
www.example.com)。 這是用於容錯移轉：如果 Edge Optimize 健康狀態不佳，將請求路由至您的網域，而網域會重新進入 Azure Front Door，並從您的預設來源提供服務。
- 優先順序 1 —
-
健康狀態探查： 已啟用
- 路徑：
/health/<your-domain>(例如/health/www.example.com) - 通訊協定：HTTPS
- 間隔：225 秒
- 路徑：
-
工作階段親和原則： 已停用
-
憑證主體名稱驗證： 已啟用
edge-optimize-origin-group 來源群組在入口網站中顯示「未關聯」警告。 這是預期中的情況，因為這是透過「規則集」路由覆寫進行參照，而非直接透過路由。步驟 2：設定路由
預設路由通常是使用您的 Azure Front Door 設定檔建立。 規則集 (步驟 3) 會覆寫代理式流量的來源群組，因此 Edge Optimize 不需要另外的路由。
步驟 3：建立規則集
移至「規則集」>「新增規則集」並將其命名為 EORouting。 依此順序新增三個規則。
規則 1：StripIncomingEOHeaders01
移除傳入的 Edge Optimize 標頭以防止詐騙。 無條件 — 適用於所有請求。 停止評估：關閉。
動作 — 刪除以下每個的請求標頭：
x-edgeoptimize-urlx-edgeoptimize-configx-edgeoptimize-api-keyx-edgeoptimize-fetcher-key
規則 2：EOGPTBotRootGET03
在 HTML 頁面路徑上將機器人請求路由至 Edge Optimize。 停止評估：開啟。
條件 (所有條件都必須相符)：
- 請求方法：等於
GET - 要求路徑：RegEx
(^$|^.*/$|(^|.*/)[^./]+$|^.*\.html$)(符合網站根目錄、以/結尾的路徑、無擴充功能的頁面路徑，以及.html路徑) - 使用者代理：包含任何的
chatgpt-user、gptbot、oai-searchbot、adobeedgeoptimize-ai、perplexitybot、perplexity-user、claudebot、claude-user、claude-searchbot。 將字串轉換設為小寫。 x-edgeoptimize-monitor：不包含1x-edgeoptimize-request：不包含任何的failover、1
動作：
- 覆寫請求標頭
x-edgeoptimize-url=/{url_path}?{query_string} - 覆寫請求標頭
x-edgeoptimize-config=LLMCLIENT=TRUE; - 覆寫請求標頭
x-edgeoptimize-api-key=YOUR_API_KEY - 覆寫請求標頭
x-edgeoptimize-monitor=1 - 路由設定覆寫：來源群組 →
edge-optimize-origin-group，轉送通訊協定 → 符合傳入要求，快取 → 已停用
規則 3：HealthProbeRewrite03
重寫 Azure Front Door 健康狀態探查請求，以便透過 / 而非 /health/<domain> 連至您的來源。 這樣 Azure Front Door 便可以監視 Edge Optimize 可用性，且不需要在您的來源上有專屬的健康端點。 停止評估：開啟。
條件 (所有條件都必須相符)：
- 請求 URL 路徑：開頭為
/health/ x-fd-healthprobe：包含1
動作：
- URL 重寫 — 來源模式：
/health/，目標：/ - 覆寫回應標頭
custom-origin-health=routed(診斷：可在驗證後移除) - 附加請求標頭
user-agent=AdobeEdgeOptimize/1.0(新增前置空格：Azure Front Door 會依原樣附加該值) - 覆寫路由設定：來源群組 →
default-origin-group，轉送通訊協定 → 符合傳入要求，快取 → 已停用
步驟 4：將規則集與路由關聯
開啟您的路由，捲動至底部的「規則」區段，然後從下拉式清單中選取「EORouting 規則集」。 如果您有現有的規則集，請使用「移至頂端」將 EORouting 放在 #1。 邊緣最佳化規則只會攔截代理式流量及 Edge Optimize 環回請求，所有其他流量會直接通過並且不影響您的其他規則。 儲存並等待傳播 (大約 20 分鐘)。
透過防火牆規則允許邊緣最佳化 (選用)
如果您的CDN使用WAF或機器人管理員：
-
允許列出WAF或機器人管理員中的
*AdobeEdgeOptimize/1.0*使用者代理程式，讓Edge最佳化服務可以擷取您的來源內容。 -
如果您的防火牆需要使用者代理程式以外的其他驗證，請產生密碼（例如，
openssl rand -hex 32）並：- 將帶有密碼的
x-edgeoptimize-fetcher-key新增到路由規則中與其他x-edgeoptimize-*標頭一起。 - 新增WAF或機器人管理員規則以允許
x-edgeoptimize-fetcher-key符合相同密碼的請求。
- 將帶有密碼的
-
在Edge最佳化會依原樣轉送此標題 — 您擁有完整的金鑰生命週期。
驗證設定
完成設定後，請確認機器人流量會路由至 Edge Optimize，而真人流量不受影響。
1. 測試機器人流量 (應經過最佳化)
運用代理式使用者代理模擬 AI 機器人要求：
curl -svo /dev/null https://www.example.com/page.html \
--header "user-agent: chatgpt-user"
成功的回應會包含 x-edgeoptimize-request-id 標頭，確認要求已經透過 Edge Optimize 進行路由：
< HTTP/2 200
< x-edgeoptimize-request-id: 50fce12d-0519-4fc6-af78-d928785c1b85
2. 測試真人流量 (不應受到影響)
模擬一般真人瀏覽器要求：
curl -svo /dev/null https://www.example.com/page.html \
--header "user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36"
回應 不應 包含 x-edgeoptimize-request-id 標頭。 頁面內容和回應時間應與啟用邊緣最佳化之前維持相同。
3. 如何區分這兩種情境
x-edgeoptimize-request-id流量路由的狀態也可以在Adobe Brand Visibility UI中檢視。 瀏覽至 客戶組態 並選取 CDN組態 標籤。
若要進一步瞭解Edge最佳化，包括可用的機會、自動最佳化工作流程和常見問答，請返回Edge最佳化概覽。