I am running this docker image: https://github.com/nextcloud/docker with a cloudflare tunnel, meaning the webserver would see all the traffic coming from a single ip in 172.16.0.0/12 .
The documentation says:
The apache image will replace the remote addr (IP address visible to Nextcloud) with the IP address from X-Real-IP if the request is coming from a proxy in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 by default
So I thought that this is a not a problem, as other docker images can also automagically figure out the real IP address from traffic coming from cloudflare tunnels.
In the beginning it worked fine, then it was SLOW. Like 2 full minutes to load new feeds on news, waiting ages to complete a sync, and so on. I rebooted the server on those instances, and then it worked fine for a day.
So because at the time i was running it on unraid, i blamed the lag on that OS + my weird array of HDDs with decades of usage on them. Migrated to debian on a nvme array and… same lag!
Wasted hours trying to use caddy+fpm instead of apache and it’s the same, worked fine for a day, then it was slow again.
Then I wondered: what if the program is “smart” and throttles it by itself without any warning to the admin if it thinks that an ip address is sending too many requests?
Modified the docker compose like this:
nextcloud:
image: nextcloud
became
nextcloud:
build: .
and I created a Dockerfile with
FROM nextcloud
RUN apt update -y && apt upgrade -y
RUN apt install -y libbz2-dev
RUN docker-php-ext-install bz2
RUN a2enmod rewrite remoteip
COPY remoteip.conf /etc/apache2/conf-enabled/remoteip.conf
with this as the content of remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 10.0.0.0/8
RemoteIPTrustedProxy 172.16.0.0/12
RemoteIPTrustedProxy 192.168.0.0/16
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/12
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32
RemoteIPTrustedProxy 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32
RemoteIPTrustedProxy 2a06:98c0::/29
RemoteIPTrustedProxy 2c0f:f248::/32
and now because nextcloud is seeing all the different ip addresses it doesn’t throttle the connections anymore!
Simple reason: at home I don’t have a static IPv4 address and I can’t do port forwarding
What about ddns?
Edit: never mind reread your comment and saw the port forwrding caveat. Sorry pal.
Thx, that is a good reason to do it. I’m eventually going to lose my static IPv4 address, too. But I’m preparing to move some of my services to a VPS instead and in the process set up the firewall and the reverse proxy to the Nextcloud on my homeserver and so on there (on that VPS.)
I don’t have a static IP but host services off my paid domain. I use duckdns and point host records to the duckdns address. I have to use CloudFlare to manage my DNS records for this to work.
https://developers.cloudflare.com/dns/cname-flattening/
I do the same but I just use a script that runs periodically to update CloudFlare with my current IP with their native API.
Ah. Makes sense. I don’t think you have to specifically use cloudflare in that case. But I remember CNAME records can’t be used for everything… there are some limitations. I know I had issues with dyndns and a domain at some point. I just can’t remember the details. I know it didn’t work with every registrar / DNS provider. But some of them offer some magic to make some things work. I believe back then we ended up transferring that domain to some other hoster. And my domains are with a company that offers an API. I can just have a small script run in the background that changes around entries and do dyndns that way. But obviously you need to pay attention to things like the time to live for your records and set it accordingly once you do dyndns yourself.
The CNAME flattening is not a regular feature of DNS, so I have to use Cloudflare. Maybe other providers do the same, but I haven’t looked around. It’s certainly not something namecheap offer.
I point my TLD to the dynamic DNS record and then point to other records to the TLD as CNAME records. I’m using Nginx Proxy Manager to reverse proxy traffic to different services. These all live on a Raspberry Pi 4.
Imgur
https://www.namecheap.com/support/knowledgebase/article.aspx/10128/2237/how-to-create-an-alias-record/
https://kb.porkbun.com/article/85-how-to-connect-your-root-domain-when-your-web-host-wont-provide-an-ip-address
Took me a while to remember… I think other providers don’t call it CNAME flattening, but ALIAS records. And namecheap lists them in their documentation. You maybe need to look it up if you’re interested, but I think they do in fact offer it. (I mean I’m not advertising for or against anything here. If you’re happy with your provider and your setup works, that’s fine. It’s definitely not available everywhere.)
Awesome info! I wasn’t overly happy with having to use CloudFlare for just this one feature. I’ll have a test with my registrar.
Get a $15/year VPS and run your own tunnel using Wireguard.