설명서LLM Optimizer

CloudFront(BYOCDN)

마지막 업데이트: 2026년 4월 8일

이 구성은 에이전틱 트래픽(AI 봇 및 LLM 사용자 에이전트의 요청)을 Edge Optimize 백엔드 서비스(live.edgeoptimize.net)로 라우팅합니다. 사람 방문자와 SEO 봇은 기존과 동일하게 사용자의 원본 서버에서 계속 제공됩니다. 구성을 테스트하려면 설정이 완료된 후 응답에서 헤더 x-edgeoptimize-request-id를 찾습니다.

사전 요구 사항

CloudFront 구성을 설정하기 전에 다음이 있는지 확인하십시오.

  • 웹 사이트를 제공하는 기존 CloudFront 배포
  • Lambda 함수, IAM 역할, CloudFront 배포 및 캐시 정책을 생성할 수 있는 AWS IAM 권한
  • LLM Optimizer 온보딩 프로세스 완료
  • LLM Optimizer로 CDN 로그 전달 완료
  • LLM Optimizer UI에서 검색한 Edge Optimize API 키
  • (선택 사항) 스테이징 라우팅을 테스트하려면 선택 사항: 이 페이지의 끝에 있는 스테이징 호스트 이름에서 라우팅 테스트​를 참조하십시오.

프로덕션 Edge 최적화 API 키를 검색하는 단계:

  1. LLM Optimizer에서 고객 구성​을 열고 CDN 구성 탭을 선택합니다.

    고객 구성으로 이동

  2. AI 에이전트에 최적화 배포 섹션을 찾습니다. 최적화 엔진 활성화 확인란을 선택합니다.

    AI 에이전트에 최적화 배포 — 보류 중

  3. 확인 대화 상자에서 활성화​를 선택합니다.

    최적화 엔진 확인 대화 상자 활성화

  4. 세부 정보 보기​를 선택합니다. 최적화 배포 세부 정보 대화 상자에서 프로덕션 API 키​을(를) 복사합니다(필드 옆 사용).

    배포 최적화 세부 정보의 프로덕션 API 키

    note
    NOTE
    대화 상자에서 설정이 완료되지 않았음을 보여줄 수 있습니다. 이는 라우팅을 확인할 때까지 발생합니다. IT 또는 CDN 팀이 구성을 완료할 수 있도록 API 키를 복사할 수 있습니다.

또한 위 단계에 대한 도움이 필요한 경우 Adobe 계정 팀 또는 llmo-at-edge@adobe.com에 문의하십시오.

1단계: Edge 최적화 원본 만들기

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 원본 탭

  1. 원본 만들기​를 클릭합니다.

  2. 원본을 다음과 같이 구성합니다.

    • 원본 도메인: live.edgeoptimize.net
    • 이름: EdgeOptimize_Origin

  3. 다른 모든 필드는 기본값으로 둡니다.

  4. 사용자 정의 헤더 추가:

    table 0-row-2 1-row-2 2-row-2
    헤더 값
    x-edgeoptimize-api-key API 키
    x-forwarded-host www.example.com

    www.example.com을 실제 웹 사이트 도메인으로 바꾸고 Your API key를 Adobe 담당자가 제공한 Edge Optimize API 키로 바꿉니다.

  5. 원본 만들기​를 클릭합니다.

Cloudfront 원본 만들기

2단계: 뷰어 요청 함수 만들기

탐색: AWS Console > CloudFront > 함수

  1. 함수 만들기​를 클릭합니다.

  2. 다음을 구성하십시오.

    • 이름: edgeoptimize-routing
    • 런타임: cloudfront-js-2.0

  3. 기본 코드를 viewer-request.js의 코드로 바꿉니다.

    게시하기 전에 코드에서 다음 값을 사용자 정의합니다.

    • YOUR_DEFAULT_ORIGIN — 기존 기본 원본 이름으로 대체합니다(CloudFront > 배포 > [배포] > 원본 탭에서 확인).
    • TARGETED_PATHS — null을 모든 HTML 페이지를 타깃팅하도록 설정하거나 특정 경로의 배열(예: ['/', '/products', '/about'])로 설정합니다.

  4. 변경 내용 저장 > 함수 게시​를 클릭합니다.

