kubernetes
nginx
ingress
rewrite-target
troubleshooting

kubernetes nginx ingress rewrite-target not work

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

When rewrite-target appears broken in NGINX Ingress, the issue is usually a mismatch between path regex groups, path type, and controller annotations rather than the backend service itself. In practice, the fastest path is to reduce the problem to a small reproducible baseline first, then reintroduce production constraints one by one. That approach keeps debugging local, prevents overfitting to one failing symptom, and makes your final implementation easier to explain to teammates.

Rewrites depend on exactly what the ingress controller receives as the incoming path. If regex capture groups are missing or use-regex is not enabled, the target path cannot be computed as expected. A strong implementation separates configuration from execution flow, adds measurable checkpoints, and captures enough telemetry to distinguish transient failures from deterministic misconfiguration.

Core Sections

1) Define a narrow baseline before optimization

Start by identifying the smallest end-to-end version that should work reliably. Keep external dependencies minimal, remove optional features, and make defaults explicit. Once the baseline is stable, layer complexity gradually and verify behavior after each change. This staged workflow is more predictable than changing multiple variables at once and trying to infer root cause afterward.

2) Use regex path + capture groups with matching rewrite target

yaml
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    nginx.ingress.kubernetes.io/use-regex: "true"
7    nginx.ingress.kubernetes.io/rewrite-target: /$2
8spec:
9  ingressClassName: nginx
10  rules:
11  - host: app.example.com
12    http:
13      paths:
14      - path: /api(/|$)(.*)
15        pathType: ImplementationSpecific
16        backend:
17          service:
18            name: api-service
19            port:
20              number: 8080

This baseline snippet is intentionally conservative. It prioritizes readability, deterministic behavior, and explicit control points over clever shortcuts. For production, you can tune performance later, but first ensure the pipeline is correct and repeatable. If this step does not behave as expected, freeze further refactors and diagnose here; debugging gets exponentially harder once additional abstractions are layered on top.

3) Inspect generated NGINX config and controller logs

bash
1kubectl describe ingress app-ingress
2kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --tail=200 | grep app-ingress
3
4# Validate route behavior from inside cluster
5kubectl run -it curl --rm --image=curlimages/curl --   curl -H "Host: app.example.com" http://ingress-nginx-controller.ingress-nginx.svc.cluster.local/api/health

Operational guardrails are what turn a working demo into a maintainable system. Add logging around key transitions, monitor latency and error classes, and define clear retry or fallback policy where failures are expected. Avoid silent recovery paths that hide data quality or state issues. Instead, emit structured signals that make post-incident analysis straightforward.

4) Validate behavior with repeatable checks

Test multiple paths (/api, /api/, /api/v1/users) and verify backend access logs for the rewritten URI. This catches capture-group mistakes immediately. Write a short verification checklist that can run in local development, CI, and pre-release environments. Include both success-path assertions and at least one intentional failure case. Over time, this checklist becomes regression protection: it documents assumptions, catches environment drift, and prevents future edits from reintroducing the same class of bug.

Common Pitfalls

  • Using pathType: Prefix with regex syntax and expecting capture groups to work.
  • Setting rewrite-target to $1 while the regex actually captures desired text in $2.
  • Applying annotations to a different ingress object than the active host rule.
  • Forgetting to use the ingress class managed by the NGINX controller instance.
  • Assuming old behavior from deprecated API versions without validating controller docs.

Summary

Ingress rewrites are predictable when regex, capture groups, path type, and controller class are aligned end-to-end. The key pattern is consistent across stacks: keep the core path simple, instrument the edges, and validate with deterministic tests before scaling complexity.


Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.