Can somebody educate me on reverse proxies?

[Canaletto 2]

Cache level "standard", Always Online "ON" (doesn't really do much but keep the login page active when emby is down) Cache Expiration "Respect Existing Headers"  or  "Select"  Between emby's default cache settings and the two above rules those settings work well.   

Dont enable "auto minify" check boxes, or rocket loader, some strange client issues start to pop up.

 

Hello !

 

After a lot of tests on port 8443 and no results in CF-Cache-Status, I changed the port to test in 443, and there; bingo Cloudflare cache works!

 

I do not know if it is related to the free version, in any case impossible to have cache on a port other than the 443.

 

At the same time I did not get the impression that the CloudFlare cache is really efficient for Emby.

 

CloudFlare is useful for SSL and lereverse proxy, being able to ban IP addresses other than those of CloudFlare is a real plus in terms of security.

 

In this context CloudFlare rules are useless.

 

To summarize, on the server Emby (VPS Windows), it will open only the port, 8443 for example, and only from the IP CloudFlare (https://www.cloudflare.com/ips/)

 

lionel

[ttgapers 94]

Are these rules still valid with the latest Emby server versions? I am not seeing many hits other than the /* (root) rule, so more interested in the second rule. I found the pattern off and thus changed mine to:

sub.domain.net/Items/*/Images/*
Cache Level: Cache Everything, Edge Cache TTL: a month

But still lots of Dynamic hits particularly on "static" images with dynamic paths - library images, movie, tv shows etc.

 

Thanks a lot @@pir8radio

 

 

Add these settings to cloudflare under "Page Rules"  replayce "domainname.com" with your domain name.

 

This first rule forces all cached images to stay on the edge servers for 30 days and in clients for 1 year.  Otherwise they flush the edge servers quite often defeating the purpose of the cache.

 

 

This rule forces cloudflare to cache all images, normally they do not cache most emby images because emby doesn't have extensions on the majority of their images, so this rule forces (based on path) cloudflare to Cache the file no matter what.  You don't want to use "cache everything" on the root, bad things start to happen.. If emby makes a change it wont get pushed to CF, so CF will serve stale pages, this is ok with the images though as shown below.

 

You can confirm things are working by loading your emby up in CHROME, right click go to "INSPECT" select the "NETWORK" tab and check the "Disable Cache" box..  right click the title "NAME" and add a custom header "cf-cache-status"   load up the page three or four times you should start seeing "HIT" under cf-cache-status, this means the resource has came from CF and not directly from your server!

Edited April 12, 2020 by ttgapers

[pir8radio 1292]

Are these rules still valid with the latest Emby server versions? I am not seeing many hits other than the /* (root) rule, so more interested in the second rule. I found the pattern off and thus changed mine to:

sub.domain.net/Items/*/Images/*
Cache Level: Cache Everything, Edge Cache TTL: a month

But still lots of Dynamic hits particularly on "static" images with dynamic paths - library images, movie, tv shows etc.

 

Thanks a lot @@pir8radio

 

yes, CF wont cache items until they have been pulled fresh a few times....  disable browser caching and reload the page a few times you should start seeing all of the images come back as cache hits.

[ttgapers 94]

yes, CF wont cache items until they have been pulled fresh a few times....  disable browser caching and reload the page a few times you should start seeing all of the images come back as cache hits.

Thanks for the feedback. So, the updated second rule I have above (updated pattern path) is now the "default" for Emby in CF with caching versus your original correct?

 

I have noticed a jump with that pattern, but want to be sure.

[pir8radio 1292]

Thanks for the feedback. So, the updated second rule I have above (updated pattern path) is now the "default" for Emby in CF with caching versus your original correct?

 

I have noticed a jump with that pattern, but want to be sure.

 

not sure i follow your question, this is what my rules look like today:

1. First rule caches majority of emby images,  we do "cache everything" because emby images do not have an extension that CF can recognize as an image. that's why we have to specify the wildcard url, there "should" only be images coming from that url.  Then we keep those images on the edge servers as long as CF allows us. (a month)
2. the second rule just tells CF anything it cached using its normal means (css, js, html, etc), keep that stuff on the edge server for as long as CF will allow us (a month). We have to specify this otherwise CF flushes its cache pretty quickly.  

Edited April 12, 2020 by pir8radio

[ttgapers 94]

Thanks!

 

Here is mine:

 

 

Do I need the "/emby/" in my first rule similar to yours? I don't seem to have any hits to that subfolder, so I updated above based on my Chrome observations. Hope that clarifies my ask.

 

Cheers

[pir8radio 1292]

Thanks!

 

Here is mine:

 

 

Do I need the "/emby/" in my first rule similar to yours? I don't seem to have any hits to that subfolder, so I updated above based on my Chrome observations. Hope that clarifies my ask.

 

Cheers

 

not sure why you dont have hits,  check your browser for "cf cache status" it will tell you if what you are receiving is a cache hit or not.   But yea all of my images come from /emby

 

 

 

This shows the custom header column i added to the chrome developer page, showing which file was a cache hit .    google CF-CACHE-STATUS to find some instructions how to view this in chrome. 

 

[ttgapers 94]

not sure why you dont have hits,  check your browser for "cf cache status" it will tell you if what you are receiving is a cache hit or not.   But yea all of my images come from /emby

 

 

 

This shows the custom header column i added to the chrome developer page, showing which file was a cache hit .    google CF-CACHE-STATUS to find some instructions how to view this in chrome. 

 

Confirmed hits on my pattern now...I don't have the /emby/ so all good. Thanks for the steps on how to enable and verify this!

[pir8radio 1292]

Confirmed hits on my pattern now...I don't have the /emby/ so all good. Thanks for the steps on how to enable and verify this!

 

weird, what server version and os are you using?  curious why it would be different from the rest.  

[ttgapers 94]

Yup,

 

 

It is weird and thus my question! Happy you understand now. Here are my details:

 

OS: Windows 10 Pro - fully patched

Emby Server version: 4.5.0.5 Beta

Nginx setup for reverse proxy via sub-domain (not sub-folder), thus emby.domain.net rather than domain.net/emby

 

Some screenshots:

 

 

Let me know your thoughts. Only things I can think of is what I suggested re: sub-domain/sub-folder differences.

Edited April 13, 2020 by ttgapers

[pir8radio 1292]

Yup,

 

 

It is weird and thus my question! Happy you understand now. Here are my details:

 

OS: Windows 10 Pro - fully patched

Emby Server version: 4.5.0.5 Beta

Nginx setup for reverse proxy via sub-domain (not sub-folder), thus emby.domain.net rather than domain.net/emby

 

Some screenshots:

 

 

Let me know your thoughts. Only things I can think of is what I suggested re: sub-domain/sub-folder differences.

 

oh you use sub-directory?

[ttgapers 94]

oh you use sub-directory?

Yup. sub.domain.com vs domain.com/sub

 

So guess that's where guidance on the Page Rules should call out, else someone might be butting their heads

 

Thanks again chief, your posts not only in this thread, but others shed a lot of light on CF and it's feature set to allow (secure) enablement of emby!