Cloudfront 함수 만들기

3단계: 캐시 정책 구성

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

현재 동작에 연결된 캐시 정책을 확인합니다. 동작에서 편집​을 클릭하고 캐시 키 및 원본 요청 섹션을 보고 시나리오를 확인하십시오.

  • 시나리오 A(기존): 기존 캐시 설정​이라고 레이블이 지정된 라디오 버튼이 표시됩니다. 정책 이름 드롭다운은 없으며, 대신 인라인 TTL 및 헤더 설정이 표시됩니다.
  • 시나리오 B(사용자 정의 정책): 사용자 또는 팀이 만든 정책 이름(AWS 제공 정책이 아님)으로 선택한 캐시 정책​이 표시됩니다.
  • 시나리오 C(관리 정책): CachingOptimized, CachingDisabled 또는 CachingOptimizedForUncompressedObjects와 같이 AWS에서 제공한 이름으로 선택한 캐시 정책​이 표시되며, 해당 정책은 편집할 수 없습니다.

시나리오 A: 기존 캐시 설정

동작이 레거시 캐시 설정을 사용하는 경우:

  1. 캐시 키 및 원본 요청​을 보면 기존 캐시 설정​이 선택되어 있습니다.

  2. 헤더 허용 목록에 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.

    • 드롭다운에서 다음 헤더 포함​을 선택합니다.
    • x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.
      Cloudfront 캐시 레거시

    헤더 드롭다운에서 이미 모두​를 선택한 경우 모든 헤더가 원본으로 자동 전달되므로 이 단계를 건너뜁니다.

  3. 오브젝트 캐싱 설정을 확인합니다.

    • 사용자 지정​으로 설정하는 경우 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.
    • 원본 캐시 헤더 사용​으로 설정된 경우 변경할 필요가 없습니다.

  4. 변경 내용 저장​을 클릭합니다.

시나리오 B: 사용자 정의 캐시 정책을 사용하는 비레거시

동작이 이미 사용자 정의 캐시 정책(AWS 관리 정책이 아닌 사용자가 만든 정책)을 사용하는 경우:

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 기존 정책을 클릭합니다.

  2. 편집​을 클릭합니다.

  3. 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.
    캐시 정책 TTL 설정

  4. 캐시 키 설정 > 헤더​에서 기존 포함과 함께 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.
    캐시 정책 헤더

  5. 변경 내용 저장​을 클릭합니다.

시나리오 C: 관리(AWS) 캐시 정책이 있는 비레거시

동작이 AWS 관리 캐시 정책(예: CachingOptimized)을 사용하는 경우 편집할 수 없습니다. 따라서 기존 관리 정책 설정을 복제하고 상위에 Edge Optimize 헤더를 추가하는 새 사용자 정의 캐시 정책을 만들어야 합니다.

1부: 현재 관리되는 캐시 정책 설정을 기록

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 현재 동작에 연결된 관리 캐시 정책을 찾아 클릭합니다(예: CachingOptimized).

  2. 기존 설정을 모두 기록합니다.

    • 최소 TTL, 최대 TTL, 기본 TTL
    • 캐시 키에 포함된 헤더
    • 캐시 키에 포함된 쿠키
    • 캐시 키에 포함된 쿼리 문자열
    • 압축 지원(Gzip, Brotli)

2부: 동일한 설정 + Edge Optimize 구성을 사용하여 새 사용자 정의 캐시 정책 만들기

