frp、Cloudflare Tunnel、Nginx 怎么配合：原理、架构与使用场景¶

写在前面¶

很多人学会单个工具之后，真正到实战反而更困惑：

• frp 能发布内网服务，那还要不要 Nginx？
• Cloudflare Tunnel 和 frp 是不是同一类东西？
• 已经有 Nginx 了，为什么服务还是到不了内网机器？
• 家庭实验室、测试环境、个人博客，对外访问到底应该怎么组合？

这类问题的根源通常不是不会配工具，而是没有把三者放进同一张图里理解。

这篇文章不再单独讲某个工具，而是专门回答：

1. frp、Cloudflare Tunnel、Nginx 各自解决什么问题
2. 三者之间是什么关系
3. 什么场景该单独用，什么场景该组合用
4. 实际架构怎么落

先记住一句话¶

如果你只想先记结论，可以先记这个：

frp 和 Cloudflare Tunnel 解决“内网服务怎么到公网”，Nginx 解决“公网入口进来以后转给谁”。

换句话说：

• frp / Cloudflare Tunnel 更像“打通路径”
• Nginx 更像“统一入口和流量分发”

这也是为什么它们常常不是替代关系，而是配合关系。

一、三者各自到底干什么¶

1. frp¶

frp 的本质是：

让没有公网 IP 的内网服务，通过一台公网服务器被外部访问。

它常用于：

• 家庭实验室服务发布
• 公司内网测试环境临时暴露
• SSH / RDP / MySQL / Web 服务穿透

它的核心逻辑是：

• 内网客户端主动连接公网 frps
• 公网流量进入 frps
• frps 通过已建立的通道把流量送回内网

2. Cloudflare Tunnel¶

Cloudflare Tunnel 的本质也是：

让内网服务通过一条主动建立的隧道被外部访问。

但它和 frp 的差别在于：

• frp 一般需要你自己有一台公网服务器
• Cloudflare Tunnel 用的是 Cloudflare 的边缘网络和控制平面

从使用体验上看，它更像：

你把服务“挂到 Cloudflare 网络上”，而不是自己维护一台中转公网机。

常见适用场景：

• 个人博客
• 临时管理页面
• 内网 Web 服务外发
• 不想自建公网跳板机的人

3. Nginx¶

Nginx 的本质是反向代理。

它解决的问题是：

当请求已经到达入口节点之后，应该怎么根据域名、路径、协议把它转发到后端服务。

它常用于：

• 多站点统一入口
• HTTPS 证书管理
• 负载均衡
• API 与静态资源分流
• 限流、鉴权、Header 处理

它不负责：

• NAT 穿透
• 内网打洞
• 公网到内网的可达性建立

二、三者最核心的区别¶

frp / Cloudflare Tunnel 关注“到得了”¶

它们优先解决的是：

外部请求到底能不能走到原本不可达的内网服务。

举例¶

你家里一台机器跑了博客：

• 服务地址：192.168.1.10:8080
• 没公网 IP
• 家用路由器后面一层 NAT

这时候如果没有穿透能力，公网请求根本到不了这台机器。

这时需要先解决“能到达”的问题，frp 或 Cloudflare Tunnel 才派上用场。

Nginx 关注“到了以后怎么分”¶

如果请求已经能到达某个公网入口节点，Nginx 才有施展空间。

举例¶

一个公网入口要同时接：

• blog.example.com
• api.example.com
• admin.example.com

这时候 Nginx 可以根据 Host 分发：

blog.example.com  -> 博客服务
api.example.com   -> API 服务
admin.example.com -> 管理后台

但前提是这些后端对 Nginx 来说是可达的。

三、它们之间为什么经常一起出现¶

因为实战里你往往既要：

• 先让服务能被外部访问
• 再把多个服务统一管理

所以很常见的结构是：

flowchart LR
    U[公网用户] --> E[公网入口]
    E --> N[Nginx]
    N --> T[frp / Cloudflare Tunnel]
    T --> I[内网服务]

不过更常见的真实方案通常是以下两种。

四、典型组合方案¶

方案一：frp + Nginx¶

这是最经典的“自己掌控公网入口”的方案。

结构¶

flowchart LR
    U[公网用户] --> G[公网云服务器]
    G --> N[Nginx]
    H[内网机器 frpc] --> S[frps]
    S --> H2[内网服务]
    N --> S

更直白一点的理解¶

• 你有一台公网云服务器
• 这台机器上跑 frps
• 同时也跑 Nginx
• 家里的服务通过 frpc 连上来
• 外部请求先进 Nginx
• 再由 Nginx 转发到对应的 frp 暴露端口

适合什么场景¶

• 你自己有云服务器
• 你想完全掌控入口
• 你要对接很多内网服务
• 你想统一证书和域名管理

优点¶

• 自主可控
• 灵活
• 协议支持广
• 不只支持 Web，还能发 TCP 服务

缺点¶

• 你要维护 frps
• 你要维护云服务器安全
• 入口、证书、日志、限流都要自己管

方案二：Cloudflare Tunnel + Nginx¶

这是“更偏托管、对 Web 友好”的组合。

结构¶

flowchart LR
    U[公网用户] --> C[Cloudflare 边缘网络]
    I[内网机器 cloudflared] --> C
    C --> N[本地 Nginx]
    N --> A[博客]
    N --> B[API]
    N --> D[管理页面]

它的工作方式¶

