Consul compiles a destination service's `service-router`, `service-splitter` and `service-resolver` config entries into a discovery chain. In what order do those three stages apply, and which of them require the destination's protocol to be declared as HTTP?

## What the discovery chain is When a mesh proxy needs to reach an upstream, Consul does not just hand it a list of healthy instances. It compiles a **discovery chain** for that destination — a graph assembled from up to three config entries — and turns the result into the proxy's routing and cluster configuration. Understanding the order is what lets you predict which entry actually shapes a given request. ## Stage one: `service-router` The router is the L7 entry point. It matches on request attributes and picks a destination: ```hcl Kind = "service-router" Name = "api" Routes = [ { Match { HTTP { PathPrefix = "/admin" } } Destination { Service = "api-admin" } }, { Match { HTTP { Header = [{ Name = "x-debug", Exact = "1" }] } } Destination { ServiceSubset = "canary" } } ] ``` Routes are evaluated in order and the first match wins; anything unmatched falls through to the default destination, which is the service itself. This is the stage that gives you deterministic header-based access to a specific version. ## Stage two: `service-splitter` Whatever the router selected is then split by weight: ```hcl Kind = "service-splitter" Name = "api" Splits = [ { Weight = 90, ServiceSubset = "v1" }, { Weight = 10, ServiceSubset = "v2" } ] ``` Weights are percentages and must sum to 100. This is the mechanism behind weighted traffic shifting — note that it is only the mechanism; deciding *when* to shift and on what signal is a release-process question, not a Consul one. ## Stage three: `service-resolver` The resolver answers "which instances count as this target?": ```hcl Kind = "service-resolver" Name = "api" DefaultSubset = "v1" Subsets = { v1 = { Filter = "Service.Meta.version == v1" } v2 = { Filter = "Service.Meta.version == v2" } } Failover = { "*" = { Datacenters = ["dc2"] } } ConnectTimeout = "5s" ``` `Subsets` name a slice of the catalog using a filter expression over instance metadata — which is why version-based routing depends on instances actually registering the metadata the filter reads. The resolver also owns `Redirect` (send this name somewhere else entirely), `Failover` (where to go when no healthy instance remains), `ConnectTimeout`, and load-balancing policy. Because it selects endpoints rather than inspecting requests, it applies to any protocol. ## The protocol prerequisite A Consul mesh proxy treats an upstream as an opaque TCP stream unless told otherwise. Declaring the protocol is a separate, easily-forgotten step: ```hcl Kind = "service-defaults" Name = "api" Protocol = "http" ``` Without it, the proxy has no HTTP parsing on that upstream, so nothing can match a path or count requests for a percentage split — the router and splitter have no meaning and Consul will not accept them as part of a valid chain. The resolver still works. This is the single most common reason a newcomer's canary split "does nothing": the entry was written, and the service was still on the default `tcp` protocol. The same prerequisite governs L7 intention `Permissions` and per-request metrics, so declaring the protocol is really the switch that turns a connection-level mesh into a request-level one for that service. ## Reading the compiled result Rather than reasoning about three entries in your head, ask Consul what it compiled: `GET /v1/discovery-chain/api` returns the resolved graph including the router nodes, splitter weights, resolver targets and the effective protocol. If the chain shows a single resolver node and no router, your protocol is almost certainly still `tcp`. This is also the fastest way to see that a subset filter matched nothing — a subset with no instances behind it produces a target that will simply fail to connect. ## Practical cautions Subsets are only as good as the metadata instances register, so version labels must be applied consistently by whatever registers the service. Splits apply to new requests, so a long-lived streaming or gRPC connection stays where it landed. And a resolver `Redirect` is evaluated before failover, so a chain can hop between services in ways that are much easier to see in the compiled output than in the source entries.