Ömer

Two more that produce the same rejection and are worth checking before rewriting the proxy config.

The cookie is not coming back. If the CSRF cookie is marked secure and something in the chain is still plain HTTP, the browser will not send it, and a missing token reads as a failed check. Look at the request in developer tools and confirm the cookie is actually on the submission.

Host mismatch. If people reach the site by more than one name — with and without www, a bare address, an internal name — each is a distinct origin and each needs to be in the trusted list, or better, redirect them all to one canonical name.

The canonical redirect is the fix I would reach for. Multiple valid entry points cause this class of problem repeatedly, and not only for CSRF.

Your reasoning is right. The redirect happens in the user's browser, not server to server, so the URL has to be one that browser can reach. localhost means the user's own machine, which is not where your service is.

The fix is to tell the application its public address. Nearly every self-hosted service has a setting for this — variously called the public URL, external URL, base URL or site URL — and the callback is generated from it. Setting it is the whole fix, and applications generate a lot more than callbacks from it: links in emails, absolute URLs in pages, webhook targets. Leaving it wrong produces a long tail of confusing bugs, of which this is the first.

If the service has no such setting, it is deriving the URL from the incoming request, and then this becomes the proxy-header problem: forward the original host and protocol, and make the app trust them.

The requirements the provider is enforcing, so you know what will be accepted:

• Registered in advance. The exact callback URL must be in the provider's application settings, character for character. A trailing slash difference is a rejection.
• HTTPS, for anything not local. This is close to universal now.
• A resolvable public host, since the browser must reach it.

And yes, localhost callbacks are legitimate in one case: an application running on the user's own machine — a desktop app or a command line tool that opens a browser and listens on a loopback port for the redirect. That is a recognised pattern, providers generally allow loopback addresses for it, and many relax the port matching because the tool picks a free port at run time.

What is not legitimate is a server pretending to be that. Your case is a server, so it needs a real address.

One thing worth ruling out before assuming corruption: whether the project is looking for files that moved.

A project that opens empty, or reports errors, sometimes just cannot find its audio because the folder was renamed, moved to another drive, or is on external storage that is not mounted. That looks exactly like corruption and is entirely recoverable by putting things back.

Check the path the project expects before doing anything more drastic.

One thing worth weighing that rarely appears in these comparisons: who maintains it in two years.

A server-rendered application with a small amount of progressive enhancement can be maintained by anybody who knows the backend framework. A single-page front end is a second application with its own build tooling, dependency treadmill and idioms, and it needs somebody who knows that too.

For a small team that is a real constraint, and it is why plenty of teams that could have gone either way are happier having not split the stack.

The counter-argument is hiring: it is easier to find people for the mainstream client-side ecosystem than for a specific backend's templating. Both are legitimate and it depends on your team rather than on the technology.