starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-03-01 11:20:59 +03:00
Code Issues 822 Packages Projects Releases 10 Wiki Activity

When using a reverse proxy, different sessions cannot find each other, breaking remote control #255

New Issue
Closed
opened 2026-02-06 19:30:18 +03:00 by OVERLORD · 7 comments
OVERLORD commented 2026-02-06 19:30:18 +03:00
Owner
Copy Link

Originally created by @hawken93 on GitHub (Jan 10, 2019).

found this while looking at #496
Turns out I could not find any devices to remote control because I was using a reverse proxy, and somehow that breaks the functionality.

I think jellyfin must be looking at the originating ip, and somehow rely on that to identify sessions. Maybe a security measure. But it breaks this..

Originally created by @hawken93 on GitHub (Jan 10, 2019). found this while looking at #496 Turns out I could not find any devices to remote control because I was using a reverse proxy, and somehow that breaks the functionality. I think jellyfin must be looking at the originating ip, and somehow rely on that to identify sessions. Maybe a security measure. But it breaks this..
OVERLORD commented 2026-02-06 19:30:20 +03:00
Author
Owner
Copy Link

@sparky8251 commented on GitHub (Jan 10, 2019):

Poke at various proxy settings like transparent and such. One such setting out to exist that will fix your problem.

It seems unlikely to me that this is a problem with the server. I've found all manner of web apps break in odd ways if I don't set the reverse proxy perfectly.

@sparky8251 commented on GitHub (Jan 10, 2019): Poke at various proxy settings like transparent and such. One such setting out to exist that will fix your problem. It seems unlikely to me that this is a problem with the server. I've found all manner of web apps break in odd ways if I don't set the reverse proxy *perfectly*.
OVERLORD commented 2026-02-06 19:30:21 +03:00
Author
Owner
Copy Link

@hawken93 commented on GitHub (Jan 10, 2019):

I can't make it transparent, that's not possible for my usecase. In my case I'm using apache in front of it

@hawken93 commented on GitHub (Jan 10, 2019): I can't make it transparent, that's not possible for my usecase. In my case I'm using apache in front of it
OVERLORD commented 2026-02-06 19:30:21 +03:00
Author
Owner
Copy Link

@sparky8251 commented on GitHub (Jan 10, 2019):

Well, not claiming transparent is the missing setting. Just that if any setting is, it might not be trivial to fix it in the actual code vs turning on the setting.

@sparky8251 commented on GitHub (Jan 10, 2019): Well, not claiming transparent is the missing setting. Just that if any setting is, it might not be trivial to fix it in the actual code vs turning on the setting.
OVERLORD commented 2026-02-06 19:30:23 +03:00
Author
Owner
Copy Link

@hawken93 commented on GitHub (Jan 10, 2019):

Unless I'm mistaken, I think transparent proxying is something squid can do if it's inline with the traffic. But this is relying on telling iptables to redirect traffic that already has a source and destination ip set. In my case I'm using apache to split a public ip to different internal IPs based on SNI, and it also serves to convert http to https. Apache doesn't fake the external IP and that is also not how reverse proxying is done in general

I think Jellyfin should support being behind such a proxy, and in that case it would perhaps need a setting to trust a server to deliver http requests where the original ip is in an added http header..

@hawken93 commented on GitHub (Jan 10, 2019): Unless I'm mistaken, I think transparent proxying is something squid can do if it's inline with the traffic. But this is relying on telling iptables to redirect traffic that already has a source and destination ip set. In my case I'm using apache to split a public ip to different internal IPs based on SNI, and it also serves to convert http to https. Apache doesn't fake the external IP and that is also not how reverse proxying is done in general I think Jellyfin should support being behind such a proxy, and in that case it would perhaps need a setting to trust a server to deliver http requests where the original ip is in an added http header..
OVERLORD commented 2026-02-06 19:30:24 +03:00
Author
Owner
Copy Link

@sparky8251 commented on GitHub (Jan 10, 2019):

Might be part of the stupid custom HTML server. Yet more reason to switch to Kestrel imo.

@sparky8251 commented on GitHub (Jan 10, 2019): Might be part of the stupid custom HTML server. Yet more reason to switch to Kestrel imo.
OVERLORD commented 2026-02-06 19:30:25 +03:00
Author
Owner
Copy Link

@hawken93 commented on GitHub (Jan 10, 2019):

The client wasn't setting SupportsRemoteControl, investigating the browser console lead me to this:

<VirtualHost bla bla>
    bla bla bla...

    ProxyPass / http://bla:8096/
    ProxyPassReverse / http://bla:8096/
    RewriteEngine On
    RewriteRule /embywebsocket(\?.*)? ws://bla:8096/embywebsocket$1 [P,QSA]
    RewriteRule /socket(\?.*)?        ws://bla:8096/socket$1 [P,QSA]
</VirtualHost>

Turns out that we have to proxy websocket with GET parameters nowadays. And that it's called embywebsocket now, not socket
EDIT: seems like it uses socket for https and embywebsocket for http or something. Lol. So you need both to stay safe
EDIT: have taken a look at apiclient.js and found out that I'm seeing "/socket" because my server URL starts with "https://emby". For most users this will not be the case. This check is buggy and as far as I understand the intention from the developer has been to have the path of the websocket be /embywebsocket. But we get to decide.. :) Both need to be supported to avoid random breakage.

@hawken93 commented on GitHub (Jan 10, 2019): The client wasn't setting SupportsRemoteControl, investigating the browser console lead me to this: ``` <VirtualHost bla bla> bla bla bla... ProxyPass / http://bla:8096/ ProxyPassReverse / http://bla:8096/ RewriteEngine On RewriteRule /embywebsocket(\?.*)? ws://bla:8096/embywebsocket$1 [P,QSA] RewriteRule /socket(\?.*)? ws://bla:8096/socket$1 [P,QSA] </VirtualHost> ``` Turns out that we have to proxy websocket with GET parameters nowadays. ~~And that it's called `embywebsocket` now, not `socket`~~ ~~EDIT: seems like it uses `socket` for https and `embywebsocket` for http or something. Lol. So you need both to stay safe~~ EDIT: have taken a look at apiclient.js and found out that I'm seeing "/socket" because my server URL starts with "https://emby". For most users this will not be the case. This check is buggy and as far as I understand the intention from the developer has been to have the path of the websocket be /embywebsocket. But we get to decide.. :) Both need to be supported to avoid random breakage.
OVERLORD commented 2026-02-06 19:30:26 +03:00
Author
Owner
Copy Link

@hawken93 commented on GitHub (Jan 10, 2019):

Should be documented...

@hawken93 commented on GitHub (Jan 10, 2019): Should be documented...
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#255
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?