[[["易于理解","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-19。"],[],[],null,["# Routing rule maps overview\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\nThis document applies only to Cloud Service Mesh with the load balancing APIs. We\nstrongly recommend that you use the\n[service routing APIs](/service-mesh/docs/service-routing/service-routing-overview).\n\nA routing rule map consists of the following:\n\n- A [forwarding rule](/service-mesh/legacy/load-balancing-apis/forwarding-rules) that references a target proxy\n- A [target proxy](/service-mesh/legacy/load-balancing-apis/target-proxies) that references a URL map\n- A [URL map](/load-balancing/docs/url-map-concepts) that contains various routing rules\n\nWhen you create and configure these resources for Cloud Service Mesh,\nCloud Service Mesh uses the values to create the configuration that it\nsends to your data plane, which includes xDS clients such as Envoy\nproxies and proxyless gRPC applications. The data plane then handles traffic\naccording to this configuration.\n\nA forwarding rule references a target proxy, and has an IP address and a port.\nFor Cloud Service Mesh deployments, the forwarding rule's load-balancing\nscheme must be set to `INTERNAL_SELF_MANAGED`. The target proxy, in turn,\nreferences a URL map. These three resources combine to form a routing rule map.\n\nA forwarding rule that references a target gRPC proxy with the\n`validateForProxyless` field set to `TRUE` must have its IP address set to\n`0.0.0.0`. When `validateForProxyless` is set to `TRUE`, configurations that\nspecify an IP address other than `0.0.0.0` are rejected.\n\nThe routing rule map defines how traffic passes from clients to servers inside\na service mesh.\n\nSupported target proxy types\n----------------------------\n\nCloud Service Mesh supports the following target proxy types:\n\n- **Target HTTP proxy**, which you configure when your clients and servers send or receive HTTP or HTTP/2 traffic.\n- **Target HTTPS proxy**, which you configure when your clients and servers send or receive HTTPS traffic. This is required when you set up service security with Envoy proxies.\n- **Target TCP proxy**, which you configure when your clients and servers send or receive TCP traffic.\n- **Target gRPC proxy** , which you configure when your clients and servers send or receive gRPC traffic. Target gRPC proxies contain the field `validateForProxyless`, which is set to `TRUE` when you deploy proxyless gRPC services.\n\nTraffic routing with Envoy sidecar proxies\n------------------------------------------\n\nWhen you use Cloud Service Mesh with Envoy sidecar proxies, client requests\nare routed as follows:\n\n- The network stack intercepts the request and redirects it to your Envoy sidecar proxy.\n- The Envoy sidecar proxy looks at the request's IP address and port.\n- The IP address and port pair are checked against the IP address and port specified in any forwarding rules that have the load-balancing scheme set to `INTERNAL_SELF_MANAGED`.\n- If a forwarding rule with a matching IP address and port is found, Envoy looks at the target HTTP proxy or the target gRPC proxy that the forwarding rule references.\n- Envoy checks the URL map that the target proxy references.\n- Envoy routes the request according to the rules specified in the URL map.\n\nFor information about how traffic is routed with a target TCP proxy, see\n[Routing TCP traffic with Cloud Service Mesh](/service-mesh/legacy/load-balancing-apis/configure-tcp).\n\nTraffic routing with proxyless gRPC applications\n------------------------------------------------\n\nThis behavior is different for proxyless gRPC applications. When you configure\na gRPC client, you specify the target URI for the service that the client\nneeds to contact. This URI uses the `xds` name resolver scheme and the\n`hostname:port` format---for example `xds:///example.hostname:8080`.\n\nWhen the proxyless gRPC client connects to Cloud Service Mesh,\nCloud Service Mesh sends it information corresponding to the service\nas follows:\n\n- Cloud Service Mesh looks for forwarding rules with the load-balancing scheme set to `INTERNAL_SELF_MANAGED` to find forwarding rules whose port matches the port specified in the target URI.\n- Cloud Service Mesh finds the target gRPC proxy or the target HTTP proxy for each of these forwarding rules.\n- Cloud Service Mesh finds the URL maps referenced by these target gRPC proxies or target HTTP proxies.\n- Cloud Service Mesh checks the host rules in the URL map, which also have the `hostname[:port]` format, and looks for a match.\n- When a match is found, Cloud Service Mesh returns routing rules and service information to the gRPC client.\n\nIf more than one match is found, the behavior is undefined and can\nlead to unpredictable behavior. This generally happens when both of the following\nconditions are met:\n\n- The same hostname is used across multiple URL maps.\n- Multiple forwarding rules with the load-balancing scheme `INTERNAL_SELF_MANAGED` specify the same port.\n\nFor this reason, we recommend that you don't re-use the same hostname across\nmultiple URL maps that are referenced by forwarding rules that specify the same\nport.\n\nWhat's next\n-----------\n\n- To get fine-grained control over how traffic is handled, see the\n [Advanced traffic management overview](/service-mesh/legacy/load-balancing-apis/advanced-traffic-management-legacy).\n\n- To learn more about Cloud Service Mesh, see the\n [Cloud Service Mesh overview](/service-mesh/legacy/load-balancing-apis/overview)."]]