Clarification on 'Secure connection mode' when using Cloudflare?

[C.S. 93]

When I first set up my Emby server with Cloudflare a couple years ago, I had issues with buffering (mostly with Roku clients iirc). So I tried changing 'Secure connection mode' to 'Handled by reverse proxy'. After that everything worked great and has been working great. This solution made sense to me because Cloudflare is a reverse proxy after all, and by using its firewall to reject any non-SSL requests to my domain, I figured Cloudflare was "handling" it.  But after reading @cayars's post in this thread:

I am now unsure if I'm doing things wrong. The advice given above is to set Cloudflare's SSL mode to 'Full' and Emby's mode to 'Required'. My SSL mode is set to 'Full (strict)'. Am I leaving my server vulnerable by using the 'Handled by reverse proxy' setting?

[Luke 42083]

HI, no, you're not. The handled by reverse proxy option just informs Emby Server that you have SSL support via external software. 

[C.S. 93]

Great thanks!

So if anyone is having connectivity issues when using Cloudflare, my advice would be to try the reverse proxy option. That's what worked for me.

[Carlo 4561]

10 minutes ago, C.S. said:

Great thanks!

So if anyone is having connectivity issues when using Cloudflare, my advice would be to try the reverse proxy option. That's what worked for me.

The choice between Full or Full (Strict) will have to do with the way you setup the cert for your domain.

One thing you may want to check:
Look at the connection in Emby when someone is using your server remotely.
Does Emby report the users actual IP address or do you always see the same set of IPs that belong to Cloudflare?
The Reverse Proxy setting can affect this if I remember correctly.
 

[C.S. 93]

I see the actual IPs.

[Carlo 4561]

You are just fine then.

Edited October 28, 2021 by cayars

[warrentc3 47]

sorry to re-open this topic, but with regard to reverse proxy...

why does emby server still make direct outbound connections to the client?
inbound is just fine via cloudflared.

would absolutely welcome any insights!!

114 6 veth114i0-IN 25/Mar/2023:19:28:24 -0400 ACCEPT: IN=fwbr114i0 OUT=fwbr114i0 PHYSIN=fwln114i0 PHYSOUT=veth114i0 MAC=xxxx SRC=cloudflared-lxc1 DST=emby-lxc LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=17794 DF PROTO=TCP SPT=49346 DPT=8096 SEQ=2381169660 ACK=0 WINDOW=64240 SYN 

114 6 veth114i0-OUT 25/Mar/2023:19:28:39 -0400 ACCEPT: IN=fwbr114i0 OUT=fwbr114i0 PHYSIN=veth114i0 PHYSOUT=fwln114i0 MAC=xxxx SRC=emby-lxc DST=externalclient LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=18575 DF PROTO=TCP SPT=48248 DPT=443 SEQ=1795991609 ACK=0 WINDOW=64240 SYN 

[Luke 42083]

3 hours ago, warrentc3 said:

sorry to re-open this topic, but with regard to reverse proxy...

why does emby server still make direct outbound connections to the client?
inbound is just fine via cloudflared.

would absolutely welcome any insights!!

114 6 veth114i0-IN 25/Mar/2023:19:28:24 -0400 ACCEPT: IN=fwbr114i0 OUT=fwbr114i0 PHYSIN=fwln114i0 PHYSOUT=veth114i0 MAC=xxxx SRC=cloudflared-lxc1 DST=emby-lxc LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=17794 DF PROTO=TCP SPT=49346 DPT=8096 SEQ=2381169660 ACK=0 WINDOW=64240 SYN 

114 6 veth114i0-OUT 25/Mar/2023:19:28:39 -0400 ACCEPT: IN=fwbr114i0 OUT=fwbr114i0 PHYSIN=veth114i0 PHYSOUT=fwln114i0 MAC=xxxx SRC=emby-lxc DST=externalclient LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=18575 DF PROTO=TCP SPT=48248 DPT=443 SEQ=1795991609 ACK=0 WINDOW=64240 SYN 

It's the clients that connect to the server, not the other way around. So that means as far as the server is concerned, they are incoming.

[warrentc3 47]

5 minutes ago, Luke said:

It's the clients that connect to the server, not the other way around. So that means as far as the server is concerned, they are incoming.

The incoming and most of the outgoing traffic is flowing through the reverse proxy.  It’s the outbound connection from the server to the client on :443 is what i’m hoping to gain some clarity on.  It seems to nullify some of the intended networking flow the reverse proxy means to mitigate.