With an upstream of
192.168.1.4:5002/home, a request for
example.com with a URI that matches the basepath
/tixati will be forwarded to
192.168.1.4:5002/home and the full URI appended, i.e:
So you can see that Caddy treats the
/home part as part of the upstream domain, before the URI is appended. This means you will see
/home at the start of every request the upstream receives, which seems unlikely to be desirable behaviour.
But with an upstream of just
192.168.1.4:5002, you’ll see:
Which is what I would normally expect to be the desired behaviour. When you also add
without /tixati, Caddy should strip
/tixati from the start of the URI, and it should work like this:
Yes, technically, with your proxy to
192.168.1.4:5002/home, but as explained above that proxy will prevent any other requests from behaving as expected through the proxy.
What you probably want to be doing is requesting
example.com/tixati/home, which should show you the main page as expected.
The second step sounds like
http.filter is working great, but again, because your proxy is to
192.168.1.4:5002/home, your upstream is getting a request for
192.168.1.4:5002/home/transfers, the result of which might look fine but I suspect that its ostensible functionality is coincidental; likewise a request for
example.com/tixati/log is being sent to
192.168.1.4:5002/home/log. These don’t look like properly formed requests to me.
Again from what I am seeing you probably want to
proxy /tixati 192.168.1.4:5002 (sans
/home) and direct your requests to
example.com/tixati/home for the homepage. Appending
/home to the upstream URL is not a good way to solve the redirect issue.