X-Forwarded-Proto

Problem

TLS is terminated at Traefik on the NAS. Traffic forwarded from Traefik to Kubernetes backends is plain HTTP. As a result, backends receive requests where X-Forwarded-Proto is http, even though the original client connection was HTTPS.

Many apps use this header to:

• Decide whether to issue an HTTPS redirect
• Construct absolute URLs in OAuth callbacks, API responses, or redirects
• Validate that the connection is secure before allowing certain operations (e.g. OIDC login)

When the header reports http, these apps either redirect to HTTP (breaking the connection), generate http:// callback URLs that fail OAuth flows, or refuse to function entirely.

Fix

For apps deployed on Kubernetes using the Gateway API, add a RequestHeaderModifier filter to the HTTPRoute to force X-Forwarded-Proto: https:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
  namespace: my-namespace
spec:
  parentRefs:
  - name: shared
    namespace: infra
  hostnames:
  - my-app.hdhomelab.com
  rules:
  - filters:
    - type: RequestHeaderModifier
      requestHeaderModifier:
        set:
        - name: X-Forwarded-Proto
          value: https
    backendRefs:
    - name: my-app
      port: 8080

The set action overwrites any existing value for the header. This ensures the app always sees https regardless of what Traefik forwards.

Note

This fix only applies to apps routed through the Gateway API. Apps routed via the Ingress controller or Traefik directly may need the header set differently depending on the proxy configuration.

Affected Apps

Apps known to require this fix:

App	Symptom
Jenkins	Redirects to http:// after login
Shelfarr	OAuth callback URL constructed with http://
Audiobookshelf	OIDC login fails with redirect URI mismatch