Introduction

A redirect loop between Argo CD and NGINX Ingress usually means the proxy and the Argo CD server disagree about where TLS is terminated. Adding --insecure changes one part of the request path, but it does not automatically fix an ingress that is still forwarding traffic with the wrong protocol or headers.

The reliable fix is to choose one TLS model and configure every hop to match it. Once the ingress, service port, and Argo CD server agree, the loop disappears.

Why the Redirect Loop Happens

Argo CD can run with its own TLS enabled, or it can trust the ingress to terminate TLS and speak plain HTTP to the backend. Problems start when those models are mixed.

A few common examples:

• NGINX terminates TLS, but the ingress still proxies to the Argo CD HTTPS backend.
• Argo CD is started with server.insecure: "true", but the ingress annotation still says the backend protocol is HTTPS.
• The ingress forces HTTPS redirects, while Argo CD also believes it must redirect because forwarded protocol information is inconsistent.

In all three cases, the browser keeps bouncing between equivalent URLs and eventually reports too many redirects.

Pattern 1: TLS Terminates at Ingress

This is the simpler setup for many clusters. NGINX handles the public certificate, and Argo CD listens over plain HTTP behind the ingress.

For this model:

• Set Argo CD to insecure mode on the server side.
• Route the ingress backend to the HTTP service port.
• Tell NGINX that the upstream protocol is HTTP, not HTTPS.

Example configuration:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: argocd-cmd-params-cm
5  namespace: argocd
6data:
7  server.insecure: "true"
8---
9apiVersion: networking.k8s.io/v1
10kind: Ingress
11metadata:
12  name: argocd-server
13  namespace: argocd
14  annotations:
15    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
16    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
17spec:
18  ingressClassName: nginx
19  tls:
20    - hosts:
21        - argocd.example.com
22      secretName: argocd-tls
23  rules:
24    - host: argocd.example.com
25      http:
26        paths:
27          - path: /
28            pathType: Prefix
29            backend:
30              service:
31                name: argocd-server
32                port:
33                  name: http

If you enable server.insecure, but still send traffic to the HTTPS port or annotate the backend as HTTPS, you have only done half the migration.

Pattern 2: TLS Pass-Through to Argo CD

If you want Argo CD itself to keep handling TLS, the ingress must pass encrypted traffic through instead of terminating it. In that model:

• Do not enable server.insecure.
• Configure the ingress controller with SSL pass-through support.
• Route to the HTTPS backend.

A minimal ingress looks like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: argocd-server
5  namespace: argocd
6  annotations:
7    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
8    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
9spec:
10  ingressClassName: nginx
11  rules:
12    - host: argocd.example.com
13      http:
14        paths:
15          - path: /
16            pathType: Prefix
17            backend:
18              service:
19                name: argocd-server
20                port:
21                  name: https

This pattern works, but it requires the NGINX Ingress controller to be started with SSL pass-through enabled. If that controller flag is missing, the ingress may accept the object but still fail at runtime.

Checking the Actual Request Path

When redirects are confusing, inspect each hop rather than guessing. Useful checks include:

• 'kubectl get ingress -n argocd argocd-server -o yaml'
• 'kubectl get cm -n argocd argocd-cmd-params-cm -o yaml'
• 'kubectl logs -n ingress-nginx deploy/ingress-nginx-controller'
• 'kubectl logs -n argocd deploy/argocd-server'

You are looking for mismatches such as server.insecure: "true" combined with an HTTPS upstream, or an ingress that redirects to HTTPS while the backend already believes it is serving secure traffic.

A Note About gRPC

Argo CD uses both normal HTTP traffic and gRPC. Depending on the controller version and your ingress style, gRPC sometimes needs separate hostnames or ingress rules. If the web UI works but the CLI behaves strangely, review whether your ingress also handles the gRPC path correctly.

That is a separate issue from a browser redirect loop, but teams often hit both while trying to simplify the same ingress.

Common Pitfalls

The most common mistake is assuming --insecure fixes everything by itself. It only tells Argo CD not to serve TLS on its own listener. You still need the ingress backend protocol and service port to match that choice.

Another mistake is mixing service port names. Sending the ingress to https while telling NGINX the backend is HTTP creates contradictory behavior that is hard to spot in a quick manifest review.

People also forget about controller-level SSL pass-through support. The ingress annotation alone is not enough if the NGINX controller was not launched with the right flag.

Finally, avoid layering multiple redirect mechanisms unless you understand each one. If Argo CD, NGINX, and an external load balancer all try to enforce HTTPS independently, debugging becomes much harder.

Summary

• Redirect loops usually mean Argo CD and NGINX disagree about where TLS ends.
• Pick one model: TLS termination at ingress or SSL pass-through to Argo CD.
• For ingress termination, use server.insecure: "true" and an HTTP backend.
• For pass-through, keep Argo CD TLS enabled and proxy to the HTTPS backend.
• Verify ingress annotations, service port names, and controller flags together instead of changing only one layer.