Jump to content

Cloudflare CDN and Websockets


graphixmaker

Recommended Posts

graphixmaker

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

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

graphixmaker

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

dcrdev

I use CloudFlare and I don't have this problem - does this happen when accessing your proxy directly as well? 

  • Like 1
Link to comment
Share on other sites

graphixmaker

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

dcrdev

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

graphixmaker

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

dcrdev

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

graphixmaker

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 by graphixmaker
Link to comment
Share on other sites

dcrdev

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.

 

59de76daa365b_Screenshot_20171011_204821

Edited by dcrdev
Link to comment
Share on other sites

pir8radio

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.

59de96ebaecf3_Capture.png

Edited by pir8radio
Link to comment
Share on other sites

graphixmaker

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 by graphixmaker
Link to comment
Share on other sites

pir8radio

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 by pir8radio
Link to comment
Share on other sites

graphixmaker

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.

 

59dfa1cacfef1_Capture.jpg

Link to comment
Share on other sites

pir8radio

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? 

 

59dfe16523cef_Capture.png

Edited by pir8radio
Link to comment
Share on other sites

graphixmaker

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

pir8radio

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

graphixmaker

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

59e162e4aa55d_nam.jpg

 

Mine

59e162fce374b_emg.jpg

Link to comment
Share on other sites

anthonws

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

pir8radio

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. 

 

 

59e548b261fab_noCDN.png

 

 

 

 

59e548c4b9ee5_CDN.png

Edited by pir8radio
  • Like 1
Link to comment
Share on other sites

jscoys

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

Jdiesel

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 by Jdiesel
Link to comment
Share on other sites

horstepipe

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...