graphixmaker 2 Posted October 11, 2017 Share Posted October 11, 2017 I host Emby on a remote server behind nginx reverse proxy and I recently began using cloudflare to improve peering. This is working perfectly to overcome some speed issues with one caveat, I can't keep websockets open. Everything works as expected with Kodi except the automatic library updates. If I delete an episode or movie, it doesn't refresh until I manually sync or restart Kodi. I assumed this was a websocket issue so I started digging. I have confirmed from Cloudlflare that websockets are automatically disconnected after 100 seconds of silence. I tested this by logging in with Chrome and playing an episode. While in the iOS app I can see the web socket is active and can send messages to the chrome client however, 100 seconds after I send the message the app reports the chrome client disconnects. Playback is unaffected but it's clear the socket is no longer active. Is anyone using cloudflare and not experiencing this? My main issue was peering and it has solved that so well I'm considering just living with it but would love to have it working 100%. Link to comment Share on other sites More sharing options...
Luke 36886 Posted October 11, 2017 Share Posted October 11, 2017 FYI, this won't help Kodi, but we are planning on utilizing cloud messaging for the mobile apps when the web socket is not connecting. having the two protocols will pretty much ensure that messages get through, one way or another. Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 11, 2017 Author Share Posted October 11, 2017 I only used the messaging for the test but that's a nice workaround. What I'd really like to have back is the functionality of the Kodi automatic sync when episodes and movies are deleted or added. Link to comment Share on other sites More sharing options...
dcrdev 251 Posted October 11, 2017 Share Posted October 11, 2017 I use CloudFlare and I don't have this problem - does this happen when accessing your proxy directly as well? 1 Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 11, 2017 Author Share Posted October 11, 2017 No, if I turn the cloudflare proxy off nginx handles the web socket perfectly. I initially assumed I needed to change something in my configuration but after I found the timeout info I figured that was it. Could you post your nginx conf to compare? Link to comment Share on other sites More sharing options...
dcrdev 251 Posted October 11, 2017 Share Posted October 11, 2017 No, if I turn the cloudflare proxy off nginx handles the web socket perfectly. I initially assumed I needed to change something in my configuration but after I found the timeout info I figured that was it. Could you post your nginx conf to compare? I don't use nginx, I use Apache with mod_proxy and mod_proxy_wstunnel, Have you got the CloudFlare caching enabled? Can't see how that would possibly make a difference, but I do have it disabled with page rules. Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 11, 2017 Author Share Posted October 11, 2017 I do have it enabled, I'll disable that and see if it makes a difference. Do you have Emby specific page rules? I've never used a CDN before so I'm trying to learn all I can. It took me a while to get my server config dialed in but once it was it was flawless. If I can keep the clouflare peering and everything else as it was I'll be set. Thanks for the quick replies. Link to comment Share on other sites More sharing options...
dcrdev 251 Posted October 11, 2017 Share Posted October 11, 2017 I do have it enabled, I'll disable that and see if it makes a difference. Do you have Emby specific page rules? I've never used a CDN before so I'm trying to learn all I can. It took me a while to get my server config dialed in but once it was it was flawless. If I can keep the clouflare peering and everything else as it was I'll be set. Thanks for the quick replies. I'm not using the CDN functionality for Emby at all, I am for some of my sites though. I'll take a look later, but the rule is pretty much disable for patterns matching "*emby.domain.com*". CloudFlare for me is mainly about obscuring my server's origin IP as well as being a dynamic dns service - since they have an api for updating dns records. Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 11, 2017 Author Share Posted October 11, 2017 (edited) I'm not using the CDN functionality for Emby at all, I am for some of my sites though. I'll take a look later, but the rule is pretty much disable for patterns matching "*emby.domain.com*". CloudFlare for me is mainly about obscuring my server's origin IP as well as being a dynamic dns service - since they have an api for updating dns records. Ahh that's probably why you aren't having the same issue. If you're only using the DNS functionality for the Emby sub domain then the web sockets would be unaffected. Same result I get when cloudflare is only doing DNS for mine. Edited October 11, 2017 by graphixmaker Link to comment Share on other sites More sharing options...
dcrdev 251 Posted October 11, 2017 Share Posted October 11, 2017 (edited) Ahh that's probably why you aren't having the same issue. If you're only using the DNS functionality for the Emby sub domain then the web sockets would be unaffected. Same result I get when cloudflare is only doing DNS for mine. No - I think you're misinterpreting what I said. CloudFlare is acting as a proxy i.e. it's not just relaying traffic to my ip. It's just I'm not using the cdn functionality, so to clarify websockets are being tunneled through CloudFlare. Edited October 11, 2017 by dcrdev Link to comment Share on other sites More sharing options...
dcrdev 251 Posted October 11, 2017 Share Posted October 11, 2017 And here's my page rule: Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted October 11, 2017 Share Posted October 11, 2017 (edited) I host Emby on a remote server behind nginx reverse proxy and I recently began using cloudflare to improve peering. This is working perfectly to overcome some speed issues with one caveat, I can't keep websockets open. Everything works as expected with Kodi except the automatic library updates. If I delete an episode or movie, it doesn't refresh until I manually sync or restart Kodi. I assumed this was a websocket issue so I started digging. I have confirmed from Cloudlflare that websockets are automatically disconnected after 100 seconds of silence. I tested this by logging in with Chrome and playing an episode. While in the iOS app I can see the web socket is active and can send messages to the chrome client however, 100 seconds after I send the message the app reports the chrome client disconnects. Playback is unaffected but it's clear the socket is no longer active. Is anyone using cloudflare and not experiencing this? My main issue was peering and it has solved that so well I'm considering just living with it but would love to have it working 100%. what url are you using? kodi.yourdomain.com by itself or do you have a kodi.yourdomain.com/emby as your access url? Post your nginx config too without your domain name. I use cloudflare/nginx/emby setup myself. I'm not seeing this. Edited October 11, 2017 by pir8radio Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 12, 2017 Author Share Posted October 12, 2017 (edited) Below is my emby specific config: server { listen 80; listen [::]:80; server_name emby.**.org; return 301 https://$server_name$request_uri; } server { # SSL configuration listen 443 ssl http2; listen [::]:443 ssl http2; server_name emby.**.org; include snippets/ssl-**.org.conf; include snippets/ssl-params.conf; location / { # Send traffic to the backend proxy_pass http://127.0.0.1:8096; 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; real_ip_header X-Forwarded-For; real_ip_recursive on; # Send websocket data to the backend as well proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /.well-known/ { root /var/www/html; } } I was beginning to think it might have something to do with the traffic going through two proxies since my emby logs show both the originating IP and the cloudflare IP for all connections. But I'm just not familiar enough with the websockets to know. Edited October 12, 2017 by graphixmaker Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted October 12, 2017 Share Posted October 12, 2017 (edited) Below is my emby specific config: I was beginning to think it might have something to do with the traffic going through two proxies since my emby logs show both the originating IP and the cloudflare IP for all connections. But I'm just not familiar enough with the websockets to know. The two IP's in the log/dashboard are fine, that is x-forwarded-for adding each step to the chain. I think your issue is IP related, but it is in your own config. I would loose proxy redirect off, x-forwarded for proto, x-forwarded for scheme, you dont need the real-IP stuff either... You don't want your nginx trying to directly respond to the client, let each reverse proxy do its thing... Try to copy my config here (POST #2) use it as a starting point, you can leave out the "security settings" section. Let us know how that goes, you can always put your config back in.. Edited October 12, 2017 by pir8radio Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 12, 2017 Author Share Posted October 12, 2017 The two IP's in the log/dashboard are fine, that is x-forwarded-for adding each step to the chain. I think your issue is IP related, but it is in your own config. I would loose proxy redirect off, x-forwarded for proto, x-forwarded for scheme, you dont need the real-IP stuff either... You don't want your nginx trying to directly respond to the client, let each reverse proxy do its thing... Try to copy my config here (POST #2) use it as a starting point, you can leave out the "security settings" section. Let us know how that goes, you can always put your config back in.. Yes I added the real-IP stuff thinking the two IP's may have been causing the issue. I made the changes you recommended but I got the same result when testing with chrome. You can see below that just after a minute it shows it disconnects, but playback to the user is uninterrupted. It then shows it's immediately back online. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted October 12, 2017 Share Posted October 12, 2017 (edited) Yes I added the real-IP stuff thinking the two IP's may have been causing the issue. I made the changes you recommended but I got the same result when testing with chrome. You can see below that just after a minute it shows it disconnects, but playback to the user is uninterrupted. It then shows it's immediately back online. Do you see the same thing when on my server? I do not. https://emby.media/community/index.php?/topic/19457-help-me-test-my-emby-server/?p=188745 Here is the stats on my websocket connections, So I know it does/can work. Oh what does the rest of your config look like? Any timouts set? Edited October 12, 2017 by pir8radio Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 12, 2017 Author Share Posted October 12, 2017 Do you see the same thing when on my server? I do not. https://emby.media/community/index.php?/topic/19457-help-me-test-my-emby-server/?p=188745 Here is the stats on my websocket connections, So I know it does/can work. Oh what does the rest of your config look like? Any timouts set? Playback is perfectly fine on your server but it is on mine as well. I think you'd have to check your dashboard to see if it showed the disconnect from chrome. That's the thing that's strange is that it doesn't affect playback at all. It's only the two way communication that is getting disconnected. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted October 13, 2017 Share Posted October 13, 2017 Playback is perfectly fine on your server but it is on mine as well. I think you'd have to check your dashboard to see if it showed the disconnect from chrome. That's the thing that's strange is that it doesn't affect playback at all. It's only the two way communication that is getting disconnected. oh I thought you were using developer tools in chrome... Well hit F12 in chrome, hit the network tab then select WS and you can monitor the websockets, compare yours to mine. Link to comment Share on other sites More sharing options...
graphixmaker 2 Posted October 14, 2017 Author Share Posted October 14, 2017 oh I thought you were using developer tools in chrome... Well hit F12 in chrome, hit the network tab then select WS and you can monitor the websockets, compare yours to mine. Ok, so I viewed yours, then mine. I'm going to be honest, I don't know what I'm looking for so I I don't understand how the two differ however, yours say "embywebsocket" at th beginning and mine say "socket". that is the only difference I can see. Yours Mine Link to comment Share on other sites More sharing options...
anthonws 40 Posted October 16, 2017 Share Posted October 16, 2017 For someone that has not yet ventured into CDN territory. Can anyone with more experience on the matter tell me what's the benefit for a traditional Emby setup, without reverse proxy? Cheers, anthonws. Link to comment Share on other sites More sharing options...
pir8radio 1289 Posted October 17, 2017 Share Posted October 17, 2017 (edited) For someone that has not yet ventured into CDN territory. Can anyone with more experience on the matter tell me what's the benefit for a traditional Emby setup, without reverse proxy? Cheers, anthonws. So there are many different CDN's... Let's start with Cloudflare, my favorite. Cloudflare "IS" an nginx reverse proxy service.... What they do is run nginx servers all over the world, acting as a reverse proxy to your emby... These servers will cache or store your images, javascript files, css and other static content on these "EDGE" servers around the world.. So let's say your server is in Chicago USA, and someone in Europe goes to your emby.mysite.com, they will get all of the static stuff really quickly from the edge server closest to them... VS without cloudflare, each requested file has to travel across the planet, each hop through servers delaying your Europe client from getting the image, JS, CSS, HTML instantly, making your page load slowly. Because cloudflare is also based on an nginx reverse proxy, your true emby server IP is hidden from anyone.. Because your domain name will point to cloudflare servers... Only cloudflare will be able to see your real IP (in most cases). Cloudflare as well as other CDN's also have pretty good/fast pipes to these edge servers, as opposed to whatever internet backbone your client lands on to reach your emby in chicago. Other CDN's usually cache DNS stuff, some cache images as well, but I don't believe any of them hide your true server address/location like Cloudflare, if that is something you want. Here are two graphs of my server... These graphs show load times to remote countries from my server near Chicago... The first graph is directly from these sites to my server, the second graph is running through cloudflare. you can see that "most" of the time the CDN is quicker. Not always. Tokyo is the obvious improvement. I just use cloudflare so I can say I do... Running my emby server is more a hobby than anything, I just like tinkering with techno. Would you need to? probably not unless you were using it to mask your IP, or you travel to other countries, states often, even with a basic setup you can see some speed improvements using cloudflare, it can also offload all of those images, css, javascript, html content from being pulled directly from your emby, it will come from the edge servers, so emby takes less hits. Not true with streaming content, that always comes from your server. Edited October 17, 2017 by pir8radio 1 Link to comment Share on other sites More sharing options...
jscoys 143 Posted October 17, 2017 Share Posted October 17, 2017 Hello little question: I opened an account on Cloudflare, but I can’t put my website it refuses. What I’m supposed to do then? Sent from my iPad using Tapatalk Link to comment Share on other sites More sharing options...
Jdiesel 1112 Posted October 17, 2017 Share Posted October 17, 2017 (edited) Hello little question: I opened an account on Cloudflare, but I can’t put my website it refuses. What I’m supposed to do then? Sent from my iPad using Tapatalk You need to enter it as domain.com rather than www.domain.com or http://domain.com Edited October 17, 2017 by Jdiesel Link to comment Share on other sites More sharing options...
jscoys 143 Posted October 17, 2017 Share Posted October 17, 2017 Ok so you have a domain that point to your ipaddress:8096? Sent from my iPad using Tapatalk Link to comment Share on other sites More sharing options...
horstepipe 356 Posted October 17, 2017 Share Posted October 17, 2017 Hey Just came across this thread, using Cloudflare sounds like an interesting option. When I got it right you need to purchase a domain name, so using a service like dyndns or no-ip won‘t be enough, right? Somewhere I read that Cloudflare only forwards particular ports, so what do you do if your desired port is not on that list? (For another webservice than Emby) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now