Introduction

When a GCE Ingress always sends traffic to the default-http-backend, it means the Google load balancer did not find a usable rule and backend for the request. The underlying cause is usually one of four things: the host or path does not match the ingress rule, the referenced service has no healthy endpoints, the ingress controller has not finished provisioning, or the ingress configuration does not match the GCE controller's expectations.

What The Default Backend Means

The default HTTP backend is the catch-all target for requests that do not match a healthy configured route. That makes it a symptom, not a root cause.

So the debugging question is not "why is GCE using the default backend," but rather "why did my intended rule fail to match or fail to become healthy?"

Start By Inspecting The Ingress Resource

kubectl describe ingress my-ingress

Look for:

• the expected host rules
• the expected path rules
• events showing provisioning errors
• the external IP assigned by the controller

If the request host or path does not match the rule exactly, fallback behavior is expected.

Verify Host And Path Matching

A common mistake is testing the external IP directly without sending the expected host header.

curl -H 'Host: app.example.com' http://EXTERNAL_IP/my-path

If your ingress rule is defined for app.example.com, a plain request to the IP without that host header may not match the intended rule at all.

Also verify the path semantics. The route /api is not the same as /.

Check The Backend Service And Endpoints

Even if the ingress rule matches, traffic still falls back if the backend service has no healthy endpoints.

kubectl get svc my-service
kubectl get endpoints my-service

If the endpoints list is empty, the service selector likely does not match the pods, or the pods are not ready. In that situation, the ingress rule exists, but the load balancer has nowhere healthy to send traffic.

Readiness And Health Checks Matter

GCE Ingress integrates with cloud load-balancer health checks. If your application pods are not passing readiness or health checks, the backend may never become healthy from the load balancer's point of view.

Check:

• pod readiness status
• service port and target port alignment
• health check path assumptions
• whether the application actually listens on the port you exposed

A mismatched port is one of the easiest ways to end up at the default backend.

A Minimal Ingress Example

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  rules:
7    - host: app.example.com
8      http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: app-service
15                port:
16                  number: 80

This only works if app-service exists, exposes port 80, and has ready endpoints behind it.

GCE Controller Specifics

Make sure the ingress is actually being handled by the intended controller. In environments with multiple ingress classes, the wrong controller may ignore or partially interpret the resource.

Also give the GCE controller time to finish provisioning. External load balancers, backend services, health checks, and URL maps are not instantaneous.

kubectl get ingress my-ingress -w

Watch for the external IP and stable configuration before assuming the route is ready.

Common Pitfalls

The biggest mistake is testing by IP alone when the ingress rule is host-based. Another is focusing only on the ingress YAML while ignoring whether the service has ready endpoints. Developers also often forget that a path can be syntactically present but operationally useless if the service port, target port, or readiness configuration is wrong. Finally, GCE provisioning can take time, so an early request may hit the default backend before the load balancer is fully programmed.

Summary

• Falling back to default-http-backend means the intended rule or backend is not usable.
• Verify host and path matching first, including the Host header in tests.
• Check that the referenced service has healthy endpoints.
• Confirm ports, readiness, and health-check behavior.
• Make sure the GCE ingress controller has finished provisioning the external load balancer.