[[["易于理解","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-13。"],[[["\u003cp\u003eExternal backends, or custom origins, allow Cloud CDN to deliver content hosted outside of Google Cloud, whether it's on-premises or in another cloud environment, using Google's high-performance edge caching infrastructure.\u003c/p\u003e\n"],["\u003cp\u003eInternet network endpoint groups (NEGs) are used to specify these external backends, and they can be configured using either a fully qualified domain name (FQDN) or a publicly accessible IP address.\u003c/p\u003e\n"],["\u003cp\u003eCloud CDN, in conjunction with an external Application Load Balancer, supports various backend types, including instance groups, zonal NEGs, serverless NEGs, internet NEGs for external backends, and buckets in Cloud Storage.\u003c/p\u003e\n"],["\u003cp\u003eWhen deploying a hybrid or multi-cloud architecture, Cloud CDN can route requests to external backends based on the request URL, such as directing video traffic to an external backend while sourcing images from within Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003eWhen using an external backend, the \u003ccode\u003eHost\u003c/code\u003e header in HTTP requests must be configured in the backend service if the external backend requires a specific \u003ccode\u003eHost\u003c/code\u003e value.\u003c/p\u003e\n"]]],[],null,["# External backends specified by using internet NEGs\n\nUse external backends (also called *custom origins* ) for Cloud CDN\n(Content Delivery Network) when content is hosted on-premises or in another\ncloud, and you want to deliver the content over Google's [high\nperformance](https://itm.cloud.com/google-reports/),\ndistributed edge caching infrastructure.\n\nTerminology\n-----------\n\nThe following terms are sometimes used interchangeably because they have\nthe same or similar meanings:\n\n- **external backend:** A backend that resides outside of Google Cloud and is reachable across the internet. The endpoint in an internet NEG.\n- **internet network endpoint group (NEG):** The Google Cloud API resource that you use to specify an external backend.\n- **external endpoint:** Same as an *external backend*.\n\nTo maintain consistency with the [load balancing\ndocumentation](/load-balancing/docs/https/setting-up-https-external-backend-internet-neg),\nthis document uses the term *external backend* except when referring to the\ninternet NEG API resource.\n\nSupported backend types for Cloud CDN\n-------------------------------------\n\nCloud CDN works with an [external Application Load Balancer](/load-balancing/docs/https)\nto deliver content to your users. The external Application Load Balancer provides the frontend\nIP addresses and ports that receive requests. Cloud CDN content can\nbe sourced from various types of backends:\n\n- [Instance groups](/compute/docs/instance-groups)\n- [Zonal network endpoint groups\n (NEGs)](/load-balancing/docs/negs/zonal-neg-concepts)\n- [Serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts): One or more [App Engine](/appengine/docs), [Cloud Run](/run/docs), or [Cloud Run functions](/functions/docs) services\n- [Internet NEGs](/load-balancing/docs/negs/internet-neg-concepts) for external backends\n- Buckets in [Cloud Storage](/storage/docs)\n\nExternal backends can be hosted within an on-premises infrastructure or origins\nprovided by third-party providers. The following sections discuss external\nbackends in more detail.\n\nHybrid and multi-cloud architectures\n------------------------------------\n\nAs you move your services to Google Cloud, you might need to do so in\nphases. Sometimes certain content can't immediately be moved to a cloud\nenvironment and might need to stay on-premises. In other cases, the content\nmight be hosted in another cloud. Cloud CDN support\nfor external backends lets you use Google's\n[globally distributed edge caching infrastructure](/cdn/docs/locations) for such\ncontent.\n[](/static/load-balancing/images/cdn-hybrid-multicloud.svg) Hybrid and multi-cloud architecture\n\nIn the diagram, `images` content resides in Google Cloud, while `video`\nresides in a Tokyo data center, which could be on-premises or in another cloud.\nWith external backends, origins in the Tokyo data center can be\nthe backend source of the `video` content with Cloud CDN and the\nexternal Application Load Balancer delivering the content to users.\n\nUsing [URL maps](/load-balancing/docs/url-map-concepts), this deployment can\ndirect origin pull requests for video traffic to the external backend in Tokyo.\nThis mapping is determined based on request URL: `/video`.\n\nFor images (determined based on request URL: `/images`), content is sourced\nfrom Google Cloud and is delivered by the Cloud CDN edge\ninfrastructure.\n| **Note:** Cloud CDN supports fetching content from a single external backend for a service. It does not provide load balancing among multiple external backends for a service, nor does it load balance between an external backend and a Google Cloud backend.\n\nSpecifying an external backend\n------------------------------\n\nSimilar to configuring Cloud CDN with your endpoints deployed in\nGoogle Cloud, you can use the [network endpoint groups (NEGs)\nAPI](/compute/docs/reference/rest/v1/networkEndpointGroups) to add your\nserver as the external backend for Cloud CDN.\n\nTo specify the external backend, use an internet NEG. An internet NEG\nhas one of the endpoint types shown in the following table.\n\nThe best practice is to create the internet NEG with the `INTERNET_FQDN_PORT`\nendpoint type and an FQDN value as an origin hostname value. This insulates the\nCloud CDN configuration from IP address changes in the origin\ninfrastructure. Network endpoints that are defined by using FQDNs are resolved\nthrough public DNS. Make sure that the configured FQDN is resolvable through\n[Google Public DNS](https://developers.google.com/speed/public-dns/).\n\nAfter you create the internet NEG, the type cannot be changed between\n`INTERNET_FQDN_PORT` and `INTERNET_IP_PORT`. You need to create a new internet\nNEG and change your backend service to use the new internet NEG.\n\nWhen using an external backend that expects a particular value for the HTTP\nrequest's `Host` header, you must configure the backend service to set the\n`Host` header to that expected value. If you don't configure a user-defined\nrequest header, a backend service preserves the `Host` header that the client\nused to connect to the Google Cloud external Application Load Balancer. For general\ninformation about custom headers, see\n[Create custom headers in backend services](/load-balancing/docs/custom-headers).\nFor a specific example, see [Setting up Cloud CDN with an external\nbackend](/cdn/docs/setting-up-cdn-with-ex-backend-internet-neg).\n\nUsing external backends and Google Cloud-based origins\n------------------------------------------------------\n\nThe following figure shows an internet NEG used to deploy an external backend\nwith an external Application Load Balancer and Cloud CDN.\n[](/static/load-balancing/images/cdn-custom-origins-negs.svg) Cloud CDN with external backends\n\nWhat's next\n-----------\n\n- To set up an external backend, see [Set up an external backend with an internet NEG](/cdn/docs/set-up-external-backend-internet-neg).\n- To learn about what content is cached, see [Caching overview](/cdn/docs/caching).\n- To resolve issues, see [Troubleshooting external backend and internet NEG\n issues](/load-balancing/docs/https/troubleshooting-ext-https-lbs#external-backends-internet-neg)."]]
