How should Anubis sit in front of a Tomcat app under a subpath?

Start by tracing the path at each hop rather than changing proxy software. The browser should request the challenge URL on the public host, Apache should pass that request to Anubis, and Anubis should send the app traffic to Tomcat. Check the Apache proxy rules for the challenge path as well as /thredds, since a rule that only covers the app prefix may leave the challenge endpoint unmatched.

The missing /thredds in the failing URL is a useful clue. The app may be generating an absolute redirect or challenge link from its context path, while a proxy rule is forwarding or rewriting paths differently. Compare the exact browser request with Apache’s access log, then verify what path Anubis receives and what it sends upstream. Also confirm whether Tomcat expects the /thredds prefix or whether the proxy is meant to strip it.

Check the public scheme and host that the application sees too. With HTTPS ending at Apache, Tomcat or Anubis may otherwise build redirects using the wrong scheme, host, or base path. Review the forwarded headers and Tomcat’s proxy settings, then test whether the generated challenge URL stays on the public hostname and retains the correct route.

I’d simplify the routing temporarily to locate the break. Test Anubis directly with a request for the app path, then test the challenge endpoint through Apache, checking status codes and logs at each layer. Once the failing hop is clear, adjust only that proxy mapping. A suggestion to switch to another web server doesn’t address the underlying path or header mismatch.