1먼저 알아둘 것

판정에 쓰는 근거는 두 가지이고, 항상 둘을 함께 봐야 합니다.

2오리진 등록

Tencent Cloud CDN 콘솔에서 가속 도메인을 만들고 오리진을 다음과 같이 지정합니다.

3가장 기본이 되는 확인

같은 URL을 연속으로 두 번 호출합니다. 아래에서 <도메인> 은 가속 도메인입니다.

curl -sD - -o /dev/null http://<도메인>/cache/max-age-60/test.txt | grep -i x-cache-lookup
curl -sD - -o /dev/null http://<도메인>/cache/max-age-60/test.txt | grep -i x-cache-lookup

첫 번째는 Miss, 두 번째는 Hit 이면 캐시가 정상 동작합니다. 이때 오리진 로그에는 요청이 한 건만 남아야 합니다.

# 서버에서 실시간으로 확인
sudo tail -f /var/log/nginx/access.log

4시나리오별 확인 방법

5캐시 키와 stale 응답 확인

앞의 시나리오가 얼마나 오래 캐시하는지를 봤다면, 여기서는 CDN이 캐시를 어떻게 나누는지와 만료된 사본을 계속 내보내도 되는지를 봅니다.

Vary — 같은 URL이 여러 사본으로 갈리는지

요청 헤더를 바꿔가며 호출해야 의미가 있습니다. 두 요청이 서로 다른 캐시 항목으로 잡히면 두 번째도 Miss가 됩니다.

URL=http://<도메인>/cache/vary-lang/test.txt
curl -sD - -o /dev/null -H 'Accept-Language: ko' "$URL" | grep -i x-cache-lookup
curl -sD - -o /dev/null -H 'Accept-Language: en' "$URL" | grep -i x-cache-lookup
curl -sD - -o /dev/null -H 'Accept-Language: ko' "$URL" | grep -i x-cache-lookup

Vary 를 존중한다면 1·2번째는 Miss, 3번째는 Hit입니다. 무시한다면 2번째부터 Hit이 됩니다. /cache/vary-ua/ 는 User-Agent 로 같은 확인을 합니다.

Set-Cookie — 캐시 가능 헤더와 충돌시키기

/cache/set-cookie/test.txt 는 max-age=300 으로 캐시를 허용하면서 동시에 Set-Cookie 를 내보냅니다. 대부분의 CDN은 쿠키가 붙은 응답을 캐시하지 않으므로, 계속 Miss가 나오면 정상입니다. Hit이 난다면 사용자별 쿠키가 다른 사람에게 새어 나갈 수 있다는 뜻이라 반드시 확인해야 합니다.

stale-while-revalidate / stale-if-error

max-age 가 10초라 만료 이후 구간을 금방 관찰할 수 있습니다.

오리진 장애를 실제로 만들어 보기

/api/flaky/N 은 N번째 요청마다 502를 내보내고, 성공 응답에는 max-age=10, stale-if-error=300 을 붙입니다. 실패 응답 자체는 no-store 라 CDN이 502를 캐시하지 않습니다. 따라서 CDN이 stale-if-error 를 존중한다면, 오리진이 502를 내는 동안에도 캐시된 200 응답을 계속 내보내야 합니다.

# 반복 테스트 전에는 카운터를 초기화
curl -s http://<도메인>/api/flaky/reset

URL=http://<도메인>/api/flaky/3
for i in $(seq 1 9); do
  curl -sD - -o /dev/null "$URL" \
    | awk 'NR==1 || tolower($1) ~ /^x-cache-lookup:/ { printf "%s  ", $0 }'
  echo
done

6TTL이 실제로 만료되는지 보기

max-age=60 경로로 확인하는 것이 가장 빠릅니다. Age 헤더가 60에 가까워질수록 만료가 임박한 것입니다.

URL=http://<도메인>/cache/max-age-60/test.txt
for i in $(seq 1 8); do
  curl -sD - -o /dev/null "$URL" \
    | awk 'tolower($1) ~ /^(x-cache-lookup|age):/ { printf "%s ", $0 }'
  echo "  ($(date +%T))"
  sleep 10
