An Istio VirtualService is applied with no `gateways` field set. Which traffic does it govern, and what has to change for that same VirtualService to route requests arriving at an Istio ingress Gateway?

## Two resources, one binding The Istio edge is described by a pair of resources that do genuinely different jobs. The **Gateway** is the listener description. It says which ingress workload is being configured (through `selector`, matching labels on the ingress proxy's pods), which ports and protocols it accepts, which hostnames it will serve, and how TLS is handled for each server: ```yaml apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: web-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS tls: mode: SIMPLE credentialName: web-tls hosts: - shop.example.com ``` A Gateway on its own accepts connections and then has nowhere to send them. It contains **no routes**. The routing lives, as always, in a VirtualService — and the VirtualService has to say that it applies here. ## The default is `mesh`, not "everywhere" `spec.gateways` on a VirtualService is a list, and when you omit it Istio treats it as `["mesh"]`. `mesh` is a reserved name meaning *all sidecar proxies in the mesh*. So an omitted `gateways` field gives you east-west routing only: service-to-service calls inside the cluster obey the rules, and requests arriving at the ingress do not. To serve edge traffic, list the Gateway: ```yaml spec: hosts: - shop.example.com gateways: - istio-system/web-gateway http: - route: - destination: {host: frontend, port: {number: 8080}} ``` ## The replacement trap Writing `gateways: ["istio-system/web-gateway"]` **replaces** the default rather than adding to it. If in-mesh services also call this host by the same name, their traffic no longer matches any rule in this VirtualService, and behaviour silently changes — canary weights stop applying east-west, or a rewrite stops happening. When one VirtualService is meant to govern both directions, list both: ```yaml gateways: - mesh - istio-system/web-gateway ``` That said, edge routing and in-mesh routing usually want different hostnames and different rules. Splitting them into two VirtualServices is often cleaner than one resource trying to serve both. ## Namespaces and qualified names Gateways commonly live in the ingress namespace (`istio-system` in a default installation) while the VirtualService lives with the application. A bare name in `gateways` resolves in the **VirtualService's own** namespace, so referencing a Gateway elsewhere requires the `namespace/name` form. A silently non-matching reference is one of the two most common causes of edge 404s. The Gateway's `servers[].hosts` may itself be namespace-qualified — `"*/shop.example.com"` allows a VirtualService in any namespace to bind for that host, while `"./shop.example.com"` restricts binding to the Gateway's own namespace. That is the control an ingress owner uses to decide which teams may attach routes to a shared hostname. ## Hosts must intersect Even with the Gateway correctly referenced, the VirtualService's `hosts` must overlap the Gateway server's `hosts`. A Gateway serving `shop.example.com` and a VirtualService declaring `hosts: ["www.example.com"]` bind to nothing useful, and the ingress answers 404. Wildcards are allowed on both sides, and `"*"` on the Gateway accepts anything — convenient in a demo, and a poor idea on a shared ingress, because any team can then claim any hostname. ## Diagnosing an edge 404 When requests reach the ingress and come back 404 without the application logging anything, work through the binding chain in order: does the Gateway's `selector` actually match the ingress pods' labels; is the port and protocol right; does the VirtualService reference the Gateway with the correct `namespace/name`; do the hostnames intersect; and does the destination resolve. Inspecting the ingress proxy's routes with `istioctl proxy-config route` on the ingress pod shows whether the route was ever programmed — an empty or default-only route table means the binding failed, not the routing.