Introduction
When an Ingress controller returns the default backend 404, it usually means the request never matched the rule you thought it would. That can happen because the host header is wrong, the path does not match the configured path type, the wrong ingress class picked up the object, or the backend wiring is incomplete. The important point is that a default-backend 404 is often a routing mismatch rather than an application error.
Symptoms
- Requests return
404from the ingress controller rather than from the app - The default backend response appears even though an Ingress object exists
- Curl works with one host header but not another
- A new ingress or controller migration changed which requests route correctly
Common Causes
- The request host does not match any ingress rule
- The path rule and
pathTypedo not match the request URL the way you expect - The Ingress object is not using the ingress class handled by the active controller
- The backend service has no healthy endpoints even though the route exists
Step-by-Step Fix
- 1.Inspect the Ingress object and class
- 2.Confirm the host, path, service name, and ingress class on the live object instead of the manifest you think was applied.
kubectl get ingress my-ingress -o yaml- 1.Test with the exact host header
- 2.Many ingress 404s are simply host mismatches.
curl -H "Host: myapp.example.com" http://INGRESS_IP/- 1.Check that the backend Service and endpoints are real
- 2.A route can match correctly and still fail if the Service points nowhere useful.
kubectl get svc my-service
kubectl get endpoints my-service- 1.Review controller logs if the rule still does not match
- 2.The ingress controller usually logs enough to reveal whether the route was ignored, unmatched, or misclassified.
Prevention
- Validate ingress class usage explicitly when multiple controllers exist
- Test host and path routing with real curl requests after ingress changes
- Monitor endpoint health alongside ingress routing
- Keep host and path rules simple and explicit where possible