[[["容易理解","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-05 (世界標準時間)。"],[[["\u003cp\u003eCache invalidation, or purging, removes content from the Cloud CDN cache before its expiration, forcing the cache to retrieve fresh content from the backend server upon the next request.\u003c/p\u003e\n"],["\u003cp\u003eCloud CDN supports invalidation by path patterns and cache tags, allowing for targeted removal of specific objects or sets of content.\u003c/p\u003e\n"],["\u003cp\u003eInvalidation requests have rate limits: up to 500 per minute for cache tags and one per minute for other matchers, with latency for completion being approximately 10 seconds and one to three minutes, respectively.\u003c/p\u003e\n"],["\u003cp\u003eIt is recommended that invalidation should be used sparingly, such as in exceptional circumstances, and that the backend server should be verified as returning correct content before invalidation is requested.\u003c/p\u003e\n"],["\u003cp\u003eCache invalidation is configured in the frontend project and cache invalidations can only be requested by principals that have the correct IAM roles.\u003c/p\u003e\n"]]],[],null,["# Cache invalidation overview\n\nThis page provides an overview of Cloud CDN cache invalidation.\n\nWhat is cache invalidation?\n---------------------------\n\nAfter an object is cached, it normally remains in the cache until it expires or\nis evicted to make room for new content. You might want to remove an object\nfrom the cache before its normal expiration time. You can force an object\nor set of objects to be ignored by the cache by requesting a cache invalidation.\n\nCache invalidation, sometimes called *cache purging*, is the process of\ndeclaring cached content to be invalid. This process causes the entry to be\nremoved from the cache and then refilled from the backend server the next time\nthat the content is requested.\n\nCloud CDN supports the use of cache tags and invalidation matchers, such as\nhost and URL path, for invalidation requests.\n\nYou can combine these invalidation parameters to target specific cached\nresponses and minimize backend load on the subsequent cache fill.\n\nIt's important to ensure that the backend server is returning the correct\ncontent before you request the cache invalidation. Otherwise, when\nCloud CDN requests the content again, it might cache the incorrect\ncontent.\n\nInvalidations requests are rate limited. You can submit up to 500 invalidation\nrequests per minute. Each invalidation request takes effect in about 10 seconds.\n\nCloud CDN doesn't restrict the number of objects or the total size of\nall invalidated objects for each request.\n\nInvalidation by URLs\n--------------------\n\nEach invalidation request specifies a path pattern that identifies the object\nor set of objects that should be invalidated. The path pattern can be either a\nspecific path, such as `/cat.jpg`, or an entire directory structure, such as\n`/pictures/*`. The following rules apply to path patterns:\n\n- The path pattern must start with `/`.\n- It cannot include `?` or `#`.\n- It must not include an `*` except as the final character following a `/`.\n- If it ends with `/*`, the preceding string is a prefix, and all objects whose paths begin with that prefix are invalidated.\n\nThe path pattern is compared with the path component of the URL, which is\neverything between the hostname and any `?` or `#` that might be present.\n\nIf you have URLs that contain a query string, for example\n`/images.php?image=fred.png`, you cannot selectively invalidate objects that\ndiffer only by query string. For example, if you have two images,\n`/images.php?image=fred.png` and `/images.php?image=barney.png`, you cannot\ninvalidate only `fred.png`. To invalidate all images served by images.php, use\n`/images.php` as the path pattern.\n\nInvalidation for a single host\n------------------------------\n\nCache invalidation invalidates the path for all your hostnames. For\nexample, if you have `example.com` and `example2.com` pointed to the same\nload balancer, and you invalidate `/images/cat.jpg`, both\n`example.com/images/cat.jpg` and `example2.com/images/cat.jpg` are invalidated.\n\nYou can restrict the invalidation to only one of the hosts by specifying the\nhost.\n\nInvalidation by cache tags\n--------------------------\n\nCache tags (or *surrogate keys*) let you invalidate content based on\narbitrary metadata.\n| **Note:** Cache tags are different from [cache keys](/cdn/docs/caching#cache-keys).\n\nThese tags are defined with the `Cache-Tag` HTTP header in a backend\nresponse. Cache tags from the backend in the `Cache-Tag` HTTP response\nheader are sent to the client.\n\nCache tags have the following limits:\n\n- Must not exceed 120 bytes per tag\n- Must not exceed 4 KiBs (4096 bytes) of total tag names per cached object\n- Must not exceed 50 tags per object\n\nIf these tag limits are exceeded, the response isn't cached and this\ndecision is logged as `RESPONSE_CACHE_TAG_INVALID` in\n`LoadBalancerLogEntry.cacheDecision`.\n\nYou can specify up to 10 cache tags per invalidation request. When multiple tags\nare specified in a single invalidation request, they are treated as a logical\n`OR`. Consider an example in which you have the following cached\nobjects:\n\n- Cached object #1 with tags `js`, `2020-12-23`, and `prod`\n- Cached object #2 with tags `css`, `2020-11-30`, and `prod`\n- Cached object #3 with tags `img` `2020-11-30`, and `staging`\n\nWhen you issue a request to invalidate objects that match\n`tags=\"prod,2020-11-30\"`, all three cached objects are invalidated.\nThis approach means that you don't need to know or specify all possible tag\ncombinations when you want to invalidate an object.\n\nIf you specify invalidation matchers along with cache tags, the\ninvalidation request applies only to the tagged objects that match the\ninvalidation matchers. Consider an example with the following cached objects:\n\n- Cached object #1 with URL `https://staging.example.com/img/cat.jpg` and tag `a`\n- Cached object #2 with URL `https://example.com/img/cat.jpg` and tag `a`\n- Cached object #3 with URL `https://staging.example.com/js/cat.js` and tag `a`\n- Cached object #4 with URL `https://staging.example.com/img/logo.jpg` and tag `b`\n\nWhen you issue a request to invalidate objects where the host is\n`staging.example.com`, the path `/img/*`, and the tag `a`, only object #1 is\ninvalidated. Objects #2, #3, and #4 don't match the host, path, or tag,\nrespectively.\n\nInvalidation latency\n--------------------\n\nBecause Cloud CDN is a distributed system, it might report that\nan invalidation has completed even though a small number of caches have not\nyet processed the invalidation request. This situation is rare and\ncorrects itself automatically.\n\nBest practices\n--------------\n\nInvalidate only what you must because invalidating too much might cause a\nspike in requests that the caches were serving to suddenly hit\nyour instances or buckets.\n\nInvalidation is intended for use in exceptional circumstances, not as part of\nyour normal workflow. Invalidations don't affect cached copies in\nweb browser caches or caches operated by third-party internet service providers.\n\nAs an alternative to routine invalidations, you can proactively set appropriate\nexpiration times on responses or use different URLs for different versions\nof your content. For more information about expiration times, see\n[Expiration times and validation requests](/cdn/docs/caching#expiration).\n\nInvalidation with Shared VPC cross-project service referencing\n--------------------------------------------------------------\n\nCache invalidation is configured in the frontend project; that is, the project\nthat has the forwarding rule, target proxy, and URL map of the load balancer.\nSo, when you're using a [global external Application Load Balancer with Shared VPC\ncross-project service referencing](/load-balancing/docs/https#shared-vpc),\nby default, service project administrators don't have the required permissions\nto request cache invalidations.\n\nCache invalidations can be issued only by principals who have the\nIdentity and Access Management (IAM) roles for configuring load balancer resources in the\nfrontend projects---for example, the Compute Network Admin role\n(`roles/compute.networkAdmin`).\n\nService administrators, who control provisioning of the backend services in a\nseparate project, can work with the load balancer administrator of the\nfrontend project to issue cache invalidation for their cross-project services.\nFor URL rewrites, ensure that the invalidation matches the pre-rewrite host and\npath that the client sends.\n\nWhat's next\n-----------\n\n- To learn how to invalidate your Cloud CDN cached content, see\n [Invalidating cached content](/cdn/docs/invalidating-cached-content).\n\n- To learn about which content is cacheable or non-cacheable, see\n [Caching overview](/cdn/docs/caching)."]]