탐색: AWS Console > CloudFront > 정책 > 캐시

  1. 캐시 정책 만들기​를 클릭합니다.

  2. 이름: edgeoptimize-cache

    캐시 정책 이름

  3. 1부에 언급된 모든 설정을 다음과 같이 수정하여 복제합니다.

    • 최소 TTL​을 0으로 설정하는 것이 좋습니다. 현재 최소 TTL이 이미 매우 짧은 경우 변경할 필요가 없습니다.

    캐시 정책 TTL 설정

    • 캐시 키 설정 > 헤더​에서 관리 정책에 있는 모든 내용을 포함하고 x-edgeoptimize-config 및 x-edgeoptimize-url을 추가합니다.

    캐시 정책 헤더

  4. 만들기​를 클릭합니다.

  5. 동작으로 돌아가서 새로 만든 정책을 연결합니다.

    탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

    1. 동작을 편집합니다.
    2. 캐시 키 및 원본 요청​에서 캐시 정책​을 선택합니다.
    3. 드롭다운에서 edgeoptimize-cache를 선택합니다.
    4. 변경 내용 저장​을 클릭합니다.

4단계: Lambda@Edge 함수 만들기(원본 요청 및 응답)

IMPORTANT
Lambda@Edge 함수​ 는 us-east-1(버지니아 북부) 지역 ​에서 만들어야 합니다. 이는 AWS 요구 사항입니다. 함수를 us-east-1에서 만들더라도 AWS가 이 함수를 전 세계의 모든 CloudFront 엣지 위치에 자동 복제하므로 뷰어에 가장 가까운 엣지 로케이션에서 함수가 실행됩니다. 계속하기 전에 본인이 AWS Console에서 us-east-1 지역에 있는지 확인하십시오.

Lambda 함수 만들기

탐색: AWS Console > Lambda

  1. 함수 만들기​를 클릭합니다.

  2. 처음부터 작성​을 선택합니다.

  3. 다음을 구성하십시오.

    • 함수 이름: edgeoptimize-origin
    • 다른 모든 필드는 기본값으로 둡니다.

  4. 함수 만들기​를 클릭합니다.

  5. 코드 편집기에서 기본 코드를 origin-request-response.js의 코드로 바꿉니다.

  6. 코드를 저장하려면 배포​를 클릭합니다.

  7. 구성 > 권한(예: edgeoptimize-origin-role-xxxxx)에 표시된 실행 역할 이름​을 참고하십시오. 다음 단계에서 이 작업이 필요합니다.

실행 역할의 신뢰 정책 업데이트

자동 생성된 역할은 lambda.amazonaws.com만 신뢰합니다. Lambda@Edge의 경우 edgelambda.amazonaws.com도 추가해야 합니다.

탐색: AWS Console > IAM > 역할 > [이전 단계의 역할] > 신뢰 관계 탭

  1. 신뢰 정책 편집​을 클릭합니다.

  2. 정책을 trust-policy.json의 내용으로 바꿉니다.

  3. 정책 업데이트​를 클릭합니다.

WARNING
Lambda@Edge의 edgelambda.amazonaws.com 서비스 주체는 필수​입니다. 필수가 아닌 경우 CloudFront가 엣지 로케이션에서 함수를 호출할 수 없습니다.

CloudWatch 로그 권한 정책 수정

자동 생성된 역할에는 Lambda@Edge에 대한 잘못된 지역 및 로그 그룹 이름이 있는 일반 Lambda에 대해 구성된 AWSLambdaBasicExecutionRole 정책이 있습니다. 따라서 이 정책을 업데이트해야 합니다.

탐색: AWS Console > IAM > 역할 > [내 역할] > 권한 탭 > 연결된 정책 이름(예: AWSLambdaBasicExecutionRole-xxxx) 클릭

  1. 편집​을 클릭합니다.

  2. 정책을 cloudwatch-policy.json의 내용으로 바꿉니다.

    JSON에서 ACCOUNT_ID를 실제 AWS 계정 ID(AWS 콘솔의 우측 상단에서 확인)로 바꾸고, FUNCTION_NAME을 Lambda 함수 이름(예: edgeoptimize-origin)으로 바꿉니다.

  3. 변경 내용 저장​을 클릭합니다.

