[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-27。"],[],[],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."]]