Introduction

Redirecting HTTP traffic to HTTPS is a standard NGINX Ingress requirement, but redirect failures are usually caused by configuration layers disagreeing with each other. A working setup needs valid TLS, one clear redirect policy, and awareness of any load balancer or proxy sitting in front of the ingress controller.

Start With a Valid TLS Configuration

Redirecting to HTTPS is only useful if HTTPS is actually configured correctly for the host. A minimal Ingress usually looks like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  namespace: app
6  annotations:
7    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
8spec:
9  ingressClassName: nginx
10  tls:
11    - hosts:
12        - app.example.com
13      secretName: app-tls
14  rules:
15    - host: app.example.com
16      http:
17        paths:
18          - path: /
19            pathType: Prefix
20            backend:
21              service:
22                name: app-service
23                port:
24                  number: 80

If the TLS secret is missing, expired, or attached to the wrong host, redirect behavior can appear broken even though the real problem is simply bad HTTPS configuration.

Understand the Redirect Annotation

For NGINX Ingress, the most common annotation is:

• 'nginx.ingress.kubernetes.io/force-ssl-redirect: "true"'

You may also see ssl-redirect. The exact interaction depends on controller behavior and broader configuration, but the operational rule is simple: pick one clear redirect policy for a host and keep it consistent across related ingress objects.

Conflicting ingress resources for the same hostname are a common source of confusing redirect behavior.

Watch for Redirect Loops Behind a Load Balancer

One of the most common production issues is a redirect loop caused by TLS termination in front of the ingress controller.

The pattern usually looks like this:

1. the client sends an HTTPS request
2. an external load balancer terminates TLS
3. ingress receives plain HTTP internally
4. ingress thinks the client used HTTP and redirects to HTTPS again

That loop is not fixed by tweaking the annotation alone. You need to verify that forwarded scheme information is being preserved correctly between the load balancer and the ingress controller.

If a cloud load balancer is in front of NGINX Ingress, include that layer in the diagnosis instead of treating the Ingress YAML as the whole system.

Test Redirect Behavior Explicitly

Do not rely on browser behavior alone. Use curl so you can see the status code and Location header clearly.

curl -I http://app.example.com
curl -I https://app.example.com
curl -IL http://app.example.com/path

The expected result is usually:

• HTTP returns a redirect to HTTPS
• HTTPS returns the real application response
• no repeated loop appears across nested paths

Testing only / can miss route-specific problems, so include important API or application paths too.

Add HSTS Only After HTTPS Is Stable

Once HTTPS works correctly, you may decide to add HSTS so browsers prefer secure transport automatically.

1metadata:
2  annotations:
3    nginx.ingress.kubernetes.io/server-snippet: |
4      add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Use this carefully. Browsers cache HSTS aggressively, so enabling it on a misconfigured or temporary environment can create a frustrating recovery process.

Certificates and Rotation Still Matter

A forced redirect to a broken TLS endpoint is worse than no redirect at all. If cert-manager or another system rotates certificates, monitor expiry and secret references as part of the redirect setup.

Redirect policy and certificate health belong together operationally. Users experience them as one system, not as separate features.

Common Pitfalls

The biggest mistake is enabling HTTPS redirect before confirming that HTTPS itself is healthy for the hostname.

Another issue is debugging only the ingress manifest while ignoring the upstream load balancer or proxy that may be changing the scheme information.

Teams also sometimes define overlapping ingress resources with inconsistent annotations for the same host and path space.

Finally, add HSTS only after the HTTPS path is stable and trusted. It is easy to turn a temporary configuration error into a sticky browser-side problem.

Summary

• Redirect to HTTPS only after TLS is configured correctly for the host.
• Keep one clear redirect policy for each hostname.
• Investigate load balancer and forwarded-scheme behavior when redirect loops appear.
• Test redirect responses explicitly with curl, not just with a browser.
• Treat HTTPS redirect and certificate health as one operational concern.