niallobr 9 Posted May 27, 2021 Share Posted May 27, 2021 (edited) Thanks for the replies. I'm on Emby server 4.6.0.52 beta so should be covered. If you think my entries for the custom headers look ok then maybe I'm just not passing the $remote_addr down the tunnel from the VPS to my Synology NAS, so Emby only sees a local address? I only entered the headers on Synology. I'm using frp (Fast Reverse Proxy) to make the connection so maybe it also needs to be configured there too. Edit: The frp documentation says the following You can get user's real IP from HTTP request headers X-Forwarded-For and X-Real-IP. The following line can be added to the frp config to enable Proxy Protocol # now v1 and v2 are supported proxy_protocol_version = v2 Described here: https://github.com/fatedier/frp#http-x-forwarded-for I've done this but I'm not having much luck with the Synology nginx config. I have added the X-Forwarded-For and X-Real-IP headers as shown previously but think I also need to add the Proxy Protocol into my nginx config based on this template http { #... server { listen 80 proxy_protocol; listen 443 ssl proxy_protocol; #... } } Described here: https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/ when I add the proxy_protocol lines to my config and reload nginx I can no longer make a connection to the proxy via my domain... so I'm stuck at this point. Without that I still see 127.0.0.1 for all remote users in Emby despite having the correct headers set on the proxy and (as far as I can tell) frp set up correctly. Maybe I'll abandon it and try doing a reverse proxy tunnel through cloudflared by using Cloudflare Argo Tunnel instead of the Synology/frp/VPS setup. Edited May 27, 2021 by niallobr Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 27, 2021 Share Posted May 27, 2021 (edited) 5 hours ago, niallobr said: Thanks for the replies. I'm on Emby server 4.6.0.52 beta so should be covered. If you think my entries for the custom headers look ok then maybe I'm just not passing the $remote_addr down the tunnel from the VPS to my Synology NAS, so Emby only sees a local address? I only entered the headers on Synology. I'm using frp (Fast Reverse Proxy) to make the connection so maybe it also needs to be configured there too. Edit: The frp documentation says the following You can get user's real IP from HTTP request headers X-Forwarded-For and X-Real-IP. The following line can be added to the frp config to enable Proxy Protocol # now v1 and v2 are supported proxy_protocol_version = v2 Described here: https://github.com/fatedier/frp#http-x-forwarded-for I've done this but I'm not having much luck with the Synology nginx config. I have added the X-Forwarded-For and X-Real-IP headers as shown previously but think I also need to add the Proxy Protocol into my nginx config based on this template http { #... server { listen 80 proxy_protocol; listen 443 ssl proxy_protocol; #... } } Described here: https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/ when I add the proxy_protocol lines to my config and reload nginx I can no longer make a connection to the proxy via my domain... so I'm stuck at this point. Without that I still see 127.0.0.1 for all remote users in Emby despite having the correct headers set on the proxy and (as far as I can tell) frp set up correctly. Maybe I'll abandon it and try doing a reverse proxy tunnel through cloudflared by using Cloudflare Argo Tunnel instead of the Synology/frp/VPS setup. You don't need proxy protocol, you need to pass the headers x-forwarded0for and x-real-ip on to emby. Have you looked at the example config posted here? Edited May 27, 2021 by pir8radio 1 Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 27, 2021 Share Posted May 27, 2021 (edited) Thanks for the advice. I had been looking at this one but I'm looking at your guide now. I'm a bit afraid of messing up the Synology DSM admin config, so instead of copying your entire file I'm trying to bring in the pieces I need. Here's what I have at the moment. I left out some bits like the Emby logging and 443 redirect for now. I just reloaded nginx with these changes and still see 127.0.0.1 when I connect as a remote user. It would be great to know if you spot anything I should fix? Sorry if this is going off topic I can re-post in your thread if it makes more sense. nginx.conf < snip - I'm removing this since its not relevant anymore and clogging up the thread > I notice the line set_real_ip_from appears twice with two different addresses. Could that mess things up? I don't see that line or the other real_ip lines above it at all in your file. I've tried removing one of the addresses, removing both, removing both and the real_ip lines above and also adding the set_real_ip_from line into the server block in the file below, none of that seemed to make a difference. app.d/server.ReverseProxy.conf < snip - I'm removing this since its not relevant anymore and clogging up the thread > Would the fact Emby is in Docker have an impact? The route is something like this Client --> https://emby.mydomain.com --> frps Docker (VPS) --> frpc Docker (Synology) --> nginx (Synology) --> Emby Docker (Synology) If my nginx config above looks good then the client IP must be lost somewhere else along the way? The Emby Docker is in host mode. Edited May 28, 2021 by niallobr Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 28, 2021 Share Posted May 28, 2021 14 hours ago, niallobr said: Thanks for the advice. I had been looking at this one but I'm looking at your guide now. I'm a bit afraid of messing up the Synology DSM admin config, so instead of copying your entire file I'm trying to bring in the pieces I need. Here's what I have at the moment. I left out some bits like the Emby logging and 443 redirect for now. I just reloaded nginx with these changes and still see 127.0.0.1 when I connect as a remote user. It would be great to know if you spot anything I should fix? Sorry if this is going off topic I can re-post in your thread if it makes more sense. nginx.conf # Copyright (c) 2000-2017 Synology Inc. All rights reserved. worker_processes auto; #worker_cpu_affinity auto; worker_rlimit_nofile 65535; include conf.d/main.conf; events { use epoll; multi_accept on; accept_mutex off; worker_connections 8192; include conf.d/events.conf; } http { include 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 off; #access_log syslog:server=unix:/dev/log,facility=local7,tag=nginx_access,nohostname main; error_log syslog:server=unix:/dev/log,facility=local7,tag=nginx_error,nohostname error; tcp_nopush on; tcp_nodelay on; sendfile on; server_tokens off; proxy_request_buffering off; fastcgi_request_buffering off; scgi_request_buffering off; proxy_buffering off; fastcgi_buffering off; scgi_buffering off; resolver_timeout 5s; client_header_timeout 10s; client_body_timeout 60s; send_timeout 60s; keepalive_timeout 65s 20s; client_max_body_size 0; server_names_hash_max_size 8192; server_names_hash_bucket_size 128; ssl_certificate /usr/syno/etc/certificate/system/default/fullchain.pem; ssl_certificate_key /usr/syno/etc/certificate/system/default/privkey.pem; ssl_protocols TLSv1.2; ssl_ciphers "not sure if this is sensitive so removing it"; ssl_dhparam /usr/syno/etc/ssl/dh2048.pem; ssl_prefer_server_ciphers on; ssl_session_tickets off; ssl_session_cache shared:SSL:1m; ssl_session_timeout 3600s; real_ip_header X-Forwarded-For; real_ip_recursive on; set_real_ip_from 127.0.0.1; set_real_ip_from 10.0.0.200; include /var/tmp/nginx/trusted_proxy/*.conf; map $http_upgrade $connection_upgrade { default upgrade; '' close; } server_tag "nginx"; gzip_disable "msie6"; gzip_comp_level 6; gzip_min_length 1100; gzip_buffers 16 8k; gzip_proxied any; gzip_types text/plain text/css text/js text/xml text/javascript application/javascript application/x-javascript application/json application/xml application/rss+xml image/svg+xml; gzip_vary on; gzip_static on; open_file_cache max=1000 inactive=60s; open_file_cache_valid 3s; open_file_cache_min_uses 2; open_file_cache_errors on; upstream synoscgi { server unix:/run/synoscgi.sock; } index index.html index.htm index.php; server { listen 5000 default_server; listen [::]:5000 default_server; server_name _; gzip on; include app.d/alias.*.conf; root /usr/syno/synoman; index index.cgi; ignore_invalid_headers off; include app.d/dsm.*.conf; include /usr/syno/share/nginx/conf.d/dsm.*.conf; include conf.d/dsm.*.conf; location = / { try_files $uri /index.cgi$is_args$query_string; } location ~ ^/volume(?:X|USB|SATA|Gluster)?\d+/ { internal; root /; open_file_cache off; include app.d/x-accel.*.conf; include conf.d/x-accel.*.conf; } location ~ /webman/modules/(PersonalSettings|ExternalDevices|FileBrowser)/index_ds.php$ { alias /usr/syno/share/OAuth/index_ds.php; default_type text/html; } location ~ \.cgi { include scgi_params; scgi_pass synoscgi; scgi_read_timeout 3600s; } error_page 403 404 500 502 503 504 @error_page; location @error_page { root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } location ~ ^/webman/modules/Indexer/ { deny all; } location ~ ^/webapi/lib/ { deny all; } location ~ ^/webapi/(:?(:?.*)\.lib|(:?.*)\.api|(:?.*)\.auth|lib.def)$ { deny all; } location ~ /\. { access_log off; log_not_found off; deny all; } location ~* \.(?:js|css|png|jpg|gif|ico)$ { access_log off; log_not_found off; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { allow all; access_log off; log_not_found off; } } server { listen 5001 default_server ssl; listen [::]:5001 default_server ssl; server_name _; include app.d/alias.*.conf; root /usr/syno/synoman; index index.cgi; ignore_invalid_headers off; include app.d/dsm.*.conf; include /usr/syno/share/nginx/conf.d/dsm.*.conf; include conf.d/dsm.*.conf; location = / { try_files $uri /index.cgi$is_args$query_string; } location ~ ^/volume(?:X|USB|SATA|Gluster)?\d+/ { internal; root /; open_file_cache off; include app.d/x-accel.*.conf; include conf.d/x-accel.*.conf; } location ~ /webman/modules/(PersonalSettings|ExternalDevices|FileBrowser)/index_ds.php$ { alias /usr/syno/share/OAuth/index_ds.php; default_type text/html; } location ~ \.cgi { include scgi_params; scgi_pass synoscgi; scgi_read_timeout 3600s; } error_page 403 404 500 502 503 504 @error_page; location @error_page { root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } location ~ ^/webman/modules/Indexer/ { deny all; } location ~ ^/webapi/lib/ { deny all; } location ~ ^/webapi/(:?(:?.*)\.lib|(:?.*)\.api|(:?.*)\.auth|lib.def)$ { deny all; } location ~ /\. { access_log off; log_not_found off; deny all; } location ~* \.(?:js|css|png|jpg|gif|ico)$ { access_log off; log_not_found off; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { allow all; access_log off; log_not_found off; } } server { listen 80 default_server; listen [::]:80 default_server; gzip on; server_name _; location ~ ^/volume(?:X|USB|SATA|Gluster)?\d+/ { internal; root /; open_file_cache off; include app.d/x-accel.*.conf; include conf.d/x-accel.*.conf; } include app.d/www.*.conf; include app.d/alias.*.conf; include /usr/syno/share/nginx/conf.d/www.*.conf; include conf.d/www.*.conf; location = /webdefault/images/logo.jpg { alias /usr/syno/share/nginx/logo.jpg; } error_page 403 404 500 502 503 504 @error_page; location @error_page { root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } location ^~ /.well-known/acme-challenge { root /var/lib/letsencrypt; default_type text/plain; } include app.d/.location.webstation.conf*; location / { rewrite ^ / redirect; } location ~ ^/$ { rewrite / http://$host:5000/ redirect; } } server { listen 443 default_server ssl; listen [::]:443 default_server ssl; server_name _; location ~ ^/volume(?:X|USB|SATA|Gluster)?\d+/ { internal; root /; open_file_cache off; include app.d/x-accel.*.conf; include conf.d/x-accel.*.conf; } include app.d/www.*.conf; include app.d/alias.*.conf; include /usr/syno/share/nginx/conf.d/www.*.conf; include conf.d/www.*.conf; location = /webdefault/images/logo.jpg { alias /usr/syno/share/nginx/logo.jpg; } error_page 403 404 500 502 503 504 @error_page; location @error_page { root /usr/syno/share/nginx; rewrite (.*) /error.html break; allow all; } location ^~ /.well-known/acme-challenge { root /var/lib/letsencrypt; default_type text/plain; } include app.d/.location.webstation.conf*; location / { rewrite ^ / redirect; } location ~ ^/$ { rewrite / https://$host:5001/ redirect; } } include conf.d/http.*.conf; include app.d/server.*.conf; include sites-enabled/*; } I notice the line set_real_ip_from appears twice with two different addresses. Could that mess things up? I don't see that line or the other real_ip lines above it at all in your file. I've tried removing one of the addresses, removing both, removing both and the real_ip lines above and also adding the set_real_ip_from line into the server block in the file below, none of that seemed to make a difference. app.d/server.ReverseProxy.conf server { listen [::]:443 ssl http2; ## Listens on port 443 IPv6 with http2 and ssl enabled listen 443 ssl http2; ## Listens on port 443 IPv4 with http2 and ssl enabled proxy_buffering off; ## Sends data as fast as it can not buffering large chunks. server_name emby.mydomain.com; ## enter your service name and domain name here example emby.domainname.com ## SSL SETTINGS ## ssl_session_timeout 30m; ssl_protocols TLSv1.2 TLSv1.1 TLSv1; ssl_certificate /usr/syno/etc/certificate/ReverseProxy/f76810b3-5a58-4602-ac82-c7bbed40243c/fullchain.pem; ## Location of your public PEM file. ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/f76810b3-5a58-4602-ac82-c7bbed40243c/privkey.pem; ## Location of your private PEM file. ssl_session_cache shared:SSL:10m; location ^~ /swagger { ## Disables access to swagger interface return 404; } location / { proxy_pass http://127.0.0.1:8096; ## Enter the IP and port of the backend emby server here. proxy_hide_header X-Powered-By; ## Hides nginx server version from bad guys. proxy_set_header Range $http_range; ## Allows specific chunks of a file to be requested. proxy_set_header If-Range $http_if_range; ## Allows specific chunks of a file to be requested. proxy_set_header X-Real-IP $remote_addr; ## Passes the real client IP to the backend server. #proxy_set_header X-Real-IP $http_CF_Connecting_IP; ## if you use cloudflare un-comment this line and comment out above line. proxy_set_header Host $host; ## Passes the requested domain name to the backend server. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ## Adds forwarded IP to the list of IPs that were forwarded to the backend server. ## ADDITIONAL SECURITY SETTINGS ## ## Optional settings to improve security ## ## add these after you have completed your testing and ssl setup ## ## NOTICE: For the Strict-Transport-Security setting below, I would recommend ramping up to this value ## ## See https://hstspreload.org/ read through the "Deployment Recommendations" section first! ## add_header 'Referrer-Policy' 'origin-when-cross-origin'; add_header Strict-Transport-Security "max-age=15552000; preload" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; ## WEBSOCKET SETTINGS ## Used to pass two way real time info to and from emby and the client. proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; } } Would the fact Emby is in Docker have an impact? The route is something like this Client --> https://emby.mydomain.com --> frps Docker (VPS) --> frpc Docker (Synology) --> nginx (Synology) --> Emby Docker (Synology) If my nginx config above looks good then the client IP must be lost somewhere else along the way? The Emby Docker is in host mode. lol, I'm not even going to try to follow these configs.. I have to go to work, but I would suggest renaming the base nginx.cfg to save it, and paste my config into a new nginx.cfg start fresh as a test.. The problem with these prebuilt docker nginx configs is that they use "include" to link to other configs, that also have includes that link to other configs... its a rabbit hole to follow.. Nothing wrong with that, HUGE commercial configs should be done like this, its the only easy way to maintain them. But home setups with no more than 5 or so services, I personally prefer a single config file that can be read top to bottom and followed. But i would start with a clean config like i said above, then we can work on your prebuilt includes config and fix it up if you like. there is probably something in those other includes that is overwriting or just ignoring your changes. include /var/tmp/nginx/trusted_proxy/*.conf; Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 28, 2021 Share Posted May 28, 2021 (edited) 1 hour ago, pir8radio said: lol, I'm not even going to try to follow these configs.. I have to go to work, but I would suggest renaming the base nginx.cfg to save it, and paste my config into a new nginx.cfg start fresh as a test.. The problem with these prebuilt docker nginx configs is that they use "include" to link to other configs, that also have includes that link to other configs... its a rabbit hole to follow.. Nothing wrong with that, HUGE commercial configs should be done like this, its the only easy way to maintain them. But home setups with no more than 5 or so services, I personally prefer a single config file that can be read top to bottom and followed. But i would start with a clean config like i said above, then we can work on your prebuilt includes config and fix it up if you like. there is probably something in those other includes that is overwriting or just ignoring your changes. include /var/tmp/nginx/trusted_proxy/*.conf; lol no worries. I replaced the nginx.cfg with your template so there's no includes in play, just your template. Only thing I added was correct domain name and SSL paths. Syntax ok, test successful, reloaded nginx. Stopped and restarted Emby. Emby is accessible but still showing all remote traffic as 127.0.0.1 Edited May 28, 2021 by niallobr Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 28, 2021 Share Posted May 28, 2021 (edited) 4 hours ago, niallobr said: lol no worries. I replaced the nginx.cfg with your template so there's no includes in play, just your template. Only thing I added was correct domain name and SSL paths. Syntax ok, test successful, reloaded nginx. Stopped and restarted Emby. Emby is accessible but still showing all remote traffic as 127.0.0.1 interesting.... what is your physical network setup again? pm me (if you want) your server url. like... internet-----router----[docker {nginx----emby}] or whatever... Edited May 28, 2021 by pir8radio Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 28, 2021 Share Posted May 28, 2021 25 minutes ago, pir8radio said: interesting.... what is your physical network setup again? pm me (if you want) your server url. like... internet-----router----[docker {nginx----emby}] or whatever... Ok, hope this makes sense Remote client --> https://emby.mydomain.com (Cloudflare CDN OFF) --> VPS (frp server [Docker]) --> Router --> Synology NAS (frp client [Docker] --> NGINX --> Emby [Docker]) Router is behind CGNAT hence the tunnel. frp on Github. It was very easy to set up but there aren't many guides. If the problem is with frp I was going to try do a cloudflared tunnel instead. I'll PM you now thanks Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 28, 2021 Share Posted May 28, 2021 5 minutes ago, niallobr said: Ok, hope this makes sense Remote client --> https://emby.mydomain.com (Cloudflare CDN OFF) --> VPS (frp server [Docker]) --> Router --> Synology NAS (frp client [Docker] --> NGINX --> Emby [Docker]) Router is behind CGNAT hence the tunnel. frp on Github. It was very easy to set up but there aren't many guides. If the problem is with frp I was going to try do a cloudflared tunnel instead. I'll PM you now thanks Oh, im sorry dude, i missed the whole tunnel part.. Try changing: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; to: proxy_set_header X-Forwarded-For $http_CF_Connecting_IP; lets see what that does, then if it works should be easy to fix your other config.. I assume it will work with the "orange cloud" (CDN OFF) off. Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 28, 2021 Share Posted May 28, 2021 17 minutes ago, pir8radio said: Oh, im sorry dude, i missed the whole tunnel part.. Try changing: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; to: proxy_set_header X-Forwarded-For $http_CF_Connecting_IP; lets see what that does, then if it works should be easy to fix your other config.. I assume it will work with the "orange cloud" (CDN OFF) off. No problem at all ok I've set that and reloaded NGINX but the problem is still there. I'll try restart Emby too. Do I have to uncomment this line? #proxy_set_header X-Real-IP $http_CF_Connecting_IP; ## if you use cloudflare un-comment this line and comment out above line. My domain is hosted on Cloudflare but I'm not using the CDN feature (orange cloud is off). SSL type is flexible. Would any other CF features cause problems? Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 28, 2021 Share Posted May 28, 2021 (edited) 4 minutes ago, niallobr said: No problem at all ok I've set that and reloaded NGINX but the problem is still there. I'll try restart Emby too. Do I have to uncomment this line? #proxy_set_header X-Real-IP $http_CF_Connecting_IP; ## if you use cloudflare un-comment this line and comment out above line. My domain is hosted on Cloudflare but I'm not using the CDN feature (orange cloud is off). SSL type is flexible. Would any other CF features cause problems? no, what happens with CDN on, just as a test keeping the config you just entered with x-forwarded-for CF-connecting ip. I think the nat is whats messing you up. Edited May 28, 2021 by pir8radio Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 28, 2021 Share Posted May 28, 2021 Ok CDN on now but still the same issue. Not sure if the CF changes propagate instantly or takes a while? If I have CDN on should I uncomment that line above in the nginx.conf or still leave commented out? Do you mean my local NAT could be causing the problem? Or carrier NAT? It's definitely making things a bit tricky Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 28, 2021 Share Posted May 28, 2021 49 minutes ago, niallobr said: Ok CDN on now but still the same issue. Not sure if the CF changes propagate instantly or takes a while? If I have CDN on should I uncomment that line above in the nginx.conf or still leave commented out? Do you mean my local NAT could be causing the problem? Or carrier NAT? It's definitely making things a bit tricky I feel like the tunnel is accessing your network from a local or null IP. Not sure why the headers are not going through. Try this as a troubleshooting step: proxy_set_header X-Real-IP 1.2.3.4; proxy_set_header X-Forwarded-For 1.2.3.4; restart nginx, then hit your emby server see if emby shows users connecting from 1.2.3.4 Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 28, 2021 Share Posted May 28, 2021 (edited) 4 hours ago, pir8radio said: I feel like the tunnel is accessing your network from a local or null IP. Not sure why the headers are not going through. Try this as a troubleshooting step: proxy_set_header X-Real-IP 1.2.3.4; proxy_set_header X-Forwarded-For 1.2.3.4; restart nginx, then hit your emby server see if emby shows users connecting from 1.2.3.4 Yep, I can see users with 1.2.3.4 now. The frp docs say this, which isn't really much info. Get Real IP HTTP X-Forwarded-For This feature is for http proxy only. You can get user's real IP from HTTP request headers X-Forwarded-For and X-Real-IP. https://github.com/fatedier/frp#get-real-ip Edit: Does Emby do some caching of IP's? I removed 1.2.3.4 completely from the nginx.conf and reverted, restarted nginx and emby and I'm still showing up as 1.2.3.4 on the Emby dashboard? Maybe NGINX is not receiving a client IP now that I have $http_CF_Connecting_IP back in so it's still showing the last IP it received (1.2.3.4)? Edited May 29, 2021 by niallobr Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted May 29, 2021 Share Posted May 29, 2021 3 hours ago, niallobr said: Yep, I can see users with 1.2.3.4 now. The frp docs say this, which isn't really much info. Get Real IP HTTP X-Forwarded-For This feature is for http proxy only. You can get user's real IP from HTTP request headers X-Forwarded-For and X-Real-IP. https://github.com/fatedier/frp#get-real-ip Edit: Does Emby do some caching of IP's? I removed 1.2.3.4 completely from the nginx.conf and reverted, restarted nginx and emby and I'm still showing up as 1.2.3.4 on the Emby dashboard? Maybe NGINX is not receiving a client IP now that I have $http_CF_Connecting_IP back in so it's still showing the last IP it received (1.2.3.4)? no it shouldnt remember the last ip. But the fact that 1.2.3.4 worked means nginx isnt getting the correct IP from your tunnel, and for some reason, im not sure why, useable headers are not being sent either.. 1 Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 29, 2021 Share Posted May 29, 2021 Yes thanks I think you're right. I wonder at which point its being dropped... Anyway I decided to take a look at https://hub.docker.com/r/erisamoe/cloudflared and I had a Cloudflare/Argo tunnel up and running in 10 minutes. It's connecting to Emby and the remote IP is being detected perfectly To anyone with a similar problem or using a NAS/Docker I would consider this as a good option, it was incredibly quick and easy to set up. Thanks for the help troubleshooting and your patience @pir8radio 1 Link to comment Share on other sites More sharing options...
Carlo 4330 Posted May 29, 2021 Share Posted May 29, 2021 Unless they've changed pricing on Argo that could get expensive to use for a home server. Last I looked, Argo is priced at $5/domain monthly, plus $0.10 per GB of transfer from Cloudflare to your visitors. Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 29, 2021 Share Posted May 29, 2021 Yes it was but I think they made it free last month (for reasonable-ish amounts of traffic, less than 1TB) so good timing https://blog.cloudflare.com/tunnel-for-everyone/ Quote In the past, Argo Tunnel has been priced based on bandwidth consumption as part of Argo Smart Routing, Cloudflare’s traffic acceleration feature. Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic. I can't see anything in the billing area of my Cloudflare account yet so I think this might be true. I'll keep an eye on it, just in case. Hope this helps someone Link to comment Share on other sites More sharing options...
Carlo 4330 Posted May 29, 2021 Share Posted May 29, 2021 It's my understanding that Cloudflare Tunnel (between you and Cloudflare) is now free but not the advanced routing of Clousflare to end users (Argo). So just make sure you have the correct one setup. Link to comment Share on other sites More sharing options...
niallobr 9 Posted May 29, 2021 Share Posted May 29, 2021 Yep I think you're right. Argo can be checked under the 'Traffic' section of the zone on the Cloudflare dashboard. Currently Argo is showing as disabled for me with an option to Enable it but the tunnel is up and running fine, so just something to be aware of and check 1 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