External access not available anymore

[Andy777 21]

Hi,

 

Earlier: Setup Emby for Kodi device on local network. Everything works. Go away from the local network. Everything works.

 

Now: Setup Emby for Kodi device on local network. Everything works. Go away from the local network. NOTHING WORKS.

 

 

Earlier Emby for Kodi would automatically find out the external access address of the server (like I have with dynamic dns service and the name is inserted in the server). Now it doesn't. It only tries to connect to the local IP which is not available on the external networks.

 

My external access is configured right. ET and browser do work.

 

A

 

 

[Tur0k 143]

Certificate problem?

 

 

Sent from my iPhone using Tapatalk

[Luke 37163]

If other apps work over https then it sounds like a certificate problem.

[Andy777 21]

If other apps work over https then it sounds like a certificate problem.

Nope. Certificates are installed and trusted. Emby for Kodi certificated checking is off. This is somethin that has worked over a year, but not anymore.

A

[Andy777 21]

Earlier Emby for Kodi would see/change the server address to the external one.

 Now: It offers internal lan address even when connection is from outside.

 

That goes for all my mobile devices that have worked  (with Kodi for Emby) until now in external networks (for more than a year). Certificate problem is highly unlikely.

 

Andy777

[Angelblue05 4130]

Provide your Kodi log, you can PM if necessary.

 

 

Sent from my iPhone using Tapatalk

[Tur0k 143]

Do you have NAT reflection/NAT loopback enabled on your firewall/router?

 

I have a PFSENSE firewall and I have NAT reflection enabled. This allows me to point internal and external devices to the same public subdomain and gain access to my resources.

 

 

Sent from my iPhone using Tapatalk

[Andy777 21]

Provide your Kodi log, you can PM if necessary.

 

 

Sent from my iPhone using Tapatalk

 

 

Sorry for jumping the gun. At least the main problem now seems that my previously well functioning nginx reverse proxy has started acting up.

 

Thanks for all that were ready to help!

 

A

[Andy777 21]

... The story continues. It wasn't nginx by it self, but with the change in functionality of this setting in Emby server:

 

 

Earlier when it was checked, Emby would advertise to use https and nginx would do the SSL termination and redirection to non-ssl port.

 

Now (when it actually does a redirect):

• If it is checked, it causes a redirect loop with nginx.
• If it NOT checked, Emby advertises non-https external url (and in my case that port is blocked).

The value of advertised external path can be checked in Emby for Kodi addon in userdata/addon_data/plugin.video.emby/data.txt

 

Soooo.... Now I need to either manipulate Emby server to advertise https (but not redirect), OR some nginx setting to rewrite the value on the fly (so the Kodi addon sees it as https) OR a manual setting to use https when in _external_ network in the Kodi addon.

 

No-one else with nginx + https only + kodi with the same problem?

 

BR

A

[Luke 37163]

@@Karbowiak how are you handling this?

[Tur0k 143]

I think I may have had similar experiences to you. I also run a reverse proxy (HAProxy on my PFsense firewall). I also SSL terminate on my RP. My publicly trusted SSL certificate is hosted on my RP. I have my Acme client installed my my PFsense firewall and it is setup to automatically renew entry 60 days and restart the reverse proxy automatically.

 

A few revisions ago I had to create and add a self-signed cert to my Emby server (server dashboard - advanced - custom SSL certificate path, certificate password) as I would get a message saying I had to have a certificate listed if I had "server dashboard - advanced - Require HTTPS for external connections" enabled, and tried to save any new changes to the page.

 

I also had to setup two separate backend servers on my RP for Emby.

 

The first is for internal use. It is pointed to port 8096 and does not pass client IP address (this part is important).

 

At one point I had the pass client ip setting to host server enabled for internal network clients and this caused communication issues because the Emby server was trying to connect to the client directly while the client was ready to receive communications from the reverse proxy not directly from the Emby server.

 

The second is for public Internet clients. This backend server is setup to pass client IP address.

 

In my front end, I defined ACLs that:

1. identified a request for my Emby server based on the URL request.

2. Identified if the request was sourced from one of my internal networks.

 

I then created actions in my front end that would:

1. Direct to my internal Emby backend server if, a request is sourced from an internal network and for my Emby server.

 

2. Direct to my external Emby backend server if, a request is for my Emby server.

 

3. Redirect to a dummy IP address and a dummy port for any URL request that doesn't have another action listed for it (this is meant to misdirect common port scanning and brute force attacks).

 

Sent from my iPhone using Tapatalk

Edited October 23, 2017 by Tur0k

[pir8radio 1292]

... The story continues. It wasn't nginx by it self, but with the change in functionality of this setting in Emby server:

 

 

