caddy配合frp使用

简介

caddy配合frp使用，是一套把 frp 内网穿透与 Caddy 反向代理组合起来的部署方案：frp 负责把内网机器上的端口或服务映射到一台有公网 IP 的服务器上，Caddy 负责在这台服务器上按域名把请求分流到 frp 的转发端口，并处理 TLS 证书与 HTTPS。它解决的是内网服务没有公网地址、多个自建服务端口分散、证书申请与续期繁琐这三类问题。适合有域名、手上有一台公网服务器的个人用户和小团队，例如 NAS、WebDAV、本地 WebSocket 服务需要对外访问的场景。核心优势在于 frp 支持 tcp、udp 协议并为 http 和 https 提供额外能力，而 Caddy 默认自动申请与续期证书，配置文件短，新增一个域名往往只需加几行站点配置。

核心功能

• 内网穿透：frp 是可用于内网穿透的高性能反向代理应用，支持 tcp、udp 协议，并为 http 和 https 应用协议提供额外能力，把内网 frpc 端的服务映射到公网 frps 端。
• 按域名分流：Caddy 在服务器上监听 80/443，按请求的域名把流量转发到不同的后端端口，其中一个后端就是 frp 转发出来的 bind_port，实现单一入口管理多个服务。
• 自动 HTTPS：Caddy 默认自动申请并续期证书，支持 HTTP/1.1、HTTP/2、HTTP/3，域名解析正确时无需手工提交证书申请流程。
• 端口重定向：frp 官方 issue 中提到的做法是把客户端 server_port 设为 443，再由服务器上的 Caddy 把 443 的请求转发到 frp 的 bind_port，从而用子域名区分不同服务。
• 配置集中：Caddy 的配置写在 /etc/caddy 下的配置文件中，frp 的 frps/frpc 各自有配置文件，改动后分别重载与重启即可生效。
• 容器化部署：公网服务器上的 frps 与 Caddy 可以用 docker-compose 一起跑，为 frps 容器映射通信端口，Caddy 容器占用 80/443。
• WebSocket 透传：可用 FRP 加 Caddy 的组合把本地 WebSocket 连接安全暴露到公网，由 Caddy 终结 TLS 后再回源到 frp 转发的端口。

使用场景

• NAS 服务公网访问：内网 NAS 上的管理页面与文件服务，通过 frp 暴露端口，再由 Caddy 按子域名反代，配合 Cloudflare 做 CDN 加速。
• 多服务统一入口：服务器上同时跑多个自建 Web 服务时，让 Caddy 独占 80/443，按域名分流到各后端，避免逐个服务抢端口。
• WebDAV 远程挂载：用 frp 把闲置设备上的服务暴露到公网，用 Caddy 搭 WebDAV，客户端用 rclone 挂载，实现类似坚果云的同步效果。
• 本地 WebSocket 对外提供：开发环境的 WebSocket 服务需要被外网访问时，用 FRP 转发端口、Caddy 提供 HTTPS 入口。
• 已有站点的服务器复用：服务器上已经部署了其他 web 服务并使用了 Caddy 做反向代理时，只需在 Caddyfile 中追加 frp 相关端口的转发规则。

安装与获取步骤

1. 准备一台有公网 IP 的服务器作为 frps 端，并在服务器防火墙放行 frps 的通信端口（示例中为 7000）以及 80、443 端口。
2. 获取 Caddy：官方提供静态二进制、Debian/Ubuntu/Raspbian 软件包、Fedora/RedHat/CentOS 软件包等多种方式，具体以官方页面为准，地址为 https://caddyserver.com/docs/install 。
3. 获取 frp：从项目仓库或镜像仓库下载 frps 与 frpc，按仓库 README 与中文文档分别配置服务端和客户端，仓库地址为 https://gitee.com/zspty/frp?skip_mobile=true 。
4. 编辑服务器上 /etc/caddy 目录下的配置文件，为每个对外域名写一条反代规则，把 upstream 指向 frp 转发出来的 bind_port。
5. 在 frpc 配置中填写服务器地址、通信端口与要暴露的本地服务端口；若采用 issue 中的做法，把 server_port 设为 443，再由 Caddy 从 443 转发到 bind_port。
6. 若选择容器方式，用 docker-compose 同时编排 frps 与 Caddy：frps 映射 7000 端口，Caddy 映射 80/443，随后启动并观察日志确认 frpc 连接成功。
7. 验证：先 curl 本机 bind_port 确认 frp 链路通，再用域名访问 443，确认返回的是目标内网服务的页面与有效证书。

典型配置要点

• Caddyfile 中每个域名一个站点块，reverse_proxy 指向 127.0.0.1 加 frp 的 bind_port，多个域名即可指向不同 bind_port。
• frps 与 Caddy 同机时，frp 的通信端口只做端口映射，不写进 Caddy 的站点配置，避免控制流与站点流量混淆。
• 改完 Caddyfile 后重载 Caddy，改完 frpc 配置后重启 frpc，两者的生效时机不同，排查时分开验证。
• 若服务器还挂了 Cloudflare CDN，回源端口、证书与缓存行为以 Cloudflare 与 Caddy 官方文档为准。

与同类方案的区别

• 与 Nginx、Traefik 相比，三者的主要差别在于如何获取 TLS 证书，以及每增加一个应用需要多少配置工作；Caddy 的特点是默认自动申请与续期证书。
• 与纯 frp 方案相比，加一层 Caddy 后可以按域名分流到多个内网服务，而不是每个服务各占一个公网端口。
• 与只做端口映射的方案相比，Caddy 提供了统一的 80/443 入口和证书管理，但多了一层转发，链路排查要分 frp 与 Caddy 两段进行。
• 与 Ferron、River 等新兴反向代理相比，Caddy 与 frp 的组合已有较多公开实践记录，遇到问题更容易找到同类配置参考。

注意事项

• frps 与 Caddy 部署在同一台服务器时，frp 的通信端口不要交给 Caddy 反代：在 docker-compose 中为 frps 容器映射 7000 端口，防火墙放行，让 frpc 直连该端口。
• 把 frp 客户端 server_port 设为 443 时，必须确认服务器上 443 由 Caddy 独占且转发目标就是 frp 的 bind_port，否则会出现端口占用或请求打到错误服务的情况。
• Caddy 的自动 HTTPS 依赖域名解析指向该服务器；解析未生效或被 CDN 拦截时证书申请会失败，具体行为以官方页面为准。
• frp 支持 tcp 与 udp，而 Caddy 主要处理 http/https 流量；纯 tcp/udp 类转发不要绕经 Caddy，直接用 frp 的端口映射即可。
• 排查故障时先 curl 内网侧与 bind_port 确认 frp 链路，再用域名访问 443 确认 Caddy 链路，两段都通才算整条链路正常。