WARNING
ARN의 지역은 *이어야 합니다. Lambda@Edge는 뷰어에 가장 가까운 엣지 위치에서 실행되므로 로그가 엣지 위치의 지역(예: ap-south-1, eu-west-1)에 있는 CloudWatch에 기록되며 지역이 반드시 us-east-1일 필요는 없습니다. 로그 그룹은 지역 접두사가 있는 이름 /aws/lambda/us-east-1.FUNCTION_NAME을(를) 사용합니다. 여기서 us-east-1은 항상 함수의 홈 지역입니다.

버전 게시

  1. 함수 페이지에서 작업(오른쪽 상단) > 새 버전 게시​를 클릭합니다.

  2. 설명을 추가합니다.

  3. 게시​를 클릭합니다.
    Lambda 게시

  4. 함수 ARN​을 복사하거나 기록하십시오. 다음 단계에서 이 정보가 필요합니다.
    Lambda ARN

5단계: 함수 및 캐시 정책을 동작과 연결

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작을 편집합니다.

  2. 3단계(시나리오 C)에서 새 캐시 정책을 만든 경우 캐시 정책​을 edgeoptimize-cache로 설정합니다.
    캐시 정책

  3. 함수 연결​에서 다음을 구성합니다.

    • 뷰어 요청: edgeoptimize-routing
    • 원본 요청: 4단계의 버전이 지정된 함수 ARN(버전 게시)
    • 원본 응답: 4단계의 버전이 지정된 함수 ARN(버전 게시)

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

방화벽 규칙을 통해 Edge에서 최적화 허용(선택 사항)

CDN에서 WAF 또는 보트 관리자를 사용하는 경우:

  • Edge 서비스에서 최적화 서비스를 통해 원본 콘텐츠를 가져올 수 있도록 WAF 또는 봇 관리자에서 *AdobeEdgeOptimize/1.0* 사용자 에이전트를 최적화합니다.

  • 방화벽에 사용자 에이전트 이외의 추가 확인이 필요한 경우 암호를 생성하고(예: openssl rand -hex 32):

    • 다른 x-edgeoptimize-* 헤더와 함께 라우팅 규칙에 암호가 포함된 x-edgeoptimize-fetcher-key을(를) 추가합니다.
    • x-edgeoptimize-fetcher-key이(가) 같은 암호와 일치하는 요청을 허용하도록 WAF 또는 보트 관리자 규칙을 추가합니다.

  • Edge에서 최적화 는 이 헤더를 있는 그대로 전달합니다. — 전체 키 라이프사이클을 소유합니다.

6단계: 구성 테스트

1. 봇 트래픽 테스트(최적화해야 함)

에이전틱 보트 사용자 에이전트를 사용하여 요청을 보냅니다. 첫 번째 요청​에서 Edge Optimize는 페이지를 처리하고 캐시하는 동안 프록시화된(최적화되지 않은) 응답을 반환할 수 있습니다. 응답의 x-edgeoptimize-proxy: 1 헤더로 이를 식별할 수 있습니다.

에이전틱 사용자 에이전트를 사용하여 AI 봇 요청을 시뮬레이션합니다.

curl -svo /dev/null https://www.example.com/page.html \
  --header "user-agent: chatgpt-user"

성공적인 응답에는 요청이 Edge Optimize를 통해 라우팅되었음을 확인하는 x-edgeoptimize-request-id 헤더가 포함됩니다.

< 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-id
있음 — 고유한 요청 ID가 포함되어 있습니다.
없음
x-edgeoptimize-fo
장애 조치가 발생한 경우에만 표시됩니다(값: 1).
없음

LLM Optimizer UI에서 트래픽 라우팅 상태를 확인할 수도 있습니다. 고객 구성(으)로 이동하고 CDN 구성 탭을 선택합니다.

AI 에이전트에 최적화 배포 — 완료됨

4. 로그 흐름이 올바른지 확인

위의 테스트 요청을 실행한 후 CloudFront 함수와 Lambda@Edge 함수 모두에 대해 로그가 기록되고 있는지 확인합니다.

CloudFront 함수 로그(edgeoptimize-routing)

