rejetto
Downloads are not counted as downloads in monitoring menu
BEFORE
- Are you using a reverse-proxy, like nginx?
- Cloudflare
To Reproduce
- Start downloading something from yourself
- Go to Monitoring
- Check both tabs
Describe the bug Downloads are not shown in "downloads+uploads", only in "all connections"
Expected behavior Downloads are shown in "downloads+uploads"
Screenshots
Environment (please complete the following information):
- OS: Windows 10 22H2
- HFS 0.57.1
- Firefox 138
Additional context Strangely, this doesn't happen always:
i'm not sure how to reproduce it, i only saw this behaviour once, confirmed it's real and filled an issue. in logs, i couldn't find any difference between mentioned requests (both are GET, 200, dl: 1, full download...)
Am experiencing the same issue when using Cloudflare in front of HFS.
rec32 stated this only rarely happens to him. What about you? Does it always happen?
Am experiencing the same issue when using Cloudflare in front of HFS.
rec32 stated this only rarely happens to him. What about you? Does it always happen?
It seems to happen intermittently only when downloading from the same public IP as the HFS server (and using Cloudflare proxy). The reported IP address is correct which I am a little confused how that is happening since if I were using a reverse proxy behind Cloudflare there would need to be additional config ie X-Forwarded-For in order to report proper client public IP's.
Anyways, when someone besides my own public IP is downloading it is being shown in the Monitor page properly - https://is.gd/cn020q
so, even with CF, it doesn't always happen. That makes hard to investigate.
on HFS surely you have set the number of proxies to 1, to see the proper client public ip. I guess CF is already configured to use x-forwarded-for, so you don't need nothing else.
i also suggest to set split-uploads option to 100MB because cloudflare has such limit.
so, even with CF, it doesn't always happen. That makes hard to investigate.
on HFS surely you have set the number of proxies to 1, to see the proper client public ip. I guess CF is already configured to use x-forwarded-for, so you don't need nothing else.
i also suggest to set split-uploads option to 100MB because cloudflare has such limit.
Check out this screenshot. Also I don't allow uploads, so that's not relevant in my case.
ok, that looks exactly what this thread is talking about, you are having some downloads that are not considered as such, and since you have "show downloads+uploads" instead of "all connections", they are not even displayed. I guess that this is always happening behind CF, but sadly i can't see any useful clue on how to fix it.
ok, that looks exactly what this thread is talking about, you are having some downloads that are not considered as such, and since you have "show downloads+uploads" instead of "all connections", they are not even displayed. I guess that this is always happening behind CF, but sadly i can't see any useful clue on how to fix it.
For one thing, you probably already know this but when using CLoudflare (orange clouded), the clients IP never hits the server, it will always be one of Cloudflare's public IP's instead.
Even if I changed it to 'Show all connections' instead of 'Show downloads+uploads', it still won't show what it should. It shows a bunch of Cloudflare IP's with 0B and my own requests at /~/api/*.
For what it's worth, my hfs site is https://hfs.opendir.org. I can give you the login if needed.
i don't know CF specifically, or orange clouded, but with a standard "reverse-proxy" it is not strange that the client doesn't see the real server's IP.
If you are seeing CF's ip instead of the client's, then you probably didn't do what i said in my previous message: "on HFS surely you have set the number of proxies to 1". What do you see in your admin-panel homepage?
i don't know CF specifically, or orange clouded, but with a standard "reverse-proxy" it is not strange that the client doesn't see the real server's IP.
If you are seeing CF's ip instead of the client's, then you probably didn't do what i said in my previous message: "on HFS surely you have set the number of proxies to 1". What do you see in your admin-panel homepage?
and despite that you are still seeing CF's IPs ? are you sure? can you tell me one?
and despite that you are still seeing CF's IPs ? are you sure? can you tell me one?
Now it's showing downloads again properly. Seems to be truly an intermittent issue. Here's some more screenshots I just took:
The 172.x.x.x and 162.x.x.x are Cloudflare IP's. Here are the Cloudflare IP blocks: https://www.cloudflare.com/ips-v4/ https://www.cloudflare.com/ips-v6/ They are also accessible here: https://www.cloudflare.com/ips/
If I were using an NGINX reverse proxy with cloudflare, these directives are what I would use:
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
real_ip_header CF-Connecting-IP;
Could this issue have something to do with HTTP/3? Cloudflare tries to use that by default between CF and client (and uses either HTTP/2 or HTTP1.1 between CF and the origin server).
Could this issue have something to do with HTTP/3?
You can test it by disabling HTTP/3 through dash.cloudflare.com
i managed to set up a CF domain for a test, and i'm reproducing the problem: you just download a file while you are already in "monitoring". the connection of the download is actually in the list, but it's not receiving updates, and appears silent. the problem goes away as soon as you reload the page.
i managed to fix the bug 🙂 it affects proxies in general. will publish asap.