This is the standard approach for this kind of scenario:
example.com {
route /ds-vpath/* {
uri strip_prefix /ds-vpath
reverse_proxy http://nextcloud_office
}
reverse_proxy http://nextcloud_app
}
You can test that Caddy is routing this logic correctly by running this exact Caddyfile:
http://:8080 {
route /ds-vpath/* {
uri strip_prefix /ds-vpath
reverse_proxy localhost:8081
}
reverse_proxy localhost:8082
}
http://:8081 {
respond "8081 {uri}" 200
}
http://:8082 {
respond "8082 {uri}" 200
}
And I do some quick tests to confirm the expected behaviour:
~/Projects/test
➜ ./caddy version
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=
~/Projects/test
➜ curl -iL localhost:8080/stuff
HTTP/1.1 200 OK
Content-Length: 11
Date: Mon, 06 Jul 2020 23:29:10 GMT
Server: Caddy
Server: Caddy
Content-Type: text/plain; charset=utf-8
8082 /stuff⏎
~/Projects/test
➜ curl -iL localhost:8080/ds-vpath
HTTP/1.1 200 OK
Content-Length: 14
Date: Mon, 06 Jul 2020 23:29:16 GMT
Server: Caddy
Server: Caddy
Content-Type: text/plain; charset=utf-8
8082 /ds-vpath⏎
~/Projects/test
➜ curl -iL localhost:8080/ds-vpath/
HTTP/1.1 200 OK
Content-Length: 6
Date: Mon, 06 Jul 2020 23:29:18 GMT
Server: Caddy
Server: Caddy
Content-Type: text/plain; charset=utf-8
8081 /⏎
In this manner I have demonstrated that requests to /ds-vpath/
have the prefix stripped before being proxied to a specific upstream, whereas other requests (including /ds-vpath
, no trailing slash) are sent to the catch-all upstream.