탐색: AWS Console > CloudWatch > 로그 그룹(us-east-1 또는 CloudFront 배포가 구성된 지역)

  1. 이름이 /aws/cloudfront/function/edgeoptimize-routing인 로그 그룹을 찾습니다.

  2. 최신 로그 스트림을 엽니다.

  3. 에이전틱 요청의 경우 다음과 같은 토픽이 표시됩니다.

    • Adding origin group for userAgent: chatgpt-user
    • Routing to Edge Optimize origin for userAgent: chatgpt-user

  4. 비에이전틱 요청의 경우 다음이 표시됩니다.

    • Routing to Default origin for userAgent: ...

또한 AWS Console > CloudFront > 함수 > edgeoptimize-routing​에서 지표 탭을 확인하여 호출 수 및 오류율을 볼 수 있습니다.

Lambda@Edge 로그(edgeoptimize-origin)

IMPORTANT
Lambda@Edge 로그는 us-east-1가 아닌 요청을 제공한 엣지 위치 지역​의 CloudWatch에 기록됩니다. curl 명령을 실행한 위치와 가장 가까운 AWS 지역에서 CloudWatch를 확인합니다.

탐색: AWS Console > CloudWatch > 로그 그룹(본인이 올바른 지역에 있는지 확인)

  1. 이름이 /aws/lambda/us-east-1.edgeoptimize-origin인 로그 그룹을 찾습니다.

  2. 최신 로그 스트림을 엽니다.

  3. 에이전틱 요청의 경우 다음과 같은 토픽이 표시됩니다.

    • 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-id 없음
원본 그룹이 Edge Optimize로 라우팅되지 않음
YOUR_DEFAULT_ORIGIN이 CloudFront 함수 코드에서 올바르게 대체되었는지 확인합니다(2단계).
에이전틱 요청에 대한 403 오류
API 키가 잘못되었거나 누락됨
Edge Optimize 원본 사용자 지정 헤더에서 x-edgeoptimize-api-key 헤더 값을 확인합니다(1단계).
Lambda@Edge에 대한 CloudWatch 로그를 찾을 수 없음
잘못된 IAM 권한
CloudWatch 로그 권한 정책이 업데이트되었는지 확인합니다(4단계). 참고: Lambda@Edge 로그는 요청을 제공한 엣지 지역에 표시되며 지역이 us-east-1일 필요는 없습니다.
캐시가 cache-control: no-store를 준수하지 않음
최소 TTL이 너무 높을 수 있음
캐시 정책에서 최소 TTL을 0으로 설정합니다(3단계). 최소 TTL이 이미 매우 짧은 경우 TTL이 문제가 아닐 수 있습니다.
설정 후 중단된 일반(비에이전틱) 트래픽
캐시 정책 구성 오류
새 캐시 정책을 만든 경우(시나리오 C) 원래 관리 정책에서 모든 설정을 복제했는지 확인합니다.

Edge에서 Optimize 비활성화 및 다시 재활성화

Lambda@Edge 함수(edgeoptimize-origin)는 CloudFront 동작의 원본 요청 및 원본 응답 이벤트와 연결되어 있습니다. 이 서비스는 사람 및 에이전틱을 막론하고 해당 동작을 통과하는 모든 요청에 인라인으로 실행되기 때문에 Lambda@Edge 작동 중단은 에이전틱 요청뿐만 아니라 모든 실시간 트래픽에 영향을 미칩니다. Lambda@Edge 중단을 감지하면 함수 연결을 즉시 제거하여 일반 트래픽 흐름을 기본 원본으로 복원하십시오.

Lambda@Edge 중단을 감지하는 방법

  • AWS 서비스 상태 대시보드 — AWS 서비스 상태 대시보드에서 Amazon CloudFront 또는 AWS Lambda​에 영향을 주는 활성 인시던트를 확인하십시오. 여기에 보고된 전역 또는 지역 중단은 구성이 아닌 AWS 인프라 측에 문제가 있는지 확인하는 가장 빠른 방법입니다.
  • Lambda@Edge 오류 — AWS Console > CloudFront > 모니터링 > [내 배포]​로 이동합니다. Lambda@Edge 오류 탭을 열고 실행 오류 그래프에서 실행 오류를 확인합니다. 이 값이 높으면 Lambda@Edge가 다운될 수 있습니다.

