In a Jail on a TrueNAS (FreeBAD) server, deployed using a script by DanB35. Caddy serves a handful of static HTML sites, and a few reverse proxies to other jails on the same host server. URL is speedtest.aiskon.net
a. System environment:
TrueNAS 13 (Base OS of FreeeBSD), running in a Jail that runs FereeBSD 13.1
OpenSpeedTest closed the issue on their end, as they noted their script works, and this is a Web Server configuration issue. What I need at this point is how to configure Caddy to work with OST, possibly by using the configs provided for NGINX as a basis.
FWIW, I ran the speed test against your site myself on my 1gbps connection, and I got different results – I got 39Mbps down and 879Mbps up. This was on Firefox. That’s about right for the upload speed, but download speed is too low.
Tried on Chrome, and I got 22Mbps down, 39582Mbps up. So it definitely seems like something weird with Chrome. It seems to just “upload” 16 byte chunks instead of sending the whole payload as it should, which completely throws off the upload numbers.
For the downloads, there might be some bottleneck because of this issue, we don’t actually use sendfile for Caddy’s file server currently, due to how our middleware pipeline works (but not to the extent of making gigabit seem like DSL speeds):
I do see some add_header stuff in the nginx config, you might need to copy some of those over to your Caddy config, in particular the Cache-Control.
There’s a commented chunk in the nginx config that mentions:
HTTP2 will return 200 withot waiting for upload to complete. it’s smart but we don’t need that to happen here when testing upload speed on HTTP2
Caddy does enable HTTP/2 by default, so this could be the explanation for the wild numbers for Chrome. You might need to use reverse_proxy in that case for the upload tests to work correctly. I don’t really understand the suggested config though. Is there actually a running daemon for OpenSpeedTest or is it just static files? It seems like it’s just proxying to 127.0.0.1:80 which in the case of Caddy would just result in an HTTP->HTTPS redirect response, probably not correct. You’ll need to ask how that works.
This is running on a TrueNAS on my home internet connection, which is a Comcast cable modem. Speeds are about 400 down / 20 up from my home PC to the outside world, so those do make some sense (it varies when I run my tests at home to an outside server, depending on the day & other users on my node, I think.)
I did have it in its own Jail (VM) on the NAS at one point, but it proved to be a pain to forward to from the outside. Instead, I put it on the same Caddy server I use to serve up a static www site, and then also reverse proxy to other Jails (VMs) on the NAS, such as NextCloud, Piwigo, etc. Because OST is just a set of static files, I was hoping it would make more sense to just share it off my main Caddy server instead of making a new NGINX server for it.
Well it seems like the way this thing works relies on HTTP/1.1, but Caddy enables HTTP/2 (and in the next version, also HTTP/3 by default) so
It will be possible to disable h2/h3 in the next release (or build from master right now) to only use h1, but that would disable it for your whole server. You could run it on a different port though, which would let you change settings just for that server.