这其实不是一场对决。Cloudflare Tunnel（cloudflared）和 PortPreview 住在不同的房间。Cloudflare Tunnel 用于把服务永久在线地保持在 Cloudflare 边缘之后——Zero Trust、命名隧道、自定义域名。PortPreview 用于你开发会话的接下来二十分钟——webhook 测试、移动 QA、和设计师分享一个分支。在两者之间选择，主要取决于你实际有哪个问题。
Cloudflare Tunnel 擅长什么
cloudflared 是为一件事构建的：把服务放到互联网上，无需打开任何入站端口，也不暴露你的源 IP。在服务器上运行它，把一个命名隧道挂到你 Cloudflare 域名上的某个主机名，流量就通过你机器发起的出站连接经 Cloudflare 边缘流向你的源。
它做得好的事：
- 生产路由。命名隧道功能持久。你可以把 cloudflared 作为服务运行，主机名在重启间持续工作。
- Zero Trust 访问策略。用 SSO、MFA 或 IP 允许列表为内部工具暴露把隧道门控起来。
- 自定义域名。把你自己的域名带到 Cloudflare。隧道终结在
your-domain.com，而非供应商子域名。 - WARP 路由。无需 VPN 设置，从 Cloudflare 网络上任何设备访问私有服务。
这些都不是关于 webhook 调试的。
Cloudflare Tunnel 在开发中何处变得别扭
quick tunnel 模式（cloudflared tunnel --url localhost:3000）是 cloudflared 最接近开发工具的形态，而且能用。你得到一个指向你本地端口的 *.trycloudflare.com URL。但是：
- 像大多数开发隧道一样，URL 每次会话轮换。
- 没有内置请求检查器。你只看到开发服务器日志的内容，仅此而已。要捕获 webhook 载荷以便稍后重放，需要外接一个单独的代理或日志器。
- 命名隧道（稳定 URL 版本）的设置涉及 Cloudflare 账户、DNS 记录和一个配置文件。对长寿命服务值得；对 webhook 迭代会话则杀鸡用牛刀。
PortPreview 适合的位置
PortPreview 是面向开发循环的 localhost 隧道 CLI。一条命令，公开 HTTPS URL，内置请求捕获和重放。
npx portpreview 3000我们优化的是“我改了我的 Stripe webhook 处理器”和“我知道它是否有效”之间的时刻。那个时刻应该是几秒钟。捕获载荷，修处理器，重放到变绿，全程无需重新触发上游事件。
并排
| 需求 | Cloudflare Tunnel | PortPreview |
|---|---|---|
| webhook 调试的快速会话 | 可能（quick tunnel） | 为此而生 |
| 请求捕获和重放 | 否 | 是 |
| 稳定的命名主机名 | 是（需设置） | 非默认重点 |
| 自定义域名 | 是 | 隧道子域名 |
| Zero Trust 访问策略 | 是 | 否 |
| 设置复杂度 | quick 低，named 中 | 一条命令 |
| 作为服务永久运行 | 是 | 为会话设计 |
| 开源客户端 | 是（cloudflared） | 是 |
何时用哪个
在以下情况用 Cloudflare Tunnel
- 你需要服务 24/7 在线而不打开防火墙端口。
- 你想要对内部仪表盘或管理工具的 SSO 门控访问。
- 你需要一个由真实 CA 证书和你现有 Cloudflare DNS 支撑的稳定自定义域名 URL。
- 你已经在 Cloudflare 上，边际设置成本很小。
在以下情况用 PortPreview
- 你在迭代一个 webhook 处理器并想要一键重放。
- 你想和设计师分享一个分支十分钟。
- 你在测试 OAuth 回调或移动流程而不想设置 DNS。
- 你宁愿不为了测一个 Stripe 事件而管理一个 Cloudflare 账户。
它们能很好地共处
我们交流过的几个团队两个都用。Cloudflare Tunnel 用于需要固定 URL 和 SSO 的常驻内部工具。PortPreview 用于需要重放和单条命令的日常 webhook 调试。它们不冲突——只是服务于 dev 到 prod 弧线的不同部分。
如果你还在权衡 ngrok 或 localtunnel，那些对比可能更直接相关。开发循环一侧请 加入 PortPreview 等候名单。