하나의 무효화 요청에서 host, path, tags를 조합할 수 있습니다. 불리언 AND로 취급됩니다.
여러 캐시 태그가 지정된 경우 불리언 OR로 취급됩니다. 예를 들어 --tags="status=404,origin=staging-origin"을 지정하면 origin=staging-origin 캐시 태그를 사용하는 모든 응답과 마찬가지로 status=404의 캐시 태그를 포함하는 모든 응답이 무효화됩니다.
캐시 태그
캐시 태그(또는 서로게이트 키)를 사용하면 임의 메타데이터를 기준으로 콘텐츠를 무효화할 수 있습니다.
이러한 태그는 다음과 같이 정의됩니다.
쉼표로 구분된 값 목록으로 지정된 태그를 사용해서 원본 응답에서 Cache-Tag HTTP 헤더 설정
응답의 HTTP 상태 코드를 기반으로 하는 기본 제공 태그, Content-Type HTTP 응답 헤더의 MIME 유형, 응답을 가져온 원본의 이름
단일 무효화 요청에 여러 태그가 지정된 경우 불리언 OR로 취급됩니다.
다음 예시를 참조하세요.
다음과 같은 캐시된 객체가 있습니다.
status=200, content-type=video/mp4 태그를 포함하는 캐시된 객체 #1
status=404, content-type=text/plain 태그를 포함하는 캐시된 객체 #2
status=200, content-type=application/x-mpegurl 태그를 포함하는 캐시된 객체 #3
tags="status=200,content-type=text/plain"로 객체를 무효화하는 요청을 실행합니다.
결과: 캐시된 객체 3개 모두 동시에 무효화됩니다. 이는 알 수 없는 상태일 수 있는 모든 가능한 태그 조합을 지정할 필요가 없도록 방지하기 위한 것입니다.
참고:
기본 캐시 태그는 기존 헤더(예: 상태 줄 또는 Content-Type) 또는 내부 구성 세부정보를 반영하기 때문에 클라이언트 대상 응답에 포함되지 않습니다.
Cache-Tag HTTP 응답 헤더에서 원점에서 전송된 캐시 태그는 클라이언트로 전송됩니다. 이러한 태그가 클라이언트에 전송되지 않도록 방지하려면 routeRule에서 responseHeadersToRemove 기능을 사용하여 Cache-Tag 헤더를 삭제합니다. 예시는 커스텀 헤더 문서를 참조하세요.
기본 제공 태그
응답에는 상태 코드, MIME 유형, 콘텐츠를 가져온 원점에 따라 콘텐츠 무효화를 지원하기 위해 다음 캐시 태그가 자동으로 적용됩니다. 원본 응답에서 이러한 태그를 지정할 필요가 없습니다.
태그
세부정보
status=HTTP_STATUS_CODE
status 캐시 태그는 캐시된 응답의 반환된 HTTP 상태 코드를 기반으로 설정됩니다.
예를 들어 무효화 요청에서 status=404를 지정하여 모든 캐시된 HTTP 404 응답을 무효화할 수 있습니다.
예를 들어 HLS 재생목록의 MIME 유형은 application/x-mpegURL 또는 vnd.apple.mpegURL입니다.
이렇게 하면 특정 유형의 콘텐츠를 무효화할 수 있습니다.
origin=ORIGIN_NAME
origin 캐시 태그는 콘텐츠를 가져온 원본의 이름을 기반으로 설정됩니다.
origin 값은 .routing.routeRules[].origin의 값을 참조하며, 잘못 구성되었거나 잠재적으로 올바르지 않게 작동하는 원본 서버의 콘텐츠를 무효화할 수 있게 해줍니다.
캐시 태그 제한사항
캐시 태그에는 다음과 같은 제한사항이 있습니다.
태그당 120바이트를 초과하지 않아야 합니다.
캐시된 객체당 총 태그 이름이 4KiB (4,096바이트)를 초과하지 않아야 합니다.
Media CDN에서 추가된 기본 태그를 포함하지 않고 객체당 태그 50개를 초과하지 않아야 합니다.
HTTP RFC 7230의 섹션 3.2.6에 정의된 대로 유효한 HTTP 토큰 이름이어야 합니다.
기본 제공되는 status=, origin=, content-type= 프리픽스를 포함하지 않아야 합니다(무시됨).
이러한 제한사항을 준수하거나 요구사항을 충족하지 않는 태그는 무시됩니다. 응답 헤더가 너무 큰 경우와 같은 일부 경우에는 응답이 실패하고 캐시되지 않습니다.
권한
networkservices.EdgeCacheServices.invalidateCache 권한은 invalidateCache API에 대한 액세스를 제어합니다.
이 권한은 networkservices.edgeCacheAdmin 및 networkservices.edgeCacheUser Identity and Access Management 역할에 포함되어 있습니다.
예시
다음 예시는 Media CDN 서비스의 캐시된 응답을 무효화하는 방법을 보여줍니다.
단일 무효화 요청에서 host, path, tags 필드를 조합하여 특정 콘텐츠 집합을 무효화할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Invalidate cached content\n\nCache invalidation, sometimes called *cache purging*, is the process of\ndeclaring cached content to be invalid. This causes the entry to be\nremoved from the cache and then refilled from the origin server the next time\nthat the content is requested.\n\nMedia CDN supports multiple ways of selecting content to be\ninvalidated, as follows:\n\n- Host and URL path\n- URL prefix (wildcard)\n- Cache tags, including built-in tags for `status`, `origin`, and `content-type`\n\nYou can combine these invalidation parameters to target specific cached\nresponses and minimize origin load on the subsequent cache fill.\n\nSupported invalidation syntax\n-----------------------------\n\nThe supported invalidation syntax is as follows:\n\nNotes:\n\n- Up to 10 cache tags can be specified in a single invalidation request.\n- You can combine `host`, `path`, and `tags` in a single invalidation request. They are treated as a boolean `AND`.\n- When multiple cache tags are specified, they are treated as a boolean `OR`. For example, if you specify `--tags=\"status=404,origin=staging-origin\"`, *all* responses with a cache tag of `status=404` are invalidated, as are *all* responses with a cache tag of `origin=staging-origin`.\n\nCache tags\n----------\n\nCache tags (or *surrogate keys*) let you invalidate content based on\narbitrary metadata.\n| **Note:** Cache tags are different from [cache\n| keys](/media-cdn/docs/caching#cache-keys).\n\nThese tags are defined by the following:\n\n- Setting the `Cache-Tag` HTTP header in an origin response, with tags specified as a comma-separated list of values.\n- Built-in tags based on the HTTP status code of the response, the MIME type from the `Content-Type` HTTP response header, or the name of the origin that the response was fetched from.\n\nWhen multiple tags are specified in a single invalidation request, they are\ntreated as a boolean `OR`.\n\nConsider the following example:\n\n- You have the following cached objects:\n\n - Cached object #1 with tags `status=200`, `content-type=video/mp4`\n - Cached object #2 with tags `status=404`, `content-type=text/plain`\n - Cached object #3 with tags `status=200`, `content-type=application/x-mpegurl`\n- You issue a request to invalidate objects with\n `tags=\"status=200,content-type=text/plain\"`\n\n- Outcome: All three cached objects are invalidated at the same time. This is to\n prevent having to specify all possible tag combinations, some of which might\n be unknown.\n\nNotes:\n\n- The default cache tags are *not* included in the client-facing response because they reflect either existing headers (such as the status line or Content-Type) or internal configuration details.\n- Cache tags sent by the origin in the `Cache-Tag` HTTP response header are sent to the client. If you want to prevent these from being sent to the client, use the `responseHeadersToRemove` feature on a `routeRule` to remove the `Cache-Tag` header. For examples, see the [custom headers](/media-cdn/docs/custom-headers#set-custom-headers) documentation.\n\n### Built-in tags\n\nResponses automatically have the following cache tags applied to support\ninvalidating content based on status code, MIME type, or the origin that the\ncontent was fetched from. You don't need to specify these tags in your origin\nresponses.\n\n### Cache tag limitations\n\nCache tags have the following restrictions:\n\n- Must not exceed 120 bytes per tag\n- Must not exceed 4 KiB (4096 bytes) of total tag names per cached object\n- Must not exceed 50 tags per object, not including default tags added by Media CDN\n- Must be a valid HTTP token name, as defined in Section 3.2.6 of HTTP RFC 7230\n- Must not include the built-in `status=`, `origin=`, or `content-type=` prefixes (which are ignored).\n\nTags that do not fall within these limits or meet these requirements are\nignored. In some cases (such as when the response headers are too large),\nthe response fails and isn't cached.\n\nPermissions\n-----------\n\nThe `networkservices.EdgeCacheServices.invalidateCache`\npermission controls access to the [`invalidateCache` API](/media-cdn/docs/reference/rest/v1/projects.locations.edgeCacheServices/invalidateCache).\nThis permission is included in the `networkservices.edgeCacheAdmin` and\n`networkservices.edgeCacheUser` Identity and Access Management roles.\n\nExamples\n--------\n\nThe following examples show how to invalidate cached responses for a\nMedia CDN service.\n\nYou can combine the `host`, `path`, and `tags`\nfields in a single invalidation request to invalidate a specific set of content.\n\n### Invalidate by host\n\n### Console\n\n1. In the Google Cloud console, go to the **Media CDN** page.\n\n [Go to Media CDN](https://console.cloud.google.com/net-services/media-cdn)\n2. Click the **Services** tab.\n3. Click a service.\n4. Click the **Cache invalidation** tab.\n5. To invalidate the cache by host, for **Host** , specify a hostname unless you want to invalidate the path for all hostnames. The hostname can't include `*`.\n6. Click **Invalidate** and then click **Confirm** to indicate that you want Media CDN to invalidate the content matching the host.\n\n### gcloud\n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --host=HOST\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e with the name of the Edge Cache service.\n- \u003cvar translate=\"no\"\u003eHOST\u003c/var\u003e with the complete hostname of the cache entry to be invalidated.\n\nFor example: \n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --host=\"media.example.com\"\n```\n\nInvalidating all content associated with a host can be risky and impact\nperformance. Consider reducing the invalidation scope by providing a specific\npath or relevant cache tags.\n\n### Invalidate by path\n\n### Console\n\n1. In the Google Cloud console, go to the **Media CDN** page.\n\n [Go to Media CDN](https://console.cloud.google.com/net-services/media-cdn)\n2. Click the **Services** tab.\n3. Click a service.\n4. Click the **Cache invalidation** tab.\n5. To invalidate the cache by path, for **Path** , specify the path and the filename---for example,`/videos/funny.mp4` or `/segments/e94a6b1f731/*`.\n6. Click **Invalidate**.\n\n### gcloud\n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --path=PREFIX\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e with the name of the Edge Cache service.\n- \u003cvar translate=\"no\"\u003eHOST\u003c/var\u003e with the hostname of the cache entries to be invalidated. To match on any hostname, omit the host flag.\n- \u003cvar translate=\"no\"\u003ePREFIX\u003c/var\u003e with a path prefix ending in '\\*' that matches cache entries to be invalidated.\n\nFor example: \n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --path=\"/segments/e94a6b1f731/*\"\n```\n\nYou can also invalidate an exact path by omitting the trailing `*`\ncharacter. Passing `--path=\"/videos/funny.mp4\"` invalidates the\ncached response (if any) matching that path.\n\n### Invalidate by cache tag\n\n**Note:** Use host, path, and tags together to reduce the volume of cached content invalidated at the same time. Invalidated responses are re-fetched from the origin in full, and invalidating too much content at the same time can result in increased load on your origin server. \n\n### Console\n\n1. In the Google Cloud console, go to the **Media CDN** page.\n\n [Go to Media CDN](https://console.cloud.google.com/net-services/media-cdn)\n2. Click the **Services** tab.\n3. Click a service.\n4. Click the **Cache invalidation** tab.\n5. To validate the cache by tags, for **Cache tags**, specify one or more tags to invalidate the cache. Use spaces or commas to separate tags. You can add a maximum of 10 cache tags for invalidation.\n6. Click **Invalidate**.\n\n### gcloud\n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --tags=TAGS\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e with the name of the Edge Cache service.\n- \u003cvar translate=\"no\"\u003eTAGS\u003c/var\u003e with a comma-separated list of tags.\n\nFor example: \n\n```\ngcloud edge-cache services invalidate-cache SERVICE_NAME \\\n --tags=\"status=404,content-type=text/plain\"\n```\n\nInvalidation latency\n--------------------\n\nCache invalidation across Media CDN's thousands of locations\ntypically completes within one minute globally.\n\nIn some cases, invalidation can take longer, depending on system load,\nconnectivity, and the volume of content being invalidated.\n\nLogging\n-------\n\nIf audit logs are enabled, invalidation calls are logged to Cloud Logging.\n\nLimitations\n-----------\n\nInvalidations are rate-limited. If you exceed the [invalidations rate limit](/media-cdn/quotas#api-rate-limits),\nyou get an HTTP `429` error message with the status `RESOURCE_EXHAUSTED`.\n\nAn invalidation can be of any size. For example, invalidating\n`/images/my-image.png` counts as one invalidation. Invalidating `/images/*` also\ncounts as one invalidation."]]