done

처음에는 Miss, 이후 Hit이 이어지다가, 60초를 넘긴 시점에 다시 Miss 또는 재검증이 일어나면 TTL이 의도대로 적용된 것입니다.

7캐시를 비우고 다시 확인하기

CDN 콘솔의 Purge(캐시 새로 고침) 로 URL 또는 디렉터리를 비운 뒤 다시 요청하면 첫 요청이 Miss로 돌아옵니다. 콘텐츠 자체를 바꿔서 확인하려면 서버에서 파일을 다시 생성하면 됩니다.

# 서버에서: 테스트 콘텐츠를 새 타임스탬프로 재생성
sudo bash ~/cdn-origin/scripts/generate-files.sh /var/www/origin
sudo chown -R nginx:nginx /var/www/origin

8서버 점검

액세스 로그에는 host=(회원 Host), range=(부분 요청), status= 가 함께 기록되어 CDN 판정과 대조하기 좋습니다.

9도달한 요청 · 나간 응답 보기

웹서버에 실제로 도달한 요청과 오리진이 돌려준 응답을 /inspect.html 에서 볼 수 있습니다. 최근 500건을 메모리에 보관하며, 자동으로 새로고침됩니다.

모든 응답에는 X-Origin-Request-Id 가 붙습니다. 이게 이 기능의 핵심입니다 — CDN을 거쳐 받은 응답을 손에 들고 있을 때, 그 ID로 기록을 찾아보면 오리진까지 온 요청인지 엣지 캐시가 답한 것인지 확실해집니다.

# 가속 도메인으로 두 번 호출하고 요청 ID를 비교한다
curl -sI https://<가속도메인>/cache/max-age-60/test.txt | grep -iE "x-origin-request-id|x-cache-lookup"
curl -sI https://<가속도메인>/cache/max-age-60/test.txt | grep -iE "x-origin-request-id|x-cache-lookup"

# ID가 그대로면 같은 오리진 응답을 캐시해 재사용한 것이고,
# ID가 바뀌었다면 오리진까지 다시 다녀온 것이다.

특정 ID의 기록만 보려면 /inspect.html#<요청ID> 로 열거나, 검색창에 붙여 넣으면 됩니다. API로는 /api/requests?id=<요청ID> 입니다.

/inspect.html 이 2초마다 보내는 자기 조회는 기록에서 빼고 건수만 셉니다 (화면 오른쪽 위 “뷰어 폴링 N건 제외”). 남겨두면 탭을 열어둔 것만으로 버퍼가 자기 폴링으로 가득 차서 정작 보려던 트래픽이 밀려나기 때문입니다. 제외 기준은 경로가 아니라 뷰어가 붙이는 표식이므로, 손으로 curl /api/requests 를 부른 것은 그대로 기록됩니다.

같은 내용이 /var/log/nginx/access.json.log 에 한 줄 JSON으로도 쌓입니다. 화면의 버퍼는 서비스가 재시작되면 비지만, 이 파일은 남습니다.

10오류 응답 읽기

오류 응답은 모두 이 오리진이 직접 만든 페이지로 나갑니다. nginx 기본 페이지는 의도적으로 만든 테스트 응답과 진짜 장애가 글자 하나까지 똑같아서, CDN에 캐시된 오류를 나중에 봤을 때 어느 쪽인지 가릴 수가 없기 때문입니다.

구분은 X-Origin-Intent 헤더 하나로 끝납니다.

마지막 줄이 실무에서 제일 쓸모 있습니다. 502를 받았을 때 X-Origin-Intent 가 아예 없다면 요청이 오리진까지 오지도 못한 것이므로, 오리진 로그를 뒤질 필요 없이 CDN 설정부터 보면 됩니다.

curl -sI https://<가속도메인>/status/404 | grep -i x-origin-intent
# X-Origin-Intent: test-fixture   → 의도된 응답

curl -sI https://<가속도메인>/없는경로 | grep -i x-origin-intent
# X-Origin-Intent: unexpected     → 진짜 404

11막힐 때