Putting authentik behind a reverse proxy

The most likely cause is that authentik does not receive the X-Forwarded-Proto header from your proxy, or ignores it because the proxy's address is not trusted. From authentik 2026.8, forwarded headers are only accepted from networks listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, so authentik can treat an HTTPS request as plain HTTP. Check the scheme in the Location header of a redirect from the login flow. If it says confirm that your proxy sends X-Forwarded-Proto` and that its source address falls inside the configured CIDR range.

Mixed content appears when the page is served over HTTPS but authentik generates links, scripts or API calls with an ` scheme. The browser then blocks those resources. This follows the same forwarded header issue described in the 2026.8 release notes, where authentik may treat HTTPS as HTTP. Open the browser developer console and look for blocked requests. Then compare the URLs with your external domain. If the scheme is wrong, review the proxy's forwarded headers and the trusted proxy CIDR list before changing anything inside authentik.

An endless spinner after sign-in often means a redirect or WebSocket connection is looping or failing. Possible causes include a wrong scheme or host in redirects, a proxy that does not forward the upgrade headers for WebSockets, or a trusted proxy setting that excludes the proxy address. Check the browser network tab for repeated redirects and for WebSocket connections that close immediately. Also confirm that the proxy forwards requests to the same authentik server that issued the original redirect.

Check the client address recorded in authentik's event logs and compare it with the address of a test client. If every event shows the proxy's internal IP, authentik is not reading X-Forwarded-For from a trusted source. Make sure the proxy sets that header, that its own address is included in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS, and that no other proxy in the chain overwrites the header. Logs that show the correct client IP after a change confirm the fix.

Callback URLs use the host that authentik believes the request came from. If it reads X-Forwarded-Host from an untrusted source or the header is missing, the redirect may point to an internal hostname or port. Inspect the redirect_uri parameter in the authorization request and compare it with the redirect URI registered in the application's provider. A mismatch produces errors such as invalid redirect URI, and the fix is usually to correct forwarded headers at the proxy and confirm the trusted CIDR list.

It can. The 2026.5 release notes say the default listen address changed from 0.0.0.0 to [::], and some IPv4-only environments may need to adjust it. If the proxy connects over IPv4 and authentik is not reachable, requests fail at the connection level rather than producing authentication errors. Confirm the listen settings in your deployment, test connectivity from the proxy host to the authentik server port, and review the 2026.5 release notes before upgrading an existing setup.

Start by comparing a direct connection to authentik with a connection through the proxy. If the direct connection works and the proxied one fails, the problem sits in the forwarded headers, trusted CIDRs or WebSocket handling. Capture the request and response headers at the proxy, confirm X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For are present, and verify the proxy's address matches a trusted range. Your own environment and proxy documentation should confirm the exact header names each product sets by default.

Yes, a team with working knowledge of its proxy and DNS can usually do the basic setup alone, because the core work is a handful of forwarded headers, a trusted proxy list and a TLS listener. The harder part is confirming that every path works after the change: login, logout, the admin interface, outposts and any websocket traffic. Teams that already operate the proxy, own the certificates and can test against a staging hostname are the best candidates to do it in house. Teams without that proxy experience, or with several proxies and domains, often find an outside review of the configuration worth the time. Whichever route you choose, test a failed header on purpose so you know what the symptoms look like before users report them.

Effort follows the number of moving parts rather than the proxy brand alone. The main drivers are:

• How many proxies or load balancers sit in front of authentik, since each hop must forward headers correctly and must be listed as trusted.
• Whether TLS is already terminated cleanly at one point or split across several layers, with re-encryption to the backend.
• How many public domains, subdomains and per-application hostnames need to route through authentik.
• Whether proxy outposts, LDAP or RADIUS endpoints need their own routing, which adds listeners and testing.

Each additional driver adds design decisions, test cases and rollback planning. Ask any provider to break the quote down along these lines so you can see which items would shrink if your architecture is simpler.

The duration depends on the drivers above and on how quickly your change process approves changes to production routing, so no single figure applies. A simple single-proxy setup in a test environment can be completed in a short working session, while a multi-domain production change with staged testing and a rollback plan takes longer. No duration figure has been published for this work, so ask any provider for a timeline in their written scope and check which steps depend on your own change windows. Plan for at least one full test cycle on a non-production hostname before cutover.

Prepare four things before any configuration begins:

• DNS control for the public hostname, so the record and any staging name can point at the new entry point.
• The certificate source, whether a corporate certificate authority, a public certificate or a cloud-managed certificate, and who renews it.
• The network CIDRs of every proxy or load balancer that will forward traffic to authentik, because these become the trusted proxy list in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS.
• A list of applications and hostnames that will be routed through the proxy, plus access to a staging environment for testing.

Missing any of these usually causes delays later, most often when a team discovers the proxy's egress address is not the address it expected.

Yes. From authentik 2026.8, the server accepts forwarded headers such as X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For only from networks listed in the trusted proxy setting. If that list is too broad, clients outside your proxy can supply headers that authentik believes, which weakens its view of the connection and of client addresses. If the list is too narrow, authentik may treat HTTPS traffic as HTTP, which causes mixed content, endless loading or authentication errors. Both failure modes are worth testing explicitly, and your security team should review the CIDR list as a controlled configuration item rather than a convenience setting. For version-specific details, read the authentik 2026.8 release notes.

DeployOpen agrees the scope, deliverables and timeline in writing before work starts, and most engagements are fixed-scope. A quote follows from that written scope, so it should name the proxies in scope, the domains and applications routed through authentik, the certificate and DNS changes, the staging and production test cases, and the documentation handed over at the end. Items that are not in scope, such as reconfiguring unrelated proxies or changing the identity design, should be listed as exclusions. DeployOpen does not publish a price list. Ask for the written scope first, then compare quotes on the same deliverables. Ongoing support, upgrades and continuous testing are available as retainers and are priced separately from the one-time configuration.