Lambda@Edge 함수 분리

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작에서 편집​을 클릭합니다.

  2. 함수 연결 섹션까지 아래로 스크롤합니다.

  3. 다음 연결을 연결 없음​으로 설정합니다.

    table 0-row-2 1-row-2 2-row-2 3-row-2
    이벤트 다음으로 변경
    뷰어 요청 연결 없음
    원본 요청 연결 없음
    원본 응답 연결 없음

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

  5. CloudFront 배포가 배포를 완료할 때까지 기다립니다. 배포​에서 마지막 수정 날짜로 상태가 변경되며, 일반적으로 몇 분 이내에 수정됩니다.

배포되면 모든 트래픽이 기본 원본으로 바로 이동합니다. 구성이 삭제되지 않으므로 Lambda 함수와 해당 연결은 언제든지 복원할 수 있습니다.

Lambda@Edge 함수 재연결

탐색: AWS Console > CloudFront > 배포 > [내 배포] > 동작

  1. 동작에서 편집​을 클릭합니다.

  2. 함수 연결 섹션까지 아래로 스크롤합니다.

  3. 연결 복원:

    table 0-row-2 1-row-2 2-row-2 3-row-2
    이벤트 다음으로 설정
    뷰어 요청 edgeoptimize-routing(CloudFront 함수)
    원본 요청 4단계에서 버전이 지정된 Lambda ARN
    원본 응답 4단계에서 버전이 지정된 Lambda ARN

    4단계(버전 게시)에서 기록한 버전이 지정된 함수 ARN​을 사용합니다.

    함수 연결 구성

  4. 변경 내용 저장​을 클릭합니다.

  5. 배포가 배포를 완료할 때까지 기다린 다음 에이전틱 요청이 6단계에서 설명한 대로 x-edgeoptimize-request-id 헤더를 반환하는지 확인합니다.

선택 사항: 스테이징 호스트 이름에서 라우팅을 테스트합니다

프로덕션 라우팅을 활성화하기 전에 더 낮은 환경에서 라우팅을 확인하려는 경우 스테이징 호스트 이름을 구성할 수 있습니다.

요구 사항

  • 스테이징 호스트 이름은 프로덕션과 동일한 등록 가능한 도메인​에 있어야 합니다(예: 프로덕션이 https://www.example.com인 경우 https://staging.example.com).
  • 사이트당 one 스테이징 도메인만. 저장되면 Adobe에 문의하지 않으면 변경할 수 없습니다.

스테이징 API 키 가져오기

  1. 고객 구성​을 열고 CDN 구성​을 선택합니다.
  2. AI 에이전트에 최적화 배포​에서 단계 도메인 추가(또는 스테이징 도메인이 이미 구성된 경우 단계 도메인)를 선택합니다.
  3. https://을(를) 포함한 전체 스테이징 URL을 입력하고 도메인 설정​을(를) 선택하십시오.
  4. 확인 대화 상자에서 스테이징 API 키를 복사합니다.

스테이징 도메인 API 키

스테이징 API 키를 사용하여 스테이징 환경에 동일한 라우팅 규칙을 배포합니다.

스테이징 보트 트래픽 테스트

https://staging.example.com/page.html을 실제 스테이징 URL 및 경로로 바꿉니다. 성공: 응답에 x-edgeoptimize-request-id 헤더가 포함되어 있습니다.

도움이 필요하면 llmo-at-edge@adobe.com에 문의하세요.

curl -svo /dev/null https://staging.example.com/page.html \
  --header "user-agent: chatgpt-user"

사용 가능한 기회, 자동 최적화 워크플로 및 FAQ를 포함하여 Edge에서 최적화에 대해 자세히 알아보려면 Edge에서 최적화 개요로 돌아가십시오.

recommendation-more-help
llm-optimizer-help-main-toc