一般的なエラー
このセクションでは、Cloudflare Tunnelを使用してリソースを接続する際に遭遇する可能性のある一般的なエラーについて説明します。以下に問題がリストされていない場合は、トラブルシューティングFAQを参照するか、トンネルログを確認するか、Cloudflareサポートに連絡してください。
リモート管理トンネルをインストールする際にこのエラーが表示された場合、このマシン上で他のcloudflaredインスタンスがサービスとして実行されていないことを確認してください。任意のマシン上でサービスとして実行できるcloudflaredのインスタンスは1つだけです。代わりに、既存のトンネルに追加のルートを追加することをお勧めします。あるいは、sudo cloudflared service uninstallを実行してcloudflaredをアンインストールすることもできます。
トンネルの公開ホスト名を保存できない場合は、別のホスト名を選択するか、既存のDNSレコードを削除してください。Cloudflareダッシュボード ↗からドメインのDNSレコードを確認してください。
トンネルを実行中に次のエラーが発生した場合は、config.ymlファイルを再確認し、credentials-fileが正しい場所を指していることを確認してください。/root/をホームディレクトリに変更する必要があるかもしれません。
cloudflared tunnel run2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592dトンネル認証情報ファイル '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' が存在しないか、ファイルではありませんCloudflare Tunnelを使用するには、Cloudflareアカウントのスーパ管理者が最初にcloudflared loginを通じてログインする必要があります。クライアントはブラウザウィンドウを起動し、ユーザーにCloudflareアカウント内のホスト名を選択するよう促します。選択されると、Cloudflareは次の3つのコンポーネントからなる証明書を生成します。
- そのホスト名のオリジン証明書の公開鍵
- そのドメインのオリジン証明書の秘密鍵
- Cloudflare Tunnelに固有のトークン
これら3つのコンポーネントは、ログインフロー中に一度ダウンロードされる単一のPEMファイルにバンドルされます。ホスト証明書はルートドメインおよび1レベル深い任意のサブドメインに対して有効です。Cloudflareはその証明書ファイルを使用して、cloudflaredを認証し、Cloudflare内のドメインのDNSレコードを作成します。
3つ目のコンポーネントであるトークンは、（選択されたドメインの）ゾーンIDと、最初にログインコマンドで認証されたユーザーにスコープされたAPIトークンで構成されています。ユーザーの権限が変更されると（たとえば、そのユーザーがアカウントから削除されたり、別のアカウントの管理者になった場合）、CloudflareはユーザーのAPIキーをロールします。ただし、cloudflaredを通じてダウンロードされた証明書ファイルは古いAPIキーを保持しており、認証の失敗を引き起こす可能性があります。ユーザーは証明書を再生成するために、再度cloudflaredを通じてログインする必要があります。あるいは、管理者が認証用の専用サービスユーザーを作成することもできます。
これは、オリジンがcloudflaredが信頼しない証明書を使用していることを意味します。たとえば、サーバーとCloudflareの間のプロキシでSSL/TLS検査を使用している場合、このエラーが発生することがあります。これを解決するには：
- 証明書をシステム証明書プールに追加します。
--origin-ca-poolフラグを使用して、証明書のパスを指定します。--no-tls-verifyフラグを使用して、cloudflaredが証明書の信頼チェーンを確認しないようにします。
エラー1033は、トンネルがCloudflareのエッジに接続されていないことを示しています。まず、cloudflared tunnel listを実行して、トンネルがアクティブとしてリストされているか確認してください。リストされていない場合は、次のことを確認してください：
- トンネルへのトラフィックを正しくルーティングしていることを確認します（トンネルガイドのステップ5）で、トラフィックをトンネルにポイントするCNAMEレコードを割り当てます。あるいは、このガイドを確認して、ロードバランサーを使用してトンネルにトラフィックをルーティングします。
- トンネルを実行していることを確認します（トンネルガイドのステップ6）。
詳細については、Cloudflare 1xxxエラーの包括的なリストを参照してください。
このエラーは、cloudflaredがオリジンによって提示されたSSL/TLS証明書を認識しない場合に発生します。この問題を解決するには、オリジンサーバー名パラメータをオリジン証明書のホスト名に設定します。以下は、ローカル管理トンネルの構成の例です：
ingress: - hostname: test.example.com service: https://localhost:443 originRequest: originServerName: test.example.comこれは、cloudflared accessクライアントがcloudflared tunnelオリジンに到達できないことを意味します。これを診断するには、cloudflared tunnelのログを確認する必要があります。根本的な原因として非常に多いのは、cloudflared tunnelがオリジンにプロキシできないことです（たとえば、イングレスが誤って構成されている、オリジンがダウンしている、またはオリジンのHTTPS証明書がcloudflared tunnelによって検証できない場合など）。cloudflared tunnelにログがない場合、CloudflareエッジがWebSocketトラフィックをルーティングできないことを意味します。
websocket: bad handshakeエラーの背後には、いくつかの異なる根本的な原因があります：
-
cloudflared tunnelが実行されていないか、Cloudflareエッジに接続されていません。 -
WebSocketが有効になっていません。有効にするには、
dash.cloudflare.com> Networkに移動します。 -
CloudflareアカウントにユニバーサルSSLが有効になっていますが、SSL/TLS暗号化モードが**オフ（安全でない）**に設定されています。解決するには：
- ゾーンのCloudflareダッシュボードで、SSL/TLS > 概要に移動します。
- SSL/TLS暗号化モードがフレキシブル、フル、または**フル（厳密）**のいずれかに設定されていることを確認します。
-
リクエストがスーパーボットファイトモードによってブロックされています。解決するには、ボットファイトモードの設定で確実に自動化されたを_許可_に設定してください。
-
SSHまたはRDPアクセスアプリケーションにバインディングクッキーが有効になっています。クッキーを無効にするには、アクセス > アプリケーションに移動し、アプリケーション設定を編集します。
Cloudflare Zero Trustプラットフォームを介して開始された長期間の接続（SSHセッションなど）は、最大8時間持続することができます。ただし、サービスパスに沿った中断により、より頻繁に切断される可能性があります。これらの切断の多くは、データセンター、サーバー、またはサービスの更新と再起動などの定期的なメンテナンスイベントによって引き起こされます。これらのイベントが環境内の切断の原因でないと考えられる場合は、関連するWARPログとトンネルログを収集し、サポートに連絡してください。
cloudflaredがerror="remote error: tls: handshake failure"というエラーを返す場合、問題のホスト名がSSL証明書でカバーされていることを確認してください。マルチレベルのサブドメインを使用している場合、ユニバーサルSSLでは1レベル以上のサブドメインをカバーしないため、高度な証明書が必要になる場合があります。これはブラウザでERR_SSL_VERSION_OR_CIPHER_MISMATCHとして表示されることがあります。
Cloudflare Tunnelログがsocket: too many open filesエラーを返す場合、cloudflaredがマシン上のオープンファイル制限を使い果たしたことを意味します。オープンファイルの最大数、またはファイルディスクリプタは、プロセスが開くことを許可されているファイルの数を決定するオペレーティングシステムの設定です。オープンファイル制限を増やすには、cloudflaredを実行しているマシンでulimit設定を構成する必要があります。
このバッファサイズの増加は、cloudflared ↗によって利用されるquic-goライブラリ ↗によって報告されます。このログメッセージの詳細については、quic-goリポジトリ ↗を参照してください。このログメッセージは一般的に影響がなく、トラブルシューティング時に無視しても安全です。ただし、ユニークで高帯域幅の環境内にcloudflaredをデプロイしている場合、テスト目的でバッファサイズを手動でオーバーライドすることができます。
Linuxで最大受信バッファサイズを設定するには：
/etc/sysctl.d/の下に新しいファイルを作成します：
sudo vi 98-core-rmem-max.conf- ファイル内で希望するバッファサイズを定義します：
net.core.rmem_max=2500000-
cloudflaredを実行しているホストマシンを再起動します。 -
これらの変更が適用されたことを確認するには、
grepコマンドを使用します：
sudo sysctl -a | grep net.core.rmem_maxnet.core.rmem_max = 2500000