Proper Host/Port Formatting in Dockerized Load balanced deployment

[JimboBean 0]

So my deployment is a bit non-standard.. I'm running dockerized Emby behind nginx as a reverse proxy, and it's being hosted from a subdirectory.

https://host.name/emby

for example is how it's accessed.

I'm trying to configure my father's Samsung TV with the Emby app. He lives far away so extracting info about model number etc I may have to do later if needed.

Anyway, it was previously working fine but now I cannot get it to connect, and am unsure what the host and port value should be

I've tried "https://host.name" with no port, or with port set to 443 -- no connection attempts show up in nginx access logs.

If I try "https://host.name" port 80, I see an access log entry where its trying to make a TLS connection so wrong protocol... but attempting

if I try "host.name" port 80 or 443 I see access log entry where its trying to use standard HTTP connection.

So then I tried Emby Connect, but the info it pulls down is "http://host.name:8096" which is probably because Emby is unaware that it's being reverse proxied through nginx and that it's truly outward facing host is "https://host.name[:443]" and is self reporting the other host which does not work...

Effectively, Id like to know what the proper host/port values are to use? I've tried adding the subdirectory with trailing slashes and without.. and FWIW, using "https://host.name" on Apple TV and Roku and Fire Sticks, I've had no issues. Certificate is valid, doesn't expire anytime soon. I'm running out of ideas what could be amiss, it feels like some validation issue on the Samsung TV client seeing as I don't see any attempts at connections with certain configurations and UI quickly fails, while faulty configurations take time to load and make attempts to connect.

Is there a way I can configure what WAN URL is being advertised by emby connect? Or is there something I'm overlooking in configuring a Samsung TV manually? This has worked in the past on the same exact television, the only thing that has changed is I've enabled Emby Premiere and updated the server. This is the only device i've had trouble with

[Q-Droid 652]

1 hour ago, JimboBean said:

Is there a way I can configure what WAN URL is being advertised by emby connect? Or is there something I'm overlooking in configuring a Samsung TV manually? This has worked in the past on the same exact television, the only thing that has changed is I've enabled Emby Premiere and updated the server.

The host and port to use should be the public ones. Have you setup the actual public domain and ports within emby? This is what gets advertised to apps.

I don't know how well you can expect the URI location "/emby" to work for the proxy. I think most people use subdomains because of problems with paths and "/emby" is one the paths in the server.

What do you mean by "updated the server"?

Edited November 29, 2023 by Q-Droid

[JimboBean 0]

1 minute ago, Q-Droid said:

Have you setup the actual public domain and ports within emby? This is what gets advertised to apps. 

I don't know how well you can expect the URI location "/emby" to work for the proxy. I think most people use subdomains because of problems with paths and "/emby" is one the paths in the server.

What do you mean by "updated the server"?

by Updated the server, I mean to the latest version (pulled latest docker image)

In settings i've got:

Server > Network > External Domain I've set "https://host.name/emby"
Server > Network > Public https port number = 443

However in the dashboard page I still see WAN as https://host.name:8096 even after restarting emby.

[JimboBean 0]

29 minutes ago, JimboBean said:

by Updated the server, I mean to the latest version (pulled latest docker image)

In settings i've got:

Server > Network > External Domain I've set "https://host.name/emby"
Server > Network > Public https port number = 443

However in the dashboard page I still see WAN as https://host.name:8096 even after restarting emby.

Exceeded edit time... here is some more info from access logs:

 I see this when the host is set to "host.name" (no URI schema) and port is set to "80"

"GET /emby/system/info/public HTTP/1.1" 301 162 "-" "Mozilla/5.0 (SMART-TV; LINUX; Tizen 4.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 TV Safari/537.36"

Which I see is getting 301 redirected to HTTPS

Then I see a 400 getting sent back to the client when it tries to pull from HTTPS

"GET /emby/system/info/public HTTP/1.1" 400 248 "-" "Mozilla/5.0 (SMART-TV; LINUX; Tizen 4.0) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 TV Safari/537.36"

Which makes me think the samsung tv  emby client is in error, but the error in the UI is not very descriptive just connection failed. (I'd understand this for a 5xx response or a 401 or 403 but not 400..)

For what its worth the status page its grabbing is available at both `/emby/system/info/public` and `/emby/emby/system/info/public` so I'd think the subpath I'm using should work (and has before and currently on all other devices).

If all else fails... I suppose I can just host it on the root of a different domain on 8443 (only have one IP) and just proxy back to the same server and host it simultaneously on both. I'll give that a shot tomorrow when my dad wakes up again, I don't have any TV's at my disposal to test.

Edited November 29, 2023 by JimboBean

[Q-Droid 652]

External domain in the server network settings should only be the domain portion, no protocol or paths.

I've seen posts in the forums mention that when non-standard ports are used the URL is constructed wrong. Like: "https://host.domain/path:port" instead of "https://host.domain:port/path". I can't remember if this was in apps, the server or both. Perhaps omitting the port on the client when 80 or 443 are used would get you closer. But again, subdomains are the preferred method for reverse proxies for these reasons.

9 hours ago, JimboBean said:

For what its worth the status page its grabbing is available at both `/emby/system/info/public` and `/emby/emby/system/info/public` so I'd think the subpath I'm using should work (and has before and currently on all other devices).

The first would be directly to the emby server and the second one is the proxied route, right? It might work but there is no guarantee that "/emby/emby" would be reliable if there is a piece of code in the server that dedups the path. You might have to rewrite the responses. Browsers are easy but apps have more dependencies on the config.

[SamES 891]

27 minutes ago, Q-Droid said:

I've seen posts in the forums mention that when non-standard ports are used the URL is constructed wrong. Like: "https://host.domain/path:port" instead of "https://host.domain:port/path". I can't remember if this was in apps, the server or both.

Knowing how the clients construct the connection address, I expect this is exactly what would happen as it's not expecting a path.   

Doing a test somewhat proved this.

Entering this, and leaving the Port at the default 8096

Edit: See comments in next post

Results in: https://my.emby.server:1234:/emby:8096

However, if you make sure you clear the Port field so that it is blank then it will use the Host address/path exactly as entered.  Try that!

Edited November 29, 2023 by SamES
Struck out error - refer to next post

[SamES 891]

I just noticed a typo (extra colon) in my previous test.  Removing that error and entering it correctly (https://my.emby.server:1234/emby) works correctly regardless of the value entered in the port field.

The way the host field is converted has been improved in recent releases which means this is more reliable - I actually expected it to work in my first test and was surprised when it didn't, but the typo explains why.

Please let me know what app/client version you are using as it may not have this recent change.  If that is the case, then please try the method by clearing the Port field as that may working in the older clients.

[Q-Droid 652]

15 minutes ago, SamES said:

I just noticed a typo (extra colon) in my previous test.  Removing that error and entering it correctly (https://my.emby.server:1234/emby) works correctly regardless of the value entered in the port field.

The way the host field is converted has been improved in recent releases which means this is more reliable - I actually expected it to work in my first test and was surprised when it didn't, but the typo explains why.

Would the call to "/emby/system/info/public" override this value in the client app after it connects or does the server also allow for paths in the domain, and if so which version?

 

[JimboBean 0]

25 minutes ago, SamES said:

Please let me know what app/client version you are using as it may not have this recent change.  If that is the case, then please try the method by clearing the Port field as that may working in the older clients.

I will try to get info on my dad's TV/client version next I speak to him (hopefully later this evening). This had worked flawlessly on the same TV, and I know I've configured it given my current deployment on an Apple TV within the last week and left the port field empty and that worked just fine using simply "https://host.tld" (not even including the /emby path) with no port.

22 minutes ago, SamES said:

I just noticed a typo (extra colon) in my previous test.  Removing that error and entering it correctly (https://my.emby.server:1234/emby) works correctly regardless of the value entered in the port field.

If I understand correctly, I can fill in the host as https://host.tld:443/emby with empty port field on even older versions (ones that construct connection string differently than at present) and the client connection string may work?

1 minute ago, Q-Droid said:

Would the call to "/emby/system/info/public" override this value in the client app after it connects or does the server also allow for paths in the domain, and if so which version?

FWIW this is how I'm proxying requests in nginx

location ^~ /emby {
    proxy_pass http://192.168.1.50:8096;
}

 

Which should not duplicate '/emby' when proxying

Thanks both @SamES and @Q-Droidfor the input! I will try to get more useful diagnostics info about the client app version and TV model

In the interim I've also set up a different domain hosting it on root.. not sure what the implications can be for the app server not being aware of being hosted on a second domain but some smoke testing shows it working for me in browser just fine in this configuration alongside the existing.

[SamES 891]

I'm guessing that if you want no port, then you will have to make the port field blank regardless of the client version.

It's a good question regarding the endpoint paths.  I suspect /emby/system/info/public will just be appended to the connection address so I'm hopeful it will work fine, but I don't have an easy way to test that without setting up a reverse proxy in this same way.

[Q-Droid 652]

26 minutes ago, SamES said:

I'm guessing that if you want no port, then you will have to make the port field blank regardless of the client version.

It's a good question regarding the endpoint paths.  I suspect /emby/system/info/public will just be appended to the connection address so I'm hopeful it will work fine, but I don't have an easy way to test that without setting up a reverse proxy in this same way.

What I meant about "/emby/system/info/public" was if the response from that call by the client would override the server connection details that were entered manually? As I understand it the app based clients use the response from that call to configure/update LAN and WAN connection settings. Which is why it's important to make sure the server Network settings for the public side are correct and match proxied actual. Unless it's different in newer versions.

 

 

Edited November 29, 2023 by Q-Droid

[SamES 891]

29 minutes ago, Q-Droid said:

What I meant about "/emby/system/info/public" was if the response from that call by the client would override the server connection details that were entered manually? As I understand it the app based clients use the response from that call to configure/update LAN and WAN connection settings. Which is why it's important to make sure the server Network settings for the public side are correct and match proxied actual. Unless it's different in newer versions.

 

 

Ah yes, that's possible