Introduction

If an Ingress only seems to work for the root path /, the problem is usually not Kubernetes itself but the combination of path matching, controller behavior, and backend application routing. In practice, the fix usually lives in one of three places: the pathType, the ingress-controller rewrite rules, or the application behind the service.

Start With A Minimal Correct Rule

A basic prefix rule should look like this:

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

With pathType: Prefix, requests such as /app and /app/login should route to the backend.

Why Only / Often Works

The common reasons are:

• the path was defined with the wrong pathType
• the controller expects controller-specific annotations for regex or rewrite behavior
• the backend app only serves content correctly from / and breaks when mounted under a subpath
• the service works, but generated links, redirects, or static assets still point at the root path

That last point is especially common with web apps that were never configured to run behind /app or another prefix.

The Backend App May Be The Real Problem

Even if the ingress forwards /app correctly, the backend may respond with redirects or HTML that assumes it is mounted at /. Then the browser requests /css/site.css instead of /app/css/site.css, and it looks like only the root route works.

In other words, ingress routing can be correct while the application is subpath-unaware.

Rewrite Example For NGINX Ingress

Some backends expect the prefix to be stripped before the request reaches them. For an NGINX-based controller, a rewrite annotation is a common fix.

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

Now a request to /app can be forwarded to / on the backend service, which often matches how the application is actually built.

Check The Controller You Are Using

Different ingress controllers interpret advanced path features differently. ImplementationSpecific in particular means the controller decides the matching behavior. If you expected regex-like path handling, verify that your controller actually supports it and that you enabled the right annotations.

For basic path routing, prefer Prefix or Exact unless you have a controller-specific reason not to.

Debugging Checklist

A short checklist helps isolate the failure:

1. verify the service works directly with port-forwarding
2. verify the ingress path and pathType
3. inspect controller logs for rule parsing errors
4. check whether the backend app supports being served from a subpath
5. test whether a rewrite target is required

This separates ingress configuration problems from backend application problems quickly.

Common Pitfalls

The most common mistake is assuming path routing failed when the real problem is that the backend app generates root-relative redirects or asset URLs.

Another mistake is using ImplementationSpecific and expecting portable behavior across controllers.

A third issue is adding rewrite annotations without understanding whether the application expects /app/... or /... once the request reaches the backend.

Summary

• If only / works, inspect path matching, rewrites, and backend subpath support together.
• Use Prefix or Exact deliberately instead of relying on controller-specific defaults.
• A working service behind port-forward but a broken Ingress usually points to path or rewrite configuration.
• A correctly routed request can still fail if the backend application assumes it lives at /.
• Controller logs and direct service tests are the fastest way to isolate the real cause.