これは本当の対決ではありません。Cloudflare Tunnel（cloudflared）と PortPreview は別の部屋に住んでいます。Cloudflare Tunnel はサービスを Cloudflare のエッジの背後で永続的にオンラインに保つためのもの——Zero Trust、ネームドトンネル、カスタムドメイン。PortPreview は開発セッションの次の 20 分のためのもの——Webhook テスト、モバイル QA、ブランチをデザイナーと共有。両者の選択は、実際にどの問題を抱えているかでほぼ決まります。
Cloudflare Tunnel が得意なこと
cloudflared は 1 つのことのために作られました：受信ポートを 1 つも開かず、origin IP も露出させずにサービスをインターネットに置くこと。サーバーで動かし、ネームドトンネルを Cloudflare ドメインのホスト名に紐づけると、トラフィックはマシンが開始した送信接続を通じて Cloudflare のエッジ経由で origin へ流れます。
うまくやること：
- 本番ルーティング。ネームドトンネル機能は永続的。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 はセッションごとにローテーションします。
- 組み込みのリクエストインスペクターがありません。dev サーバーがログするものしか見えません。後でリプレイするために Webhook ペイロードをキャプチャするには、別のプロキシやロガーを取り付ける必要があります。
- ネームドトンネル（安定 URL 版）のセットアップは Cloudflare アカウント、DNS レコード、設定ファイルを伴います。長命なサービスには価値あり、Webhook 反復セッションには過剰。
PortPreview が収まる場所
PortPreview は開発ループ向けの localhost トンネリング CLI です。1 コマンド、公開 HTTPS URL、リクエストのキャプチャとリプレイ内蔵。
npx portpreview 3000私たちが最適化するのは「Stripe の Webhook ハンドラーを変えた」と「動くかどうかわかった」の間の瞬間です。その瞬間は数秒であるべき。ペイロードをキャプチャし、ハンドラーを直し、グリーンになるまでリプレイ——すべて上流イベントを再トリガーせずに。
並べて
| ニーズ | Cloudflare Tunnel | PortPreview |
|---|---|---|
| Webhook デバッグの素早いセッション | 可能（quick tunnel） | これのために構築 |
| リクエストのキャプチャとリプレイ | いいえ | はい |
| 安定したネームドホスト名 | はい（設定あり） | デフォルトの焦点ではない |
| カスタムドメイン | はい | トンネルサブドメイン |
| Zero Trust アクセスポリシー | はい | いいえ |
| セットアップの複雑さ | quick は低、named は中 | 1 コマンド |
| サービスとして永続稼働 | はい | セッション向け設計 |
| オープンソースクライアント | はい（cloudflared） | はい |
どちらをいつ使うか
Cloudflare Tunnel を使う場面
- ファイアウォールポートを開けずにサービスを 24/7 オンラインにする必要がある。
- 内部ダッシュボードや管理ツールへの SSO ゲート付きアクセスがほしい。
- 本物の CA 証明書と既存の Cloudflare DNS に支えられた安定したカスタムドメイン URL が必要。
- すでに Cloudflare 上にいて、追加のセットアップコストが小さい。
PortPreview を使う場面
- Webhook ハンドラーを反復していてワンクリックリプレイがほしい。
- ブランチをデザイナーと 10 分間共有したい。
- DNS 設定なしで OAuth コールバックやモバイルフローをテストする。
- Stripe イベントをテストするためだけに Cloudflare アカウントを管理したくない。
うまく共存する
話を聞いた複数のチームは両方を使っています。固定 URL と SSO が必要な常時稼働の内部ツールには Cloudflare Tunnel。リプレイと 1 コマンドが必要な日々の Webhook デバッグには PortPreview。衝突しません——dev-to-prod の弧の異なる部分を担うだけです。
ngrok や localtunnel も検討中なら、それらの比較がより直接的に関連するかもしれません。開発ループ側には PortPreview のウェイトリストへ。