Context
An HTTP 404 at an Ingress address can come from different places. The controller may have no matching route, or the application may receive the request and reject its path. Kubernetes defines hostname and path matching, while controller implementations add their own rewrite and forwarded-header behavior. Diagnose these boundaries separately so an attempted fix does not quietly change every route.
Before starting, identify the Ingress namespace, external hostname, IngressClass, controller, backend Service, and an approved read-only application URL. You need read access to Ingress and Service objects. Obtain controller logs through your platform's permitted logging interface rather than granting yourself broader cluster permissions.
1. Reproduce the exact host and path
Record the scheme, host, path, response status, and relevant response headers. Query an approved safe endpoint:
curl -sS -D - -o /dev/null https://shop.example.test/catalog
kubectl -n shop get ingress storefront -o yaml
kubectl -n shop describe ingress storefront
The hostname is illustrative. If testing a specific load-balancer address, preserve the intended TLS hostname with your HTTP tool's supported resolution override. Sending an IP-address URL or a different Host header can exercise a default route instead of the rule users reach.
2. Evaluate path matching literally
Read each path and its pathType. Exact matches are case-sensitive and require the exact URL path. Prefix matches use path elements separated by slashes rather than arbitrary string prefixes. When multiple paths match, the longest matching path takes priority; equally matched Exact rules take precedence over Prefix rules.
For an explicitly illustrative example, a Prefix rule for /catalog matches /catalog/items but does not match /catalogue. An Exact rule for /catalog does not also match /catalog/. Write a small request matrix before changing either rule so trailing slashes and neighboring application routes remain intentional.
3. Follow the selected backend
Confirm the Ingress references the intended Service name and Service port. Inspect the Service's destinations and compare controller request logs with application access logs. Correlate a benign request identifier if the stack supports one. A response body alone is unreliable evidence of which component produced the 404.
Matching a Prefix does not promise that the prefix will be removed. An application expecting /items may receive /catalog/items unless the controller's documented configuration says otherwise. Rewrites, regular expressions, and annotations belong to the identified controller's behavior, not to a universal Ingress feature.
Use a focused diagnostic matrix
| Observation | Likely boundary | Next check |
|---|---|---|
| Default-controller response, no app request | Host, class or path selection | Match exact request against live rules |
| App logs the request and returns 404 | Application route contract | Check received path and rewrite policy |
| Redirect points to an unexpected scheme | Proxy context | Review trusted forwarded-header handling |
| One nested path selects another app | Rule precedence | Compare longest matching paths |
Forwarded headers deserve a separate check when redirects or absolute URLs fail. Establish which proxy writes them and which proxies the application trusts. Do not copy an unrelated controller annotation or trust arbitrary client-supplied forwarding headers to resolve a path mismatch.
Correct and verify the route contract
Change the narrowest responsible rule or application base-path setting through the normal review process. Repeat the full request matrix, including a nonexistent path that should remain a 404. Check controller events and a harmless application journey after rollout.
Maintain a route inventory containing hostname, path type, backend port, rewrite owner, and expected redirects. Add that matrix to release acceptance checks. Monitor route-specific errors and unexpected redirect targets so configuration drift appears before users discover that only a subpath is broken.
Explore Clouvenix containers kubernetes for implementation and operational handover.