Frigate not redirecting on 302

[banduraj78]

I currently have Frigate setup and functioning with caddy as a reverse proxy and have used both the caddy-security plugin and Authelia for authentication. In both cases (when using either caddy-security or Authelia), when the session times out, Frigate seems to fail to automatically redirect. Instead, what seems to happen is, as the Frigate page requests updated images and/or elements (e.g. cameras) a 302 with a location is returned and the individual cameras fail to load. Over time, all elements of the page fail to load.

Reading the Login page redirection sub section of the Authentication section of the Frigate docs indicate that:

Frigate gracefully performs login page redirection that should work with most authentication proxies. If your reverse proxy returns a Location header on 401, 302, or 307 unauthorized responses, Frigate's frontend will automatically detect it and redirect to that URL.

However, this is not the behavior that I am seeing. As soon as the token expires, and the page fails to start loading properly, reloading the page does forward to the back-end authentication page. But, my assumption was that Frigate would automatically redirect as soon as it received a 302 response of any kind and not need interaction from the user.

Maybe I am missing something in my setup?

[inkeep-ai-assistant[bot]]

Frigate's frontend is designed to automatically detect and redirect when a reverse proxy returns a Location header on 401, 302, or 307 unauthorized responses(1). If this is not happening in your setup with Caddy and either caddy-security or Authelia, it suggests that the redirect headers may not be reaching the Frigate frontend as expected, or the proxy setup might be interfering with how responses are delivered to the browser.

Key things to check:

• Ensure your reverse proxy is configured to forward the necessary headers (including Location) directly to the client and is not modifying or stripping them.
• Make sure Frigate's authentication is disabled if you are relying entirely on the upstream proxy for auth(1).
• If you have custom header mappings or use non-standard header names, verify that these are correctly mapped in your Frigate config under the proxy section(1)(2).
• Confirm that you are accessing Frigate via the authenticated port (8971) through the proxy(1).

If reloading the page triggers the redirect but background requests do not, it could indicate that the frontend JavaScript is not seeing the 302/Location headers on those background requests, possibly due to proxy or browser behavior.

For more details on reverse proxy setup and best practices, you may want to review the reverse proxy guide(3).

📚 Sources:

1. Authentication
2. Full Reference Config
3. Setting up a reverse proxy

---

Have another question? Just tag @inkeep.

[banduraj78]

I guess this is my first time responding to a bot, but here it goes.

• Ensure your reverse proxy is configured to forward the necessary headers (including Location) directly to the client and is not modifying or stripping them.
• Make sure Frigate's authentication is disabled if you are relying entirely on the upstream proxy for auth(1).
• If you have custom header mappings or use non-standard header names, verify that these are correctly mapped in your Frigate config under the proxy section(1)(2).
• Confirm that you are accessing Frigate via the authenticated port (8971) through the proxy(1).

• Reverse proxy is forwarding necessary headers. Pressing F12 to view the developer tools, I can see a 302 with Location set to the auth page being sent as elements attempt to load when the session has expired.
• Frigate's authentication is disabled.
• Custom header mappings are all done correctly. Proxy and authentication are all working as expected.
• Caddy is reverse proxy to Frigate's port 8971.

If reloading the page triggers the redirect but background requests do not, it could indicate that the frontend JavaScript is not seeing the 302/Location headers on those background requests, possibly due to proxy or browser behavior.

This may be true, but I'm not sure how to verify this or check it's behavior.

[blakeblackshear]

You can see how this is handled in the frontend code here:

frigate/web/src/api/index.tsx

Lines 27 to 37 in e4eac4a

	onError: (error, _key) => {
	if (
	error.response &&
	[401, 302, 307].includes(error.response.status)
	) {
	// redirect to the login page if not already there
	const loginPage = error.response.headers.get("location") ?? "login";
	if (window.location.href !== loginPage) {
	window.location.href = loginPage;
	}
	}

This handler is only on API calls handled by SWR, so it wouldn't work for an image request alone. Are you seeing the 302 with a location header on /api/ routes?

[banduraj78]

In an example of what authelia returns, the responses often look like this:

authelia | time="2025-11-11T13:36:53Z" level=info msg="Access to https://nvr.contoso.local/api/config (method GET) is not authorized to user <anonymous>, responding with status code 302 with location redirect to https://nvr.contoso.local/?rd=https%3A%2F%2Fnvr.contoso.local%2Fapi%2Fconfig&rm=GET" method=GET path=/api/authz/forward-auth remote_ip=10.0.0.1

[blakeblackshear]

You should look at the network tab in the browser to check the headers on the response to ensure the location header is actually there. The browser console would also show any relevant errors.