is there something i need to change about the fossil configuration before interacting with it through the web? or is there something wrong with the way caddy is passing headers? or...?

The check that is failing is technically correct, but it's unfortunate for your particular configuration. i'm not certain that we can resolve this check without making fossil more susceptible to attacks on "normal" setups (yours is somewhat exotic). We'll need to look into that, but i don't have an immediate solution for you.

Perhaps someone with experience using a reverse-proxied solution can suggest a tweak to "caddy" (whatever caddy is) to straighten this out. Numerous people have set up reverse proxying without having reported this error, so my suspicion is that caddy is failing to do something or other.

a container with duval/fossil

Is there any particularly good reason you're using that one instead of mine, which is based on Fossil's own Dockerfile, also created and maintained by me? I looked into this other container, and it seems the key differences are:

• Based on Alpine, so you're left with a package manager and a basic Linux userland inside the container, including a shell and other powerful tools like wget, even though Fossil doesn't need any of that. Mine starts with Alpine for building, but then pares all that away until it's left with a single static binary.

• LibreSSL instead of OpenSSL. This change I like, but since Alpine doesn't ship static LibreSSL libraries, it's no option for my container unless I'm willing to build LibreSSL from source. Tempting, but for now, no.

• JSON API enabled. It should be safe, but I don't see why you'd enable that feature unless you had a specific need for it.

• TH1 docs enabled. Ditto, except that…

• Tcl enabled, which combines with the prior item to potentially give anyone with checkin rights on your repo the ability to execute arbitrary shell commands. This plus Alpine gives dodgy committers an island inside your server LAN from which to branch out.

  That risk exists only if you create the container with a non-default user (e.g. docker create --user fred) without which this container falls back to the implicit USER root setting, which triggers Fossil's chroot jail feature to wall that risk away. Alas, it then goes and leaves the jail unconfigured. If nothing else, it should create a few /dev nodes inside there, per the prior link.

  If you fix that, it then begs the question, "So why do you need the Alpine environment in the final running container, then?" If it's just for the option of getting a debugging shell, that's better handled on an as-needed basis, as shown here.

• Their README tells you to bind-mount just the repo DB file, not the directory containing it, risking corruption if you ever switch the repo into WAL mode.

There are also style problems in the duvel/fossil container, including putting the repo under /opt/fossil. Under the LHS rules, that's the top-level for a program, not a data directory. If they want to follow that pattern, the binary would go in /opt/fossil/bin/fossil and the data in /opt/fossil/var.

If you still want persuading, give our container docs a skim. I'm biased as all heck on this, but I do believe I've taken a more thoughtful approach to this.

proxied by caddy as follows:

I know almost nothing about Caddy, but I was able to get Docker, Inc's official Caddy container it to proxy our official Docker container easily enough:

$ cd ~/src/fossil/trunk
$ make container-run
$ docker run -it --rm -p 80:80 \
  -v config:/config \
  -v data:/data \
  caddy caddy \
  reverse-proxy --from :80 --to 192.0.2.42:8080 

Replace the IP in the final line with the public IP of the Fossil server.

I don't claim this to be a production-grade solution, but it should be enough to get you moving toward a workable solution. I suspect proxying to the outward-facing IP instead of the internal Docker NAT IP may be enough to get you over the hump.