• 你在内网机器上运行 cloudflared
• cloudflared 主动连接 Cloudflare
• 公网用户访问你的域名时，请求先到 Cloudflare
• 再通过 Tunnel 回到你的本地 Nginx
• 最后由 Nginx 决定请求转给哪个内网服务

适合什么场景¶

• 主要是 Web/HTTP/HTTPS 服务
• 不想自己维护公网跳板机
• 想快速发布博客、面板、后台
• 已经在用 Cloudflare DNS/CDN

优点¶

• 不用自建公网入口机
• HTTPS、域名接入体验较好
• Web 场景上手很快
• 边缘网络能力比较完整

缺点¶

• 更依赖平台
• 某些非 HTTP 协议支持和使用方式不如 frp 直接
• 自主性不如全自建方案

方案三：只用 frp，不加 Nginx¶

这适合非常简单的场景：

• 暴露一个 SSH
• 暴露一个 MySQL
• 暴露一个临时测试站

比如：

cloud.example.com:6000 -> SSH
cloud.example.com:6306 -> MySQL
cloud.example.com:8080 -> 测试站

适合什么场景¶

• 纯临时访问
• 服务少
• 不讲究统一入口
• 运维自己用

不足¶

• 端口多了之后难管理
• 不适合多个 Web 域名优雅发布
• HTTPS、日志、Header、限流治理不方便

方案四：只用 Cloudflare Tunnel，不加 Nginx¶

如果你只发一个简单 Web 服务，完全可以不加 Nginx。

例如：

• 一个博客
• 一个管理面板
• 一个内网站点

这时 cloudflared 直接把请求转给本地应用就够了。

不足¶

当你开始需要：

• 多个域名
• 多路径转发
• API 和静态资源拆分
• 本地多个服务统一入口

Nginx 就会重新变得有价值。

五、应该怎么选¶

场景一：家庭实验室博客 / 个人站点¶

推荐优先级：

1. Cloudflare Tunnel + Nginx
2. frp + Nginx
3. Cloudflare Tunnel 单独用

原因¶

• Web 场景最适合 Tunnel + 反向代理
• Nginx 可以统一域名、证书、路径
• Cloudflare Tunnel 能减少自建公网机维护压力

如果你很在意完全自主可控，可以选 frp + Nginx。

场景二：临时给研发开放测试服务¶

推荐优先级：

1. frp
2. frp + Nginx

原因¶

• 临时场景，frp 非常直接
• 如果只是开放一个服务，根本没必要上复杂入口

场景三：多服务统一外发¶

推荐优先级：

1. frp + Nginx
2. Cloudflare Tunnel + Nginx

原因¶

你既要：

• 穿透内网
• 又要统一流量管理

单独用 frp 或单独用 Tunnel 都不够优雅。

场景四：发布非 HTTP 协议服务¶

例如：

• SSH
• MySQL
• Redis
• RDP

推荐优先级：

1. frp
2. VPN

这里不推荐优先靠 Nginx，因为：

• Nginx 最擅长的是 Web 入口
• 非 HTTP 端口穿透，frp 更直接

如果这些是高敏感管理入口，很多时候应优先考虑 VPN，而不是直接外发。

六、一个简单决策模型¶

你可以按下面这个顺序做判断。

第一步：你的服务是 Web 还是非 Web¶

• 如果主要是 Web：优先考虑 Cloudflare Tunnel 或 Nginx
• 如果主要是 TCP 服务：优先考虑 frp

第二步：你有没有公网云服务器¶

• 有：frp + Nginx 很灵活
• 没有：Cloudflare Tunnel 更省事

第三步：你要不要统一入口治理¶

• 要：加 Nginx
• 不要：单独用 frp 或 Tunnel 就够

第四步：这是临时开放还是长期架构¶

• 临时：简单优先
• 长期：统一入口、日志、安全、证书都要考虑

七、常见误区¶

误区一：有了 Nginx 就不需要 frp 或 Tunnel¶

不对。

如果后端本来就不可达，Nginx 根本帮不了你。
Nginx 不是内网穿透工具。

误区二：Cloudflare Tunnel 可以完全替代 frp¶

不完全对。

在很多 Web 场景里，它确实可以替代 frp。
但如果你大量依赖：

• 任意 TCP 端口
• 完全自建
• 对平台依赖更低

frp 仍然更合适。

误区三：frp 发布服务就一定安全¶

不对。

frp 只是把路径打通，安全还得看：

• 暴露的协议是什么
• 是否有认证
• 是否有 TLS
• 是否有限流和审计
• 是否应该改走 VPN

尤其是：

• 数据库
• SSH
• Kubernetes API

这类服务不能因为“能通了”就直接裸暴露公网。

八、最后的速查表¶

九、总结¶

最后把核心结论压成三句话：

• frp 更适合“自己有公网入口、要穿透各种服务”
• Cloudflare Tunnel 更适合“主要发 Web 服务、想少维护公网机”
• Nginx 更适合“请求已经到了入口之后的统一转发和治理”

所以真正实战里常见的不是三选一，而是：

• frp + Nginx
• Cloudflare Tunnel + Nginx

你在做方案时，最重要的不是先选工具，而是先回答三个问题：

1. 我的问题是“服务到不了公网”，还是“入口太乱”？
2. 我要发的是 Web 服务，还是数据库/SSH 这类 TCP 服务？
3. 我想完全自建，还是接受平台托管？

只要这三个问题答清楚，方案通常就不会偏太多。