Can't make reverse_proxy to play nicely with redirects (minio, netdata, urbit)

1. Caddy version (caddy version):

2. How I run Caddy:

a. System environment:

  • docker-compose
  • x86, aarch64

b. Command:

caddy run --config /etc/caddy/Caddyfile

d. My complete Caddyfile or JSON config:

:80 {
  log {
    output stdout
    level INFO
 uri replace /~* /urbit/~*
 redir /apps/ /urbit/apps/

  handle_path /admin/* {
    reverse_proxy localhost:2019
  handle_path /netdata/* {
    reverse_proxy netdata:{$NETDATA_PORT:19999}
  handle_path /minio-api/* {
    reverse_proxy minio-s3:{$MINIO_API_PORT:9000}
  handle_path /minio/* {
        reverse_proxy minio-s3:{$MINIO_DASHBOARD_PORT:9001} {
            header_up X-Forwarded-Proto {schema}
            header_up X-Forwarded-Host {host}
                header_up Host {host}:9000

  handle_path /urbit/* {
        reverse_proxy urbit:{$URBIT_DASHBOARD_PORT:80}

3. The problem I’m having:

  • /minio/ is a blank screen
  • The urbit service does a bunch of redirects that I want to foresee:
    • / will redirect to /~/login
    • After login, it will redirect to /apps/grid/ . Every subsequent path will be /apps/grid/X
    • It may load assets from /~<asset>. Note it’s not necessarily /~/X.

So, what I want really is to foresee for all these possible redirects and paths and simply replace /PATH with /urbit/PATH. This will kick the handle_path directive and everything will work out, as caddy will deliver the request PATH to the appropriate container (urbit).

Currently, this doesn’t work. For example, when I open /apps/grid/ and I click on a selection, it opens a new window to /apps/grid/X, while I would expect to replace /apps/ with /urbit/apps, thus kicking off the correct handle_path.

I am new to Caddy, but I have spent about 2 days trying to make this work. The software is really impressive, so I am really thankful for your help :slight_smile: .

5. What I already tried:

  • Spent a couple of hours trying different combinations of redir, rewrite, uri and combing minio and other resources.
  • Every service(container) is accessible via direct port (e.g localhost:9001 for minio). In the end-build the ports will not be exposed, but while developing they are.

6. Links to relevant resources:

You’re running into the issue described in this article:

I strongly recommend that you use subdomains for each service instead of serving them all under different subpaths.

Many services are not designed to be run under a different subpath. It’s not something you can really solve directly with Caddy. It’s easiest to just give those services a whole subdomain instead, if they don’t have configuration options to allow changing the “base path”.

@francislavoie – hanks for the article! It has so much info to dig into.

i thought about that, but the thing is that it’s an IoT application, so a lot of times I use IP to access the device.

I assume I should use hosts file to properly use the subdomain. The caddy file will detect the connection request to it’s port (say 80) and redirect based on the subdomain used, right?

Although I am very stubborn and detest the idea of surrendering, I think that spending more hours on this to make it work doesn’t really make sense. Perhaps it’s best to use the domain route.

Thanks for this :slight_smile:

This topic was automatically closed after 30 days. New replies are no longer allowed.