External Access DNS

[PeteLocky 22]

so my emby server is behind a reverse proxy (this also handles the SSL stuff) so i want it like so, https://domain/emby however the thing keeps adding the port number after, https://domain/emby:xxxx and there seems to be no way to fix this in the settings ? i do NOT want the port bound to the domain, how is this achieved ? i have added a screenshot for reference

[Luke 42079]

Hi there, how did you configure advanced settings?

[PeteLocky 22]

thanks for the reply Luke, i have attached screenshots (3 of them) showing the advanced settings, cheers

Edited February 5, 2019 by PeteLocky

[feerlessleadr 173]

thanks for the reply Luke, i have attached screenshots (3 of them) showing the advanced settings, cheers

 

That second screenshot has your full domain name - might want to take that down, blank it out, and re-attach.

 

 

It looks like you need to modify your public http & https port in your advanced settings to be 80 (default port for http traffic) and 443 (default port for https traffic). This way, when you go to http://yourdomain.com/emby, you will be automatically going over port 80 or 443.

 

This also assumes that your reverse proxy is not already set up to handle this incoming traffic, which would then route to your local emby install.

Edited February 5, 2019 by feerlessleadr

[PeteLocky 22]

That second screenshot has your full domain name - might want to take that down, blank it out, and re-attach. 

cheers totally missed that

[feerlessleadr 173]

no problem - I edited my post, but what happens when you go to https://yourdomain.com/emby in your browser?

 

Does your reverse proxy route you to emby correctly?

[PeteLocky 22]

no problem - I edited my post, but what happens when you go to https://yourdomain.com/emby in your browser?

 

Does your reverse proxy route you to emby correctly?

 

the reverse proxy is absolutely fine it is just where on the server dashboard it shows the remote wan access it auto adds the port number AFTER the dns, e.g https://domain.uk/emby:1234

 

i cant simply remove the wan port from the config as it will not save the page, everytime i click the wan link i have to manually remove the port number from the url bar

 

manually go to  domain.uk/emby it works fine, it is jsut annoying from within the server dash i have to keep changing the url bar

Edited February 5, 2019 by PeteLocky

[feerlessleadr 173]

the reverse proxy is absolutely fine it is just where on the server dashboard it shows the remote wan access it auto adds the port number AFTER the dns, e.g https://domain.uk/emby:1234

 

i cant simply remove the wan port from the config as it will not save the page, everytime i click the wan link i have to manually remove the port number from the url bar

 

manually go to  domain.uk/emby it works fine, it is jsut annoying from within the server dash i have to keep changing the url bar

 

ah ok - I don't believe you can remove it, but you can change the public http & https ports to 80 & 443 respectively, then your address on the dashboard it would be https://domain.uk/emby:443

 

I don't believe that you can have the port removed on the dashboard (Luke can correct me if I'm wrong there). 

[PeteLocky 22]

ah ok - I don't believe you can remove it, but you can change the public http & https ports to 80 & 443 respectively, then your address on the dashboard it would be https://domain.uk/emby:443

 

I don't believe that you can have the port removed on the dashboard (Luke can correct me if I'm wrong there). 

 

if that is the case i guess it is what it is, i know it might seem so small, maybe a simple tick-box could be applied to make the wan access bit reverse proxy compatible (e.g tick the box for reverse proxy and it simply removes the port from that particular link?)

[Luke 42079]

You'll need to remove the /emby from external domain as that's not supported. The apps will actually add that on their own anyway.

[Riddler84 54]

Is there actually a solution for this? Because I have the exact same problem right now.

I have a reverse proxy which is managing all the certificate stuff. And it works absolutely flawless if I visit the URL manually. It has the following structure: https://domainname.net/emby/
I'm using a subfolder, because I'm using the same domainname to address several services on my server via subfolders. I point them internally to their localhost:port addresses. So the port mustn't be added to the URL.

But Emby puts it automatically behind the URL which is used for external access and presented in the dashboard. Is there any way to prevent this?

Edited December 17, 2022 by Riddler84

[pwhodges 2012]

Emby doesn't support being run behind a folder URL, as Luke says in the post above yours.  This is why the advice is to use a subdomain. 

Is there a reason you can't use a subdomain?

Paul

[rbjtech 5284]

I do actually run emby on my internal network behind a reverse proxy via a sub folder and it works just fine - externally I use a subdomain.

So it may just be reverse proxy config issue - maybe look at the nginx emby config pages on the forum - but as Paul says above - by far the easiest way is to simply add a subdomain to your existing domain - add an external DNS A record - and away you go.

[Riddler84 54]

17 hours ago, pwhodges said:

Emby doesn't support being run behind a folder URL, as Luke says in the post above yours.  This is why the advice is to use a subdomain. 

Is there a reason you can't use a subdomain?

Paul

