Leaving Ingress NGINX? Five Things That Will Quietly Return 404

Why this matters now

The Kubernetes project retired Ingress NGINX on 24 March 2026: no more releases, bug fixes or security fixes. Your existing install keeps running, which is exactly why it is easy to leave alone. But sooner or later you will move, probably to Gateway API, the Kubernetes project's successor to Ingress, and that is when its quiet habits show up as outages.

Everything below comes from the Kubernetes blog post Before You Migrate (27 February 2026), which demonstrates each behaviour.

One request, two controllers

1. Request arrives. A client asks for /Uuid/extra on your host, the way it always has.

1 / 5

The five habits

Regex paths are loose prefixes. A pattern like /[A-Z]{3} also matched /uuid and anything after it: matching ignored case, so uui counted as three capital letters, and only the start of the path had to match.
One annotation changes the whole host. If any Ingress for a host has use-regex, Ingress NGINX treats every path on that host as a loose regex, including paths in other Ingresses that never asked for it.
rewrite-target switches regex on. The rewrite annotation quietly turns on regex matching for the whole host, exactly as habit 2 describes.
Missing slashes are redirected. When the rule said /my-path/, a request for /my-path got a 301 redirect to /my-path/. Gateway API does not add redirects you did not configure.
URLs are tidied first. //, /./ and /../ were normalised before matching. Gateway implementations handle this in their own ways.

Find the risky hosts before you move

Habits 2 and 3 follow the host, not the Ingress. This lists every Ingress on a host where regex is on, including the ones with no annotation of their own:

bash

kubectl get ingress -A -o json | jq -r '([.items[]
  | select((.metadata.annotations // {}) | has("nginx.ingress.kubernetes.io/use-regex") or has("nginx.ingress.kubernetes.io/rewrite-target"))
  | .spec.rules[]?.host] | unique) as $h
  | .items[] | select([.spec.rules[]?.host] | any(. as $x | $h | index($x)))
  | "\(.metadata.namespace)/\(.metadata.name)"'

Then send your real client paths, with their real case and suffixes, to the old controller and the new one, and compare. Every difference is a decision: fix the path, or keep the old behaviour deliberately with a case-insensitive regex or an explicit redirect.

Where to go next

The full migration guide has each habit with a test request and the HTTPRoute that keeps it. Paste your Ingresses into the Kubernetes manifest analyzer: it flags Ingress NGINX annotations, and names Ingresses whose paths turn into regexes because of a neighbour.