Remove this. This is already the defaults, so setting this has no use. It’ll only prevent future versions of Caddy from automatically providing theoretical TLS 1.4 support, if it later adds support for it. Let Caddy do the smart thing.
Caddy never emits access logs at lower than INFO, so setting DEBUG here won’t do anything.
To clarify, you configured access logs, which are not the same as Caddy’s runtime logs (which are emitted to stdout/stderr by default). Those do have debug logs. You can use the debug global option to turn those on, or use the log global option (not directive, as in, configure it in the global options block, not within a site block) to customize them further.
Remove these, those are already the defaults as well.
Sounds like you want a rewrite, not a redirect. Different things. An HTTP redirect is a special kind of HTTP response which tells the browser “hey, make a new request at this new path, please!” It uses the Location header as the target location. See the log you posted, you can see that header there. But that doesn’t make sense here because localhost:7777 is a backend which your client cannot (or should not) directly access.
A rewrite is an internal modification of the path (and/or query) of the request before continuing handling. It sounds like what you want is to rewrite the URL to remove /fileserver1 from the front of the URL (which handle_path will do for you implicitly), and then replace it with /client01. So to do that, do this:
handle_path /fileserver1/* {
rewrite * /client01{uri}
reverse_proxy localhost:7777
}
Also, you can remove your route directives wrapping the handle_path, they don’t do anything for you, they’re redundant. And replace your last route with a handle which will act as your fallback for otherwise not matched handles.