CloudFront (BYOCDN)
此配置将代理式流量（来自 AI 机器人和 LLM 用户代理的请求）路由到 Edge Optimize 后端服务（live.edgeoptimize.net）。 人类访客和 SEO 机器人仍将照常从您的源站获得响应。 完成设置后，可在响应中查找头部 x-edgeoptimize-request-id 以测试配置是否成功。
先决条件
在设置 CloudFront 配置之前，请确保您具有：
- 服务于您的网站的现有 CloudFront 分发。
- 用于创建 Lambda 函数、IAM 角色、CloudFront 分发和缓存策略的 AWS IAM 权限。
- 完成了 LLM Optimizer 的加入过程。
- 已将内容传递网络日志转发到 LLM Optimizer。
- 具有从 LLM Optimizer UI 检索到的 Edge Optimize API 密钥。
检索API密钥的步骤：
-
导航到 客户配置 并选择 CDN配置 选项卡。
-
在 AI流量路由到部署优化 下，勾选 将优化部署到AI代理 复选框。
-
复制API密钥，并继续执行下面的路由配置步骤。
note note NOTE 在此阶段，状态可能显示红叉，指示设置尚未完成。 这是正常情况 — 一旦您完成下面的路由配置并且AI机器人流量开始流动，状态将更新为绿色复选标记，确认路由已成功启用。
此外，如果您需要上述步骤的任何帮助，请联系您的Adobe客户团队或llmo-at-edge@adobe.com。
步骤 1：创建 Edge Optimize 源站
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 源站选项卡
-
点击创建源站。
-
配置源站：
- 源站域：
live.edgeoptimize.net - 名称：
EdgeOptimize_Origin
- 源站域：
-
让所有其他字段保留其默认值。
-
添加自定义标头：
table 0-row-2 1-row-2 2-row-2 页眉 值 x-edgeoptimize-api-key您的 API 密钥 x-forwarded-hostwww.example.com将
www.example.com替换为您真实的网站域，将Your API key替换为您的 Adobe 代表提供的 Edge Optimize API 密钥。 -
点击创建源站。
步骤 2：创建查看器请求函数
导航： AWS 控制台 > CloudFront > 函数
-
点击创建函数。
-
配置：
- 名称：
edgeoptimize-routing - 运行时间：
cloudfront-js-2.0
- 名称：
-
将默认代码替换为 viewer-request.js 中的代码。
在发布之前，请自定义代码中的以下值：
YOUR_DEFAULT_ORIGIN— 替换为您现有的默认源站的名称（可在 CloudFront > 分发 > [您的分发] > 源站选项卡中找到）。TARGETED_PATHS— 设置为null，将所有 HTML 页面定为目标，或设置为特定路径的数组，例如['/', '/products', '/about']。
-
点击保存更改 > 发布函数。
步骤 3：配置缓存策略
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 行为
检查当前附加到您行为的缓存策略。点击行为上的编辑，查看 缓存键和源站请求 部分，识别您的场景：
- 场景 A（旧版）：您会看到所选的单选按钮带有标记旧版缓存设置。没有策略名称下拉列表，您会看到内联 TTL 和标头设置。
- 场景 B（自定义策略）：您会看到所选的 缓存策略 带有您或您的团队创建的策略名称（不是 AWS 提供的策略）。
- 场景 C（托管策略）：您会看到所选的 缓存策略 带有一个 AWS 提供的名称，如
CachingOptimized、CachingDisabled或CachingOptimizedForUncompressedObjects，这些都无法编辑。
场景 A：旧版缓存设置
如果您的行为使用旧版缓存设置：
-
在 缓存键和源站请求 中，您会看到选择了旧版缓存设置。
-
将
x-edgeoptimize-config和x-edgeoptimize-url添加到 标头 允许列表：- 从下拉列表中选择包含以下标头。
- 添加
x-edgeoptimize-config和x-edgeoptimize-url。
如果您在“标头”下拉列表中选择了所有，请跳过此步骤，所有标头都会自动转发到源站。
-
检查 对象缓存 设置：
- 如果设置为自定义，建议将最小 TTL 设置为
0。但是，如果当前的最小 TTL 已经非常短，可能就不需要再更改。 - 如果设置为使用源站缓存标头，就无需更改。
- 如果设置为自定义，建议将最小 TTL 设置为
-
点击保存更改。
场景 B：带有自定义缓存策略的非旧版
如果您的行为已使用一个自定义缓存策略（您创建的策略，而不是 AWS 托管策略）：
导航： AWS 控制台 > CloudFront > 策略 > 缓存
-
点击您的现有策略。
-
单击编辑。
-
建议将最小 TTL 设置为
0。但是，如果当前的最小 TTL 已经非常短，可能就不需要再更改。
-
在缓存键设置 > 标头中，除了您现有的包含项以外，再添加
x-edgeoptimize-config和x-edgeoptimize-url。
-
点击保存更改。
场景 C：带有托管 (AWS) 缓存策略的非旧版
如果您的行为使用 AWS 托管缓存策略（例如 CachingOptimized），您就无法进行编辑。您需要创建一个新的自定义缓存策略，此策略复制现有的托管策略设置，并添加在 Edge Optimize 标头的最上面。
第 1 部分：记下您当前的托管缓存策略设置
导航： AWS 控制台 > CloudFront > 策略 > 缓存
-
找到并点击当前附加到您的行为的托管缓存策略（例如
CachingOptimized）。 -
记下所有现有设置：
- 最小 TTL、最大 TTL、默认 TTL
- 缓存键中包含的标头
- 缓存键中包含的 Cookie
- 缓存键中包含的查询字符串
- 压缩支持（Gzip、Brotli）
第 2 部分：用相同的设置创建一个新的自定义缓存策略 + Edge Optimize 配置
导航： AWS 控制台 > CloudFront > 策略 > 缓存
-
点击创建缓存策略。
-
名称：
edgeoptimize-cache
-
复制第 1 部分中记下的所有设置，然后进行以下修改：
- 建议将最小 TTL 设置为
0。但是，如果当前的最小 TTL 已经非常短，可能就不需要再更改。
- 在缓存键设置 > 标头中，包含托管策略中的所有内容，然后添加
x-edgeoptimize-config和x-edgeoptimize-url。
- 建议将最小 TTL 设置为
-
单击创建。
-
返回到您的行为，关联新创建的策略：
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 行为
- 编辑您的行为。
- 在 缓存键和源站请求 中选择缓存策略。
- 从下拉列表中选择
edgeoptimize-cache。 - 点击保存更改。
步骤 4：创建 Lambda@Edge 函数（源站请求和响应）
us-east-1（弗吉尼亚北部）区域中创建 Lambda@Edge 函数。这是 AWS 的要求。即使函数是在 us-east-1 中创建，AWS 仍会自动将其复制到全球所有 CloudFront 边缘位置，因此它会在距离查看器最近的边缘位置执行。在继续操作之前，请确保您位于 AWS 控制台的 us-east-1 区域中。创建 Lambda 函数
导航： AWS 控制台 > Lambda
-
点击创建函数。
-
选择从头开始创作。
-
配置：
- 函数名称：
edgeoptimize-origin - 让所有其他字段保留其默认值。
- 函数名称：
-
点击创建函数。
-
在代码编辑器中，将默认代码替换为 origin-request-response.js 中的代码。
-
点击部署，保存代码。
-
请注意配置 > 权限中显示的执行角色名称（例如
edgeoptimize-origin-role-xxxxx）。在以下步骤中您需要此名称。
更新执行角色的信任策略
自动创建的角色只信任 lambda.amazonaws.com。您还必须为 Lambda@Edge 添加 edgelambda.amazonaws.com。
导航： AWS 控制台 > IAM > 角色 > [上一步中的角色] > 信任关系选项卡
-
点击编辑信任策略。
-
将策略替换为 trust-policy.json 中的内容。
-
点击更新策略。
edgelambda.amazonaws.com服务主体是必填项。否则，CloudFront 就无法在边缘位置调用您的函数。修复 CloudWatch 日志权限策略
自动创建的角色带有为常规 Lambda 配置的 AWSLambdaBasicExecutionRole 策略，具有错误的 Lambda@Edge 区域和日志组名称。您需要将其更新。
导航： AWS 控制台 > IAM >角色 > [您的角色] > 权限选项卡 > 点击所附加的策略名称（例如 AWSLambdaBasicExecutionRole-xxxx）
-
单击编辑。
-
将策略替换为 cloudwatch-policy.json 中的内容。
在 JSON 中，将
ACCOUNT_ID替换为您的真实 AWS 帐户 ID（可在 AWS 控制台的右上角找到），将FUNCTION_NAME替换为 Lambda 函数的名称（例如edgeoptimize-origin）。 -
点击保存更改。
* — Lambda@Edge 在距离查看器最近的边缘位置执行，因此日志将写入边缘位置区域的 CloudWatch（例如 ap-south-1，eu-west-1），不一定是 us-east-1。日志组使用一个区域前缀名：/aws/lambda/us-east-1.FUNCTION_NAME，其中 us-east-1 总是函数的主区域。发布版本
-
在函数页面上点击操作（右上方）> 发布新版本。
-
添加描述。
-
单击发布。
-
复制或记下函数 ARN — 您在下一步中需要它。
步骤 5：将函数和缓存策略与行为关联起来
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 行为
-
编辑您的行为。
-
如果您在步骤 3（场景 C）中创建了新的缓存策略，应将 缓存策略 设置为
edgeoptimize-cache。
-
在 函数关联 中配置：
- 查看器请求：
edgeoptimize-routing - 源站请求：步骤 4 中带版本的函数 ARN（在 发布版本 中）
- 源站响应：步骤 4 中带版本的函数 ARN（在 发布版本 中）
- 查看器请求：
-
点击保存更改。
步骤 6：测试配置
1. 测试机器人流量（应被优化）
通过代理式机器人用户代理发送请求。在 第一个请求 上，Edge Optimize 在处理和缓存页面时可能会返回一个代理（非优化的）响应。您可以通过响应中的 x-edgeoptimize-proxy: 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 头部。 页面内容和响应时间应保持与启用 Optimize at Edge 之前时完全相同。
3. 如何区分这两种场景
x-edgeoptimize-request-idx-edgeoptimize-fo1）也可以在 LLM Optimizer UI 中查看流量路由的状态。 导航至客户配置，然后选择 内容传递网络配置 选项卡。
4. 验证日志是否正确流动
运行上述测试请求后，验证是否为 CloudFront 函数和 Lambda@Edge 函数写入了日志。
CloudFront 函数日志 (edgeoptimize-routing)
导航： AWS 控制台 > CloudWatch > 日志组（在 us-east-1 中或配置了您的 CloudFront 分发的区域）
-
查找名为
/aws/cloudfront/function/edgeoptimize-routing的日志组。 -
打开最近的日志流。
-
对于代理式请求，您应能看到如下条目：
Adding origin group for userAgent: chatgpt-userRouting to Edge Optimize origin for userAgent: chatgpt-user
-
对于非代理式请求，您应看到：
Routing to Default origin for userAgent: ...
您还可以在 AWS 控制台 > CloudFront > 函数 > edgeoptimize 路由 中检查 量度 选项卡，查看调用次数和错误率。
Lambda@Edge 日志 (edgeoptimize-origin)
us-east-1。检查距离运行 curl 命令的位置最近的 AWS 区域中的 CloudWatch。导航： AWS 控制台 > CloudWatch > 日志组（确保您位于正确的区域）
-
查找名为
/aws/lambda/us-east-1.edgeoptimize-origin的日志组。 -
打开最近的日志流。
-
对于代理式请求，您应能看到如下条目：
Calling Edge Optimize Origin for agentic requests— 主要路径Calling Default Origin in case of failover for agentic requests— 故障转移路径Failover Triggered for agentic requests— 源站响应故障转移检测
如果日志组不存在，请验证在步骤 4 中正确更新了 IAM 权限。另请检查其他 AWS 附近区域，处理请求的边缘位置可能与您期望的位置不同。
疑难解答
x-edgeoptimize-request-idYOUR_DEFAULT_ORIGIN（步骤 2）。x-edgeoptimize-api-key 标头值（步骤 1）。us-east-1。cache-control: no-store0（步骤 3）。如果最小 TTL 已经很短，这可能不是问题。禁用并重新启用 Optimize at Edge
Lambda@Edge 函数 (edgeoptimize-origin) 与您的 CloudFront 行为的源站请求和源站响应事件相关联。由于它会在每个通过此行为的请求上内联运行——无论是人类还是代理式请求，因此 Lambda@Edge 中断会影响所有实时流量，而不仅仅是代理式请求。如果您检测到 Lambda@Edge 中断，请立即移除函数关联，将正常通信流恢复到您的默认源站。
如何检测 Lambda@Edge 中断
- AWS 服务运行状况仪表板——检查 AWS 服务运行状况仪表板，了解会影响 Amazon CloudFront 或 AWS Lambda 的任何活跃事件。此处报告的全球或区域性中断是确认问题出现在 AWS 基础设施端而不是在您的配置中的最快方法。
- Lambda@Edge 错误——导航到 AWS 控制台 > CloudFront > 监控 > [您的分发]。打开 Lambda@Edge 错误选项卡，检查 执行错误 图形中的执行错误。如果错误很多，Lambda@Edge 可能不可用。
分离 Lambda@Edge 函数
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 行为
-
点击您的行为上的编辑。
-
向下滚动到 函数关联 部分。
-
将以下关联设置为无关联：
table 0-row-2 1-row-2 2-row-2 3-row-2 事件 更改为 查看器请求 无关联 源站请求 无关联 源站响应 无关联 
-
点击保存更改。
-
等待 CloudFront 分发完成部署。状态从 部署 改为上次更改日期，通常几分钟就完成。
部署后，所有流量都会直接路由到您的默认源站。不删除任何配置；可以随时恢复 Lambda 函数及其关联。
重新附加 Lambda@Edge 函数
导航： AWS 控制台 > CloudFront > 分发 > [您的分发] > 行为
-
点击您的行为上的编辑。
-
向下滚动到 函数关联 部分。
-
恢复关联：
table 0-row-2 1-row-2 2-row-2 3-row-2 事件 设置为 查看器请求 edgeoptimize-routing（CloudFront 函数）源站请求 步骤 4 中带版本的 Lambda ARN 源站响应 步骤 4 中带版本的 Lambda ARN 使用您在步骤 4（发布版本）中记下的带版本的函数 ARN。
-
点击保存更改。
-
等待分发完成部署，然后验证代理式请求是否如步骤 6 中所述返回
x-edgeoptimize-request-id标头。
要进一步了解Edge优化，包括可用的机会、自动优化工作流和常见问题，请返回Edge优化概述。