INTERNET_FQDN_PORT 類型的網路端點健康狀態檢查行為，與與 Cloud Load Balancing 和 Cloud Service Mesh 搭配使用的其他類型網路端點的健康狀態檢查行為不同。雖然大多數其他網路端點類型都使用 Google Cloud的集中式健康狀態檢查系統，但在多雲環境中用於端點的 NEG (INTERNET_FQDN_PORT 和 NON_GCP_PRIVATE_IP_PORT) 則使用 Envoy 的分散式健康狀態檢查機制。
Envoy 支援下列健康狀態檢查通訊協定：
HTTP
HTTPS
HTTP/2
TCP
您可以使用 Compute Engine API 設定健康狀態檢查。
DNS 考量事項
關於 DNS，有兩個不同的考量因素：
代管外部服務資源記錄的 DNS 伺服器。
用於將 Envoy 代理程式設為使用 DNS 進行連線管理的模式。
Cloud DNS 伺服器
您可以建立 Cloud DNS 代管不公開區域，以便在 Google Cloud 專案中代管 DNS 記錄。您也可以使用 Cloud DNS 的其他功能 (例如轉送區域)，從內部部署系統 DNS 伺服器擷取記錄。
Envoy DNS 模式
Envoy DNS 模式 (也稱為「服務探索」) 會指定 Envoy Proxy 如何使用 DNS 記錄來管理輸出連線。Cloud Service Mesh 會將 Envoy 設為使用嚴格 DNS 模式。嚴格 DNS 模式可為所有已解析的端點啟用負載平衡功能。它會遵循健康狀態檢查狀態，並排空連線至不健康或不再使用 DNS 解析的端點。您無法變更這個模式。
[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Cloud Service Mesh with internet network endpoint groups\n========================================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nYou can configure Cloud Service Mesh to use\n[internet network endpoint groups (NEGs)](/load-balancing/docs/negs/internet-neg-concepts)\nof the type `INTERNET_FQDN_PORT`. The external service is represented by its\nfully qualified domain name (FQDN) and port number in the NEG. The NEG can\ncontain only one `FQDN:Port` pair, and the backend service can contain only one\nNEG of this type. The FQDN is resolved by using the underlying\nVirtual Private Cloud (VPC) network's\n[name resolution order](/dns/docs/vpc-name-res-order).\n\nExpand the Cloud Service Mesh service mesh using FQDN backends\n--------------------------------------------------------------\n\nThe Cloud Service Mesh service mesh can route traffic to private services that\nare reachable by using hybrid connectivity, including named on-premises,\nmulti-cloud, and internet services. The remote service is referenced by its FQDN.\n[](/static/service-mesh/docs/images/internet-neg-example-setup.svg) Extending the Cloud Service Mesh service mesh to on-premises or multi-cloud locations using FQDN backends over hybrid connectivity (click to enlarge)\n\nYou can also route traffic to services that are reachable over the public\ninternet.\n[](/static/service-mesh/docs/images/td-internet-service.svg) Extending the Cloud Service Mesh service mesh to an internet service using FQDN backends (click to enlarge)\n\nGoogle Cloud resources and architecture\n---------------------------------------\n\nThis section describes the resources and architecture for configuring\nCloud Service Mesh with an internet NEG.\n\n`INTERNET_FQDN_PORT` network endpoint group\n-------------------------------------------\n\nTo route traffic to an external service referenced by its FQDN, use the global\ninternet NEG of the type `INTERNET_FQDN_PORT`. The NEG contains\nthe FQDN of your service and its port number. Cloud Service Mesh programs the\nFQDN into Envoy proxies by using xDS configuration.\n\nCloud Service Mesh itself does not guarantee name resolution and reachability\nof the remote endpoints. The FQDN must be resolvable by the name resolution\norder of the VPC network to which the Envoy proxies are attached,\nand the resolved endpoints must be reachable from the Envoy proxies.\n\nHealth checks\n-------------\n\nHealth checking behavior for network endpoints of the type `INTERNET_FQDN_PORT`\ndiffers from health checking behavior for other types of network endpoints used\nwith Cloud Load Balancing and Cloud Service Mesh. While most other network\nendpoint types use Google Cloud's centralized health checking system, the\nNEGs used for endpoints in multi-cloud environments (`INTERNET_FQDN_PORT`\nand `NON_GCP_PRIVATE_IP_PORT`) use Envoy's distributed health checking\nmechanism.\n\nEnvoy supports the following protocols for health checking:\n\n- HTTP\n- HTTPS\n- HTTP/2\n- TCP\n\nYou configure health checks by using the Compute Engine APIs.\n\nDNS considerations\n------------------\n\nThere are two distinct considerations regarding DNS:\n\n- The DNS server that hosts the resource records of your external service.\n- The mode with which the Envoy proxy is configured to use DNS for connection management.\n\n### Cloud DNS server\n\nYou can create a Cloud DNS\n[managed private zone](/dns/docs/zones#create-private-zone) to host the DNS\nrecords in your Google Cloud project. You can also use other features of\nCloud DNS, such as\n[forwarding zones](/dns/docs/zones#creating-forwarding-zones), to fetch records\nfrom an on-premises DNS server.\n\n### Envoy DNS mode\n\nEnvoy DNS mode, which is also called *service discovery* , specifies how the Envoy\nproxy uses DNS records for managing outbound connections. Cloud Service Mesh\nconfigures Envoy to use [strict DNS mode](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#strict-dns).\nStrict DNS mode enables load balancing to all resolved endpoints. It honors\nhealth check status and drains connections to endpoints that are unhealthy or\nno longer resolved by using DNS. You cannot change this mode.\n\nFor more information about service discovery, see the Envoy documentation.\n\nConnectivity and routing\n------------------------\n\nIf you are routing traffic to a private service, the following are the\nrequirements for the underlying network connectivity:\n\n- Hybrid connectivity between the VPC network and the on-premises data center or third-party public cloud is established by using Cloud VPN or Cloud Interconnect.\n- VPC firewall rules and routes are correctly configured to establish bi-directional reachability from Envoy to your private service endpoints and, if applicable, to the on-premises DNS server.\n- For successful regional high-availability failover, global dynamic routing must be enabled. For more details, see [dynamic routing mode](/network-connectivity/docs/router/concepts/learned-routes#dynamic-routing-mode-effects-on-learned-routes).\n\nIf you are routing traffic to an external service that is\nreachable on the internet, the following are the requirements:\n\n- The client virtual machine (VM) instances in the VPC network must have an external IP address or Cloud NAT.\n- The [default route](/vpc/docs/routes#routingpacketsinternet) must be present to egress traffic to the internet.\n\nIn both of the preceding cases, traffic uses the VPC network's\nrouting.\n\nSecurity\n--------\n\nFQDN backends are compatible with\n[Cloud Service Mesh's security features](/service-mesh/docs/service-routing/security-overview#securing_service-to-service_communications)\nand APIs. On the outbound connections to your external service, you can\nconfigure FQDN in the SNI header by using\n[client TLS policies](/service-mesh/legacy/load-balancing-apis/set-up-internet-neg#unauth-https).\n\nLimitations and considerations\n------------------------------\n\n- Internet NEGs of the type `INTERNET_IP_PORT` are not supported with Cloud Service Mesh.\n- Envoy version 1.15.0 or later is required with FQDN backends.\n- Use the Google Cloud CLI or REST APIs to configure Cloud Service Mesh. End-to-end configuration using the Google Cloud console is not supported.\n- FQDN backends are only supported with Envoy. Proxyless gRPC is not supported.\n- When you use the NEG type `INTERNET_FQDN_PORT` with Cloud Service Mesh, health\n checks of the remote endpoints are done using Envoy's distributed health\n checking mechanism. Whenever a new remote endpoint is added, all Envoy proxies\n start health checking it independently.\n\n Similarly, when a new Envoy proxy is added to the mesh, it starts checking\n all the remote endpoints. Therefore,\n depending on the number of Envoy proxies and remote endpoints in your\n deployment, the resulting health check mesh might cause significant network\n traffic and an undue load on the remote endpoints. You can choose not to\n configure health checks.\n- Health check status is not visible in the Google Cloud console for FQDN\n backends.\n\n- Health checking that uses the UDP, SSL, and gRPC protocols is not supported.\n\n- The following health check options are not supported:\n\n - HTTP/HTTP2/HTTPS health check\n - `--proxy-header`\n - `--response`\n - TCP health check\n - `--proxy-header`\n - `--request`\n - `--response`\n\nWhat's next\n-----------\n\n- To set up Cloud Service Mesh with internet NEGS, see [Set up external backends](/service-mesh/legacy/load-balancing-apis/set-up-internet-neg).\n- To learn about hybrid connectivity NEGs, see [Cloud Service Mesh with hybrid connectivity NEGs](/service-mesh/docs/service-routing/multi-environment-overview)."]]
