Caddy 子路径代理跳回根路径：应用还需要配置 base URL

应用直接通过 reverse_proxy 访问正常，放到 /files/ 后却跳到 /login.aspx，或者首页能打开、脚本和样式返回 404。对于 Caddy 2 的 handle_path，应同时检查传给上游的路径和应用生成的链接：去掉请求前缀，不会自动给响应中的 URL 加回前缀。

这条处理路径适用于将原本运行在站点根目录的 Web 应用放进子路径。若故障是连不上上游、TLS 握手失败或应用自己返回错误，应先处理对应问题。

看浏览器第二次请求去了哪里

打开浏览器开发者工具的网络面板，从 /files/ 进入应用，观察重定向的 Location、登录请求和失败资源地址。以下是用于解释的示例：

初始请求：/files/
上游收到：/
响应跳转：/login.aspx
浏览器随后请求：/login.aspx

最后一条已经不在 /files/ 下，可能落到 Caddy 的其他路由。页面里的 /css/site.css、/api/session 也有同样的问题。这样可以区分“第一条请求没有正确代理”和“响应让后续请求走错了位置”，不要只凭首页的 404 改端口。

如果上游日志反而显示 /files/，先检查实际生效的是 handle 还是 handle_path。前者不会隐式去掉前缀，后者会；它们不是可互换的写法。

子路径配置需要和应用的路由方式配合

下面是配置结构示例。它假设应用对外支持 /files/ 这个 base URL，但内部请求仍按根路径处理：

example.com {
    redir /files /files/ 308

    handle_path /files/* {
        reverse_proxy 127.0.0.1:8080
    }

    handle {
        respond "Not found" 404
    }
}

域名、上游和默认路由按实际部署替换；已有网站的默认处理不能直接换成这里的 404。单独处理 /files，再用 /files/* 匹配子路径，避免 /files* 把 /files-old 等名称也纳入应用。

应用还要配置自己的公共地址、URL base、base path 或同类设置，使它生成 /files/login.aspx、/files/css/site.css 等地址。设置名称与是否接受末尾斜杠由产品决定，不存在一个对所有应用通用的环境变量。

有些应用设置 base path 后也要求上游收到完整前缀。那就应使用保留路径的 handle /files/*，并核对应用入口；不能一面要求完整路径，一面用 handle_path 去掉它。浏览器地址、代理转发路径和应用配置要能对上。

应用不支持子路径时，用独立子域名

如果应用始终生成根路径链接，或登录回调、Cookie 路径不能配合子路径，改用独立子域名通常更合适：

files.example.com {
    reverse_proxy 127.0.0.1:8080
}

该域名需要正确解析到代理入口，HTTPS 也须能正常签发或加载证书。同步检查应用允许的主机名、公共 URL 和身份认证回调地址。更换访问地址可能让现有会话失效，不能只改 Caddy 后就认定迁移完成。

只改一个 Location 响应头无法覆盖 HTML、脚本生成地址和认证回调。不要为这一个应用把全站根路径都重写到 /files/，那会影响其他服务。

修改前保存 Caddyfile 和应用的 URL 配置，按服务的正常方式校验、加载；必要时恢复这两处及原访问入口。验收应覆盖登录、退出、静态资源和一个实际业务页面：它们的请求仍走同一个应用，路径没有丢失或重复前缀，其他站点路由也正常。