Earlier when it was checked, Emby would advertise to use https and nginx would do the SSL termination and redirection to non-ssl port.

 

Now (when it actually does a redirect):

• If it is checked, it causes a redirect loop with nginx.
• If it NOT checked, Emby advertises non-https external url (and in my case that port is blocked).

The value of advertised external path can be checked in Emby for Kodi addon in userdata/addon_data/plugin.video.emby/data.txt

 

Soooo.... Now I need to either manipulate Emby server to advertise https (but not redirect), OR some nginx setting to rewrite the value on the fly (so the Kodi addon sees it as https) OR a manual setting to use https when in _external_ network in the Kodi addon.

 

No-one else with nginx + https only + kodi with the same problem?

 

BR

A

 

Something doesn't sound right, post your nginx config.

[KMBanana 84]

Something doesn't sound right, post your nginx config.

I haven't been able to look into it closely so I don't have any logs atm, but I think I'm encountering the same thing.  In my case I noticed remote chromecasts stopped working after the change from "advertise https" to "force https".  The Emby app will come up on the device you cast to but will just load forever.  When I saw this thread I tried testing with Kodi but could not connect to my server remotely.  Web app and Android mobile app both work though.  

 

The Remote (WAN) access: setting on my Emby dashboard does look correct though, it's the correct domain and includes https and port 443.  

 

Here's my nginx config

server {
listen 80;
server_name _;
return 301 https://$host$request_uri;
}