It does. I have absolutely no problem reaching Emby via the subfolder URL, because the reverse proxy is pointing at the localhost with its port and without any subfolders (The reverse proxy, Caddy, is running on the same machine). It's just that Emby puts the port after the remote URL in the dashboard. And that's what is used for Emby Connect for example. 

It's the same with a subdomain or any other normal domain by the way. Whatever URL I set in the network settings, the port will always be added automatically at the end of the URL. And with it, the URL isn't reachable. I have to manually enter it on any client to remove the port.

Edited December 18, 2022 by Riddler84

[pwhodges 2012]

So you say it supports it except when it doesn't...

The documentation alongside the domain field in the Network settings explicitly says "domain name", not URL or anything else.  A domain followed by a folder is not "a domain name".

Maybe in time they will change things so that it works the way you want in all circumstances.  But rather than wait for that, why not just make the change that would fix it for you?

Paul

[Riddler84 54]

18 minutes ago, pwhodges said:

So you say it supports it except when it doesn't...

Ehm, no. I didn't. It's fully working under all circumstances. The only problem is, that the URL that Emby produces to print it out on the dashboard as remote URL isn't working, because it's not the right URL. It is adding a port which makes the URL unusable. And therefore no one can connect to the server vie the Emby Connect feature.

21 minutes ago, pwhodges said:

The documentation alongside the domain field in the Network settings explicitly says "domain name", not URL or anything else.  A domain followed by a folder is not "a domain name".

If you use a subdomain or a subfolder doesn't matter here. As I wrote above, it doesn't work with a single domainname or a subdomain either. I could literally just write "xyz" in the domain name field and Emby would produce "https://xyz:60010". There are no checks or whatever. It just takes the input from the domainname field and puts the protocol before it and the chosen port behind it. Done. I mean, is here anyone, who has this working without Emby putting the port at the end?

21 minutes ago, pwhodges said:

But rather than wait for that, why not just make the change that would fix it for you?

Well, please tell me how. How can I tell Emby not to put the port at the end? That's what I wanted to know in the first place.

[pwhodges 2012]

Emby's adding the port at the end is only an issue if you have a folder, because a port is not valid in that position.  Following the domain name with the port is entirely fine.  That's why I say there is a difference - not using a folder prevents there being a problem. 

In my case I specify my domain (which includes a subdomain) and specify the public port numbers, i.e. the ports used by the proxy, to be 80 & 443 as you'd expect.  The dashboard then shows https://subdomain.domain.name:443 which is perfectly correct - so it works.

I suppose it would not be hard for the devs to make Emby to check for the end of the domain name and insert the port there, where it belongs; https://domain.name:443/folder would work correctly.  But they don't, so avoiding the issue by not using a folder is the way to go.

Paul

Edited December 18, 2022 by pwhodges

[Riddler84 54]

Again, it's not because of the subfolder. As I already wrote above, I have tested it with a normal domain for example, mydomain.net, and with a subdomain sub.mydomain.net.

14 minutes ago, pwhodges said:

Following the domain name with the port is entirely fine

Try reaching google.com and adding a random port to it. It only works with port 80 or 443, because browsers accept and forward them. Anything other than that will be rejected. So to make this work, I have to change the SSL port in Emby to 443, so that the browser let it pass with the port added to the URL, even though it's totally unnecessary to add it.

The other option would be to configure my reverse proxy to listen to my server URL, but with the port I chose in Emby added to it. This way it would only work with the port added to it, which would be something I wanted to avoid with a custom domain in the first place

Both is pretty unintuitive, because a user would expect, that the URL Emby produces from the network settings is the URL which is actually working. I mean why giving us the option to add a custom domainname and then adding the default port (which isn't 443) to it, so that the URL isn't working without removing it. If I wanted to use a it with a port, I would just use my public IP address.

[pwhodges 2012]

1 hour ago, Riddler84 said:

Again, it's not because of the subfolder.

It is exactly so, because putting the port after a folder (which, right or wrong, we know Emby is doing) is simply wrong syntax.

1 hour ago, Riddler84 said:

Try reaching google.com and adding a random port to it. It only works with port 80 or 443, because browsers accept and forward them.

No, not because "browsers accept them" - the reason is that only the correct ports will work; if you write a random address on a letter it will not get delivered correctly, and ports are part of the address in this instance.  Suggesting a "random" port is ridiculous; the port has a meaning, and selecting a random one is bound to be nonsensical.  Oh, and ports are not forwarded - ports listen, and messages sent through them may be forwarded (to whatever port the destination machine is listening on).

1 hour ago, Riddler84 said:

So to make this work, I have to change the SSL port in Emby to 443

What?  The port used for external access is that listened to by the reverse proxy (typically 443).  The reverse_proxy statement in your Caddy config then specifies how Caddy will speak to Emby, including the port being listened to by Emby.  In my system, Caddy listens on 443 (and 80, but only to redirect to 443), and forwards to Emby on port 8096 (I link Caddy to Emby using http, not https).  But you must already know this, because you have Emby and Caddy on the same machine, so they have to be using different ports.

Paul

[Riddler84 54]

1 hour ago, pwhodges said:

It is exactly so, because putting the port after a folder (which, right or wrong, we know Emby is doing) is simply wrong syntax.

I know, that this isn't the right syntax. That's why I didn't want Emby to include the port at all. But not only for subfolders. Same with subdomain or with the plain domainname. I just want Emby to not produce an URL with port, because such an URL did not work. Why is that so hard to understand?

1 hour ago, pwhodges said:

Suggesting a "random" port is ridiculous; the port has a meaning, and selecting a random one is bound to be nonsensical.

Of course not "random". As you could see I configured Emby to listen on port 60010. And that's working without a problem. Everything is working without a problem. I just can't get the port out of the URL which is Emby building, because it just doesn't work. I just want to have an URL without any port added to it. Because that's what a custom domain is for. 

1 hour ago, pwhodges said:

What?  The port used for external access is that listened to by the reverse proxy (typically 443).  The reverse_proxy statement in your Caddy config then specifies how Caddy will speak to Emby, including the port being listened to by Emby.  In my system, Caddy listens on 443 (and 80, but only to redirect to 443), and forwards to Emby on port 8096 (I link Caddy to Emby using http, not https).  But you must already know this, because you have Emby and Caddy on the same machine, so they have to be using different ports.

Ok, listen..

I have a domain for example: https://my-server.com. I configured Caddy to forward to Emby under localhost:60010. So if I enter the domain, I see Emby. Everything's good. That's what I want to have. But the link that Emby is showing in the dashboard is https://my-server.com:60010. And Caddy can't handle that port, as you said yourself, because unless further configuration it only handles the default ports like 80 and 443.

But what I want is that Emby is simply showing me a usable URL. Or just let me choose if I want the port added to my custom domainname. I think it's pretty pointless to add the port at all, if I fill in a custom domain in the network settings. Because usually you don't want to use your domain with a port. It's ok (and needed) for IP addresses, but other than that, why not just leave it out?

Just for clarification. My only problem is, that Emby is building a link for its dashboard, which isn't usable for custom domain names without further configuration and inconveniences.

I mean, you say you're using Embys default port (8096). So, your dashboard URL must be: https://yourdomain.com:8096. Right? So you have to configure Caddy in a way, that it accepts that URL with this port, because otherwise you get an error.

[pwhodges 2012]

1 hour ago, Riddler84 said:

I mean, you say you're using Emby's default port (8096). So, your dashboard URL must be: https://yourdomain.com:8096. Right? So you have to configure Caddy in a way, that it accepts that URL with this port, because otherwise you get an error.

Wrong.

Here is my dashboard:

 

And here are the settings in Network which give that:

 

My Caddyfile contains (for this site - there are many others) just:

xxxx.xxxxxxxx.xxx {
	header Accept-Ranges "none"
	reverse_proxy http://yyyyyyy.yyyy.yyy:8096 
}

I can't think of anything else to say...

Paul

Edited December 18, 2022 by GrimReaper
Hid domains

[rbjtech 5284]

Got a little lost in the thread - but as I'm sure you are aware, a reverse proxy terminates the WAN connection and forwards the request internally on whatever port you specify.

Like Paul - I connect using 443 (thus no need for any port to be specified) and then nginx forwards using 8096 (http) - thus like Paul's - my dashboard WAN url says :443 after it - but it has no reason to.

Note emby IS listening internally (locally/lan) on port 8920 for https - so the dashboard could be a little clearer on that imo.  It's your RP that is listening on (80) 443 not emby.

[Luke 42079]

@Riddler84please let us know if this helps. Thanks!

[Riddler84 54]

20 hours ago, pwhodges said:

And here are the settings in Network which give that:

That's what I said above about the two solutions. You have chosen to set the public HTTPS port to 443 to make the URL that Emby is producing work. Because your screenshot clearly shows the port at the end of your remote (WAN) access URL. The one you manually set. But there is still no way to remove the port at all from the produced URL. That's the single thing I want!

I'm coming from Plex and there you can just enter a remote URL, which is used by Plex, and you're done. There's no need for automatically building the URL out of 3 components. I don't really see a reason for Emby to do this, but maybe someone can explain to me, why this is a good idea. In my case and environment, it produces a URL, which is not usable, unless I change the port to 443.

[pwhodges 2012]

If you remove the port from the URL it will default to 80 or 443 for thhp/https, so having the port or not is not an issue.  The issue is that Emby doesn't put it at the end of the domain, but at the end of the URL - which produces nonsense.

You have the choice of waiting until the developers decide to change this (grumbling meanwhile) or simply changing your URL setup to one that works without an issue (presumably being happier when it works).

Paul