クライアントレスアクセス向けに Cloudflare Tunnel を導入するときは、次のベストプラクティスに従うことを推奨します。
可用性のポイントを追加するため、ネットワーク内の別ホストマシンに cloudflared レプリカ を追加します。
アプリケーションの管理を簡単にするため、アプリケーションを公開する公開ホスト名を標準化します。お客様が公開ホスト名を管理する方法の例は次のとおりです。
- 社内アプリケーション用に、プライマリの公開ウェブサイトのサブドメインを委任する（例:
tools.dev.customer.com）。 - 内部 DNS インフラが公開利用できる場合は、内部のプライマリ DNS レコードを Cloudflare に登録し、このドメインを公開ホスト名のルートに使います。これにより、プライベートと公開で同一のホスト名でアプリケーションを提示できます。
- 接続するツールの種類に基づいてホスト名を生成する、内部の規則を定めます。たとえば、本番リソース専用に割り当てた US-East データセンターのアプリケーション群がある場合、
tools.us-east.prod.ztproject.comのサブドメインを作成できます。
公開ホスト名ルートが HTTPS アプリケーションを提供する場合は、TLS 証明書の検証を有効のままにします。サービス URL が localhost または IP アドレスでも、証明書がホスト名をカバーしている場合は、Origin Server Name を、証明書がカバーするホスト名に設定します。オリジンがプライベート認証局を使う場合は、CA Pool を設定します。
Disable TLS certificate verification は、証明書設定を直すあいだの一時的なテストにだけオンにします。HTTPS オリジンの判断フロー全体は、Cloudflare Tunnel の HTTPS オリジンのトラブルシューティング を参照してください。
対象アプリケーションがロードバランサーなどの背後にある場合は、HTTP Host Header をサービスホスト名に設定する必要があることがあります。オリジンサービスと cloudflared のあいだにあるロードバランサーはトラブルシュートが難しいことが多く、ロードバランサーが通常トラフィックを識別する方法に合わせたリクエストヘッダーを追加すると解決できることがよくあります。
トンネルの健全性を監視するため、Cloudflare ダッシュボードで 通知を有効 にします。
最新の機能とバグ修正を入手するため、cloudflared を定期的に更新 します。