# main server block
server {
listen 443 ssl default_server;
add_header Strict-Transport-Security "max-age=31536000";


root /config/www;
index index.html index.htm index.php;


server_name _;


ssl_certificate /config/keys/letsencrypt/fullchain.pem;
ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
ssl_dhparam /config/nginx/dhparams.pem;
#trimmed ssl ciphers for brevity;
ssl_prefer_server_ciphers on;


client_max_body_size 0;


   location ~ /.well-known {
                root /var/www/html;
                allow all;
        }
   location ^~ / {
        internal;
    }
   location /notEmby/ {
rewrite /notEmby/(.*) /$1 break;
proxy_pass http://192.168.1.02:8096; # Local emby ip and non SSL port
proxy_hide_header X-Powered-By;
proxy_set_header Range $http_range;
proxy_set_header If-Range $http_if_range;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
#Next three lines allow websockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}

[Angelblue05 4130]

Ok then provide your Kodi log to make sure I didn't bork something. Thank you.

 

 

Sent from my iPhone using Tapatalk

Edited October 24, 2017 by Angelblue05

[Andy777 21]

Something doesn't sound right, post your nginx config.

 

nginx is used for Emby only. I'm masking my real domain address for this posting as  "my.domain.internet", but my certificate is created for the true FDQN.

• Router redirects external 8920 to internal 192.168.0.5:9999 where nginx listens https
• nginx terminates SSL 
• nginx redirects unencrypted connection to 127.0.0.1:8096 (where Emby listens)
• 8096 is NOT OPEN on the router as I don't want unencrypted external traffic
• I only use nginx because mono linux SSL implementation crashes all the time (otherwise I could just connect directly to emby ssl)

nginx.conf:

user  nginx;
worker_processes  1;

error_log  /mnt/data/emby/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /mnt/data/emby/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

./conf.d/emby.conf:

msrv@MSRV:/etc/nginx/conf.d$ cat emby.conf
server {
        server_name my.domain.internet;
        listen 9999 ssl;

        ssl_certificate                 /mnt/data/emby/emby.crt;
        ssl_certificate_key             /mnt/data/emby/emby.key;
        ssl_prefer_server_ciphers       On;
        ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers                     'AES256+EECDH:AES256+EDH:!aNULL';
        #ssl_stapling                    on;
        resolver                        8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout                5s;
        #ssl_stapling_verify             on;
        #ssl_trusted_certificate         /mnt/data/emby/emby.pem;
        keepalive_timeout               180;

        # This is for strict transport security HSTS
        # add_header                    Strict-Transport-Security max-age=31536000;

        client_max_body_size 1024M;

        location / {
                # Send traffic to the backend
                proxy_pass http://127.0.0.1:8096;
                proxy_buffering off;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Proto $remote_addr;
                proxy_set_header X-Forwarded-Protocol $scheme;
                proxy_redirect off;

                # Send websocket data to the backend aswell
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

This config has worked perfectly for about 1.5 years (the time I have been using nginx).

Now the "require https" setting in emby server causes a redirect loop: nginx sends unencrypted to emby -> emby redirects to SSL 

 

If I uncheck "require https" all other clients work execept emby for Kodi.

 

@@Angelblue05 : I'll send logs in pm within an hour.

 

BR,

Andy777

[pir8radio 1292]

nginx is used for Emby only. I'm masking my real domain address for this posting as  "my.domain.internet", but my certificate is created for the true FDQN.

• Router redirects external 8920 to internal 192.168.0.5:9999 where nginx listens https
• nginx terminates SSL 
• nginx redirects unencrypted connection to 127.0.0.1:8096 (where Emby listens)
• 8096 is NOT OPEN on the router as I don't want unencrypted external traffic
• I only use nginx because mono linux SSL implementation crashes all the time (otherwise I could just connect directly to emby ssl)

nginx.conf:

user  nginx;
worker_processes  1;

error_log  /mnt/data/emby/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /mnt/data/emby/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

./conf.d/emby.conf:

msrv@MSRV:/etc/nginx/conf.d$ cat emby.conf
server {
        server_name my.domain.internet;
        listen 9999 ssl;

        ssl_certificate                 /mnt/data/emby/emby.crt;
        ssl_certificate_key             /mnt/data/emby/emby.key;
        ssl_prefer_server_ciphers       On;
        ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers                     'AES256+EECDH:AES256+EDH:!aNULL';
        #ssl_stapling                    on;
        resolver                        8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout                5s;
        #ssl_stapling_verify             on;
        #ssl_trusted_certificate         /mnt/data/emby/emby.pem;
        keepalive_timeout               180;

        # This is for strict transport security HSTS
        # add_header                    Strict-Transport-Security max-age=31536000;

        client_max_body_size 1024M;

        location / {
                # Send traffic to the backend
                proxy_pass http://127.0.0.1:8096;
                proxy_buffering off;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-Proto $remote_addr;
                proxy_set_header X-Forwarded-Protocol $scheme;
                proxy_redirect off;

                # Send websocket data to the backend aswell
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

This config has worked perfectly for about 1.5 years (the time I have been using nginx).

Now the "require https" setting in emby server causes a redirect loop: nginx sends unencrypted to emby -> emby redirects to SSL 

 

If I uncheck "require https" all other clients work execept emby for Kodi.

 

@@Angelblue05 : I'll send logs in pm within an hour.

 

BR,

Andy777

 

 

Just curious, why not open port 80 as a catch all, that doesn't point to any server and redirect to https,  then enable HSTS on all of your servers?

 

Open port 80 to your neginx, then add this as the first server block.   Then uncomment the HSTS line in your config only if all of your nginx sites are https. To be safe you can lower the max-age to like 1 day for testing (86400).     So what this will do is allow something to connect on http, force it to https, then HSTS will make sure everything is https from there on out.     The only clients I know of that don't like redirects are android, firetv, and roku (at least as of a few months ago).  Those clients should respond to HSTS though.  

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

Edited October 24, 2017 by pir8radio

[Andy777 21]

 

Just curious, why not open port 80 as a catch all, that doesn't point to any server and redirect to https,  then enable HSTS on all of your servers?

 

Open port 80 to your neginx, then add this as the first server block.   Then uncomment the HSTS line in your config only if all of your nginx sites are https. To be safe you can lower the max-age to like 1 day for testing (86400).     So what this will do is allow something to connect on http, force it to https, then HSTS will make sure everything is https from there on out.     The only clients I know of that don't like redirects are android, firetv, and roku (at least as of a few months ago).  Those clients should respond to HSTS though.  

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;
}

 

 

I could do that, but haven't seen the need for it. Clients are my family only: Mostly Kodi on multiple platforms, some Emby on android and Emby-theater on Windows. I don't think any of those try to connect to port 80(?). Emby is the only thing I'm running behind nginx, and only because the linux/mono/ssl implementation constantly crashed.

 

BR

A

[pir8radio 1292]

I could do that, but haven't seen the need for it. Clients are my family only: Mostly Kodi on multiple platforms, some Emby on android and Emby-theater on Windows. I don't think any of those try to connect to port 80(?). Emby is the only thing I'm running behind nginx, and only because the linux/mono/ssl implementation constantly crashed.

 

BR

A

 

I thought your issue was that some http requests were being leaked to the server/kodi plugin, causing the client to request over http instead of https?  Sorry replace port 80 above with 8096 then.   Usually when running emby behind nginx people opt to use ports 443 and 80 so they dont have to enter port numbers.   In your case 9999 and 8096.  So add the catch all script change to 8096 (or whatever http port you have set in emby) it will redirect without actually sending any unsecure requests past nginx.  HSTS will lock it in going forward, not even trying http.  Any reason you use 9999 instead of 443?  we would have to change that catch all to include your odd 9999 port.  you can also look into proxy_redirect options

Edited October 24, 2017 by pir8radio

[Andy777 21]

I thought your issue was that some http requests were being leaked to the server/kodi plugin, causing the client to request over http instead of https?  Sorry replace port 80 above with 8096 then.   Usually when running emby behind nginx people opt to use ports 443 and 80 so they dont have to enter port numbers.   In your case 9999 and 8096.  So add the catch all script change to 8096 (or whatever http port you have set in emby) it will redirect without actually sending any unsecure requests past nginx.  HSTS will lock it in going forward, not even trying http.  Any reason you use 9999 instead of 443?  we would have to change that catch all to include your odd 9999 port.  you can also look into proxy_redirect options

 

9999 is an arbitrary choice since it is only listening to the traffic coming from the router external 8920 port. Nothing else connects to that port.

Wouldn't the "catch on 8096" force everything even in internal network to SSL (how about the certificate FDQN name etc)?

 

Since a picture is worth a thousand words, I drew one which shows the configuration (and the newly introduced problem with red color):

 

@@Angelblue05 and @@Luke  :

The problem with Emby for Kodi would completely go away by introducing a tree way setting in the server as:

1. Do not advertise https (like before)
2. Advertise https but do not enforce or redirect (like before)
3. Enforce and redirect to https (like now)

Advantages:

1. No change to Emby for Kodi code
2. All the (logic) code needed for change in the server already exists in the github

 

Looking forward to stable .Net Core release and hoping that it has a working SSL implementation. I could get rid of nginx all together then.

BR,

Andy777

Edited October 26, 2017 by Andy777

[pir8radio 1292]

9999 is an arbitrary choice since it is only listening to the traffic coming from the router external 8920 port. Nothing else connects to that port.

Wouldn't the "catch on 8096" force everything even in internal network to SSL (how about the certificate FDQN name etc)?

 

Since a picture is worth a thousand words, I drew one which shows the configuration (and the newly introduced problem with red color):

 

 

@@Angelblue05 and @@Luke  :

The problem with Emby for Kodi would completely go away by introducing a tree way setting in the server as:

1. Do not advertise https (like before)
2. Advertise https but do not enforce or redirect (like before)
3. Enforce and redirect to https (like now)

Advantages:

1. No change to Emby for Kodi code
2. All the (logic) code needed for change in the server already exists in the github

 

Looking forward to stable .Net Core release and hoping that it has a working SSL implementation. I could get rid of nginx all together then.

BR,

Andy777

 

You are doing this kind of rube goldberg-ish....   what address do your internal clients go to?    emby.domain.com:8920?   and presumably the same address when external?   

[Andy777 21]

You are doing this kind of rube goldberg-ish....   what address do your internal clients go to?    emby.domain.com:8920?   and presumably the same address when external?   

 

Internal clients go to http://192.168.0.5:8096. No custom configuration on any clients.

 

When I launch the Kodi for Emby the first time (in internal network), It automatically finds my server (192.168.0.5) on the same subnet. It then pulls the connection information from the emby server (again, this is how it normally works) and saves it into "addon_data\plugin.video.emby\data.txt".

 

The automatic connection info contains fields "RemoteAddress":"https://myexterna.whatever.com:8920",and "LocalAddress": "http://192.168.0.5:8096"

 

I presume that emby theater and android client does the same. 

 

So.. Nothing custom in any clients. No addresses ever need to be typed in any clients. This is the normal/default way the emby clients connect with the server. I only use nginx to replace the unusable mono SSL that emby linux version contains.

 

If you take out the ngix out of the above picture, it is a very simple standard emby configuration.

 

Now that the behavior of the server setting "Require https for external connections" change to forced redirect, emby no longer accepts (unencrypted) connections coming from my nginx. It sees them as external (as it should), but doesn't understand that they were encrypted up to the nginx -> forced redirect back to external 8920 port and the loop is ready.

 

I'm getting rid of nginx the second emby integrated SSL works. Now it just dies (at least on my ubuntu) after a couple of hours of medium traffic.

[pir8radio 1292]

Internal clients go to http://192.168.0.5:8096. No custom configuration on any clients.

 

When I launch the Kodi for Emby the first time (in internal network), It automatically finds my server (192.168.0.5) on the same subnet. It then pulls the connection information from the emby server (again, this is how it normally works) and saves it into "addon_data\plugin.video.emby\data.txt".

 

The automatic connection info contains fields "RemoteAddress":"https://myexterna.whatever.com:8920",and "LocalAddress": "http://192.168.0.5:8096"

 

I presume that emby theater and android client does the same. 

 

So.. Nothing custom in any clients. No addresses ever need to be typed in any clients. This is the normal/default way the emby clients connect with the server. I only use nginx to replace the unusable mono SSL that emby linux version contains.

 

If you take out the ngix out of the above picture, it is a very simple standard emby configuration.

 

Now that the behavior of the server setting "Require https for external connections" change to forced redirect, emby no longer accepts (unencrypted) connections coming from my nginx. It sees them as external (as it should), but doesn't understand that they were encrypted up to the nginx -> forced redirect back to external 8920 port and the loop is ready.

 

I'm getting rid of nginx the second emby integrated SSL works. Now it just dies (at least on my ubuntu) after a couple of hours of medium traffic.

 

alright i'm on the same page as you now.  what comes up when you go to http://yourembyserver/emby/system/info/public/

[Andy777 21]

alright i'm on the same page as you now.  what comes up when you go to http://yourembyserver/emby/system/info/public/

 

 

I'll include the port numbers, since there is nothing listening in 80.

Emby server setting "Require https for external connections ON"

·         connections from Internal network:

o   Internal network to: http://mydomain.yyyy.net:8096/emby/system/info/public/

§  Timeout (port closed/blocked)

§  (router nat loopback taking it to the external interface where http/8096 is blocked)

o   Internal network to  https://mydomain.yyyy.net 8920/emby/system/info/public/

§  Redirect loop (“ERR_TOO_MANY_REDIRECTS”). Router port is open (see previous line about nat loopback), but Emby redirects traffic back to router since traffic (from nginx onwards) is unencrypted. Emby sees it as external connection ( as it should ), but doesn’t understand that it was encrypted (since it is not encrypted anymore after passing through nginx)

o   Internal network to http://192.168.0.5:8096/emby/system/info/public

§  Browser showing a page where it correctly announces “local address: http://192.168.0.5” and “WanAddress: https://mydomain.yyyy.net.8920

o   Internal network to https://192.168.0.5:8920/emby/system/info/public

§  Browser showing a page where it correctly announces “local address: http://192.168.0.5” and “WanAddress: https://mydomain.yyyy.net.8920

§  PROBLEM: Mono SSL is used, and it will crash to the state “not resoponding” quite often .

·         connections from external network:

o   External network to: http://mydomain.yyyy.net:8096/emby/system/info/public/

§  Timeout (port closed/blocked). Just as it should be

o   External network to  https://mydomain.yyyy.net 8920/emby/system/info/public/

§  Redirect loop (“ERR_TOO_MANY_REDIRECTS”). Router port is open (see  about nat loopback), but Emby redirects traffic back to router since traffic (from nginx onwards) is unencrypted. Emby sees it as external connection ( as it should ), but doesn’t understand that it was encrypted (since it is not encrypted anymore after passing through nginx)

·         Any attempts to connect to 192.168.0.5 from external network would be stupid.

 

I will not include results where the Emby server setting “Require https for external connection” is OFF, as it should be obvious from the above results what happens. Depending on that setting the server advertises https or http. With reverse proxy the server thinks that the external connections are not encrypted (=http). If the setting now is to allow unencrypted traffic, the server advertises only unencrypted traffic (as can be seen in system/info/public).

I need the old setting, where the server advertises https/encryption, but accepts external connections without encryption. Nginx takes care that the connections are definitely encrypted, but forwards de-encrypted traffic to emby port 8096.

OR, I need emby to have a stable working https/ssl solution within.

There is nothing unclear about this for me anymore.

 

BR

A

[pir8radio 1292]

 

There is nothing unclear about this for me anymore.

 

It's still unclear to me, I don't have this issue, I never used the HTTPS check box in emby. Are you using a version of NGINX with Sub_Filter compiled in it?  You can subfilter any http to https and/or  8096 to 8920     subfilter rewrites responses from the back end real time.  It's pretty handy to make changes to backend code without actually editing the backend server. 

[Andy777 21]

It's still unclear to me, I don't have this issue, I never used the HTTPS check box in emby. Are you using a version of NGINX with Sub_Filter compiled in it?  You can subfilter any http to https and/or  8096 to 8920     subfilter rewrites responses from the back end real time.  It's pretty handy to make changes to backend code without actually editing the backend server. 

 

You must not be using Kodi (Emby for Kodi) clients with external connection and https. If the server "require https" if unchecked, Kodi _never_ tries to connect with https (you can force it to connect once, but it reverts immediately). Http (without ssl) is blocked by my router, so there is no connection from external networks.

 

If the checkmark is ON, emby redirects the traffic coming from nginx (as it is at that point unencrypted).

 

BR,

A