Can Jellyfin Work Behind a Reverse Proxy on a Subpath?

Yes. Jellyfin can work behind a reverse proxy on a subpath such as https://example.com/jellyfin, but Jellyfin and the proxy must agree on the same base path.

A subpath failure usually looks like a half-working site: the login page may load while JavaScript, images, WebSockets, redirects, or native clients fail. Test the path in layers—Base URL first, proxy route second, forwarded headers and client address last—so you can tell a path mismatch from a TLS or proxy-identity problem.

Make the Jellyfin Base URL Match the Public Subpath

Set Jellyfin's Base URL to the exact public prefix you intend to use, for example /jellyfin. Do not add a different internal prefix merely because the proxy uses a named location block; the browser-visible path and Jellyfin Base URL need to describe the same application root.

Jellyfin's Apache reverse-proxy documentation explicitly provides a subpath example and instructs administrators to set the Base URL to /jellyfin before connecting clients to that full address. official subpath example

Restart Jellyfin after changing the Base URL, then open the public subpath in a fresh private browser window. If the initial redirect immediately drops /jellyfin or doubles it, fix the Base URL before touching WebSocket or authentication settings.

Route the Same Prefix Through the Reverse Proxy

Configure the reverse proxy so requests beginning with the public prefix are forwarded to Jellyfin without inventing an extra path transformation. The simplest design is one public prefix, one matching Jellyfin Base URL, and one upstream service.

Caddy's Jellyfin guide shows the same pattern: configure the Jellyfin base path, redirect the bare prefix to the trailing-slash form, and proxy requests under that prefix to the Jellyfin backend. matching base path and proxy route

If the browser receives a 404 from the proxy before Jellyfin logs the request, the route is wrong at the proxy layer. If Jellyfin receives the request but generates links without the prefix, the Base URL is wrong at the application layer. Keep those two failure signatures separate.

Check Static Assets and WebSockets, Not Just the Login Page

A successful HTML response is not enough to call the subpath configuration healthy. Open developer tools or the proxy log and verify that JavaScript, CSS, image, API, and WebSocket requests all remain under the same public prefix.

Jellyfin's reverse-proxy examples include WebSocket handling because interactive clients maintain a socket connection in addition to ordinary HTTP requests. A proxy rule that handles only page requests can therefore appear correct until playback status, session updates, or live UI behavior breaks. reverse-proxy requirements

The pass condition is simple: no repeated 404/502 responses for prefixed assets, the WebSocket upgrades successfully, and navigation does not escape to the site root. If one request class alone fails, repair that proxy rule instead of changing Jellyfin's library or authentication settings.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Preserve Client Identity Through the Proxy

After the path works, verify forwarded client information. Jellyfin uses the proxy trust configuration to decide whether forwarded addresses and protocols should be accepted, which affects local-versus-remote behavior and external-access rules.

The Jellyfin networking guide warns that forwarded headers from an untrusted proxy are discarded and recommends configuring the proxy address under Known Proxies. Known Proxies setting A separate client-IP verification check is useful when the site works but every request appears to originate from the proxy.

Do not solve an identity problem by trusting every private subnet or every forwarded header. Add only the actual proxy hop or controlled proxy network, then compare one LAN and one remote request in Jellyfin logs to confirm they are classified as expected.

Test Browser and Native Client Addresses Separately

Enter the complete server address, including the subpath, when a Jellyfin client asks for the server URL. A client saved as https://example.com cannot infer that Jellyfin lives under /jellyfin.

Test one browser and one native client from the LAN, then repeat through the public hostname. If the hostname works but direct local IP access does not, that may be expected when the proxy route and certificate depend on the hostname; hostname-versus-IP testing helps isolate that case without weakening the proxy.

Stop when the prefixed URL survives login, navigation, WebSocket use, and playback on the clients you actually support. If only one client fails while the browser and other clients pass, treat it as a client-address or client-compatibility problem rather than rewriting a working proxy configuration.