よくあるエラー

このセクションでは、Cloudflare Tunnel でリソースに接続するときに最もよく発生するエラーを扱います。次に該当しない場合は、Cloudflare One のトラブルシューティング、トンネルログ の確認、または Cloudflare サポートへの問い合わせ を参照してください。

トンネルの接続ステータスは、Cloudflare ダッシュボード（Networking > Tunnels）で確認するか、cloudflared tunnel list コマンドを実行して確認できます。各トンネルは、現在の接続状態を示すステータスを表示します。

リモート管理トンネルのインストール時にこのエラーが出る場合は、このマシンでサービスとして動いているほかの cloudflared インスタンスがないことを確認してください。1 台のマシンでサービスとして動かせる cloudflared は 1 インスタンスだけです。既存のトンネルにルートを追加してください。または、sudo cloudflared service uninstall を実行して cloudflared をアンインストールできます。

トンネルの公開ホスト名を保存できない場合は、別のホスト名を選ぶか、既存の DNS レコードを削除します。Cloudflare ダッシュボード ↗ で、ドメインの DNS レコードを確認 してください。

トンネル実行時に次のエラーが出る場合は、config.yml を確認し、credentials-file が正しい場所を指していることを確かめてください。/root/ をホームディレクトリに変える必要がある場合があります。

cloudflared tunnel run

2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d
Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file

Cloudflare Tunnel を使い始めるには、まず Cloudflare アカウントのスーパー管理者が cloudflared login でログインする必要があります。クライアントはブラウザーを開き、Cloudflare アカウント内のホスト名の選択を求めます。選択すると、Cloudflare は次の 3 つの要素からなる証明書を生成します。

• そのホスト名向けオリジン証明書の公開鍵
• そのドメイン向けオリジン証明書の秘密鍵
• Cloudflare Tunnel 固有のトークン

これら 3 つの要素は 1 つの PEM ファイルにまとめられ、このログインフロー中に 1 回だけダウンロードされます。ホスト証明書はルートドメインと、その 1 階層下のサブドメインに対して有効です。Cloudflare はこの証明書ファイルを使い、cloudflared を認証してドメインの DNS レコードを Cloudflare 上に作成します。

3 つ目の要素であるトークンは、ゾーン ID（選択したドメイン）と、最初に login コマンドで認証したユーザーにスコープされた API トークンで構成されます。ユーザー権限が変わると（そのユーザーがアカウントから削除された、別アカウントの管理者になったなど）、Cloudflare はそのユーザーの API キーをローテーションします。ただし、cloudflared 経由でダウンロードした証明書ファイルは古い API キーを保持したままなので、認証失敗の原因になります。ユーザーは cloudflared でもう一度ログインし、証明書を再生成する必要があります。または、管理者が認証専用のサービスユーザーを作成できます。

オリジンが、cloudflared の信頼しない証明書を使っていることを意味します。たとえば、サーバーと Cloudflare のあいだのプロキシで SSL/TLS 検査を使っていると、このエラーが出ることがあります。解消するには次のいずれかを行います。

• CA 証明書をシステムの信頼ストアに追加し、cloudflared を再起動します。
• caPool に、CA 証明書を含むローカルの PEM ファイルを指定します。
• 一時的な最終手段として、noTLSVerify を true にします。証明書の信頼チェーンを直したらオフにしてください。

--origin-ca-pool と --no-tls-verify のコマンドラインフラグは、--url でオリジンを 1 つだけ定義する場合にだけ適用されます。イングレスルールでは、これらの設定を originRequest の下に記述します。

1033 エラーは、トンネルが Cloudflare のネットワークに接続されていないことを示します。Cloudflare のネットワークが、トラフィックを受け取る健全な cloudflared インスタンスを見つけられないためです。

まず、Cloudflare ダッシュボード ↗ の Networking > Tunnels でトンネルが Active と表示されているか確認するか、cloudflared tunnel list を実行します。トンネルが Active でない場合は、次の内容を確認し、トンネルの状態に応じた対応を行ってください。

詳細は Cloudflare 1xxx エラーの一覧 を参照してください。

トンネルルートで Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared を伴う 502 Bad Gateway エラーが出る場合、トンネル自体は Cloudflare ネットワークへ接続できていますが、cloudflared がイングレスルールで定義したオリジンサービスに到達できません。エラー 1033 はトンネルが Cloudflare に接続されていないことを示しますが、502 エラーは cloudflared とローカルサービスのあいだの問題を示します。

原因を特定するには、トンネルログ の error レベルのメッセージを確認します。よくある原因は次のとおりです。

オリジンサービスが停止している、または一度も起動していない場合、cloudflared のログには次のようなエラーが出ます。

error="dial tcp [::1]:8080: connect: connection refused"

解消するには、サービスが想定どおりのポートで待ち受けていることを確認します。

curl -v http://localhost:8080

サービスが動いていない場合は、起動または再起動します。待ち受け中かどうかは、ss -tlnp | grep <PORT>（Linux）または lsof -iTCP -sTCP:LISTEN -nP | grep <PORT>（macOS）で確認できます。

オリジンが HTTPS を期待しているのにトンネルルートが http:// を指定している場合（またはその逆）は、cloudflared のログに次のようなエラーが出ます。

error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\""

解消するには、トンネルルートのサービス URL を、オリジンが期待する プロトコル に合わせて更新します。たとえば、http://localhost:8080 を https://localhost:8080 に変更します。ローカル管理トンネルを使っている場合は、設定ファイル のイングレスルールを更新します。

トンネルルートのポートが、サービスの待ち受けポートと一致しない場合、cloudflared はそのポートに対する connection refused エラーを記録します。イングレスルールのサービス URL を確認し、アプリケーションがバインドしているポートと照合してください。

オリジンが提示する TLS 証明書を cloudflared が検証できない場合、ログには次のようなエラーが出ます。

error="x509: certificate is valid for example.com, not localhost"

このエラーは、証明書がサービスホスト名をカバーしていないことを示します。一方、x509: certificate signed by unknown authority は、cloudflared がその認証局を信頼していないことを示します。

解消するには、次のいずれかの方法を使います。

• トンネルルートで、originServerName にオリジン証明書上のホスト名を設定します。ローカル管理トンネルを使っている場合の 設定ファイル の例は次のとおりです。

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        originServerName: app.example.com

• caPool で CA 証明書を指定します。

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        caPool: /path/to/ca-cert.pem

• 一時的な最終手段として、noTLSVerify で TLS 検証を無効にします。証明書の問題を直したらオフにしてください。

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        noTLSVerify: true

オリジンが HTTP リクエストを HTTPS へリダイレクトしているのに、公開アプリケーションルートの Service URL が http:// のときに、このエラーが出ることがあります。各リクエストは HTTP でオリジンに到達し、同じリダイレクトを受け取ります。

正しいサービス URL とオリジン設定の選び方は、HTTPS オリジンのトラブルシューティング を参照してください。リダイレクトチェーンが HTTP と HTTPS を行き来する場合は、ERR_TOO_MANY_REDIRECTS も参照してください。

cloudflared access クライアントが、cloudflared tunnel のオリジンに到達できないことを意味します。切り分けには cloudflared tunnel のログを確認します。よくある根本原因は、cloudflared tunnel がオリジンへプロキシできないことです（イングレスの設定ミス、オリジン停止、オリジンの HTTPS 証明書を cloudflared tunnel が検証できないなど）。cloudflared tunnel にログが出ない場合は、Cloudflare のネットワークがその WebSocket トラフィックをルーティングできていません。

このエラーの考えられる根本原因は次のとおりです。

• cloudflared tunnel が動いていない、または Cloudflare のネットワークに接続されていません。
• WebSockets が 有効 になっていません。
• Cloudflare アカウントで Universal SSL が有効なのに、SSL/TLS 暗号化モードが Off (not secure) です。解消するには、Cloudflare ダッシュボードの SSL/TLS > Overview を開き、SSL/TLS 暗号化モードを Flexible、Full、または Full (strict) に設定します。
• Super Bot Fight Mode がリクエストをブロックしています。解消するには、ボット対策の設定で Definitely automated を Allow にしてください。
• SSH または RDP の Access アプリケーションで Binding Cookie が有効です。Cookie を無効にするには、Access controls > Applications を開き、アプリケーション設定を編集します。
• 1 つ以上の Workers ルート がトンネルのホスト名と重なっており、Workers がトラフィックを正しく扱えていません。解消するには、トンネルのホスト名を含むルートを定義しないことでトンネルを Worker ルートから外すか、Worker を特定パスだけ処理し、それ以外のリクエストはオリジンへ転送するよう更新します（例: return fetch(req) を使う）。

cloudflared が error="remote error: tls: handshake failure" を返す場合は、対象ホスト名が SSL 証明書でカバーされていることを確認してください。多階層のサブドメインを使う場合は、Universal SSL が 1 階層を超えるサブドメインをカバーしないため、Advanced Certificate が必要になることがあります。ブラウザーでは ERR_SSL_VERSION_OR_CIPHER_MISMATCH として表示される場合があります。

Cloudflare Tunnel のログ に socket: too many open files エラーが出る場合、cloudflared がマシンのオープンファイル数上限に達しています。オープンファイル（ファイルディスクリプター）の上限は、プロセスが開けるファイル数を決める OS の設定です。上限を上げるには、cloudflared を動かしているマシンで ulimit を設定 します。

このバッファーサイズの増加は、cloudflared ↗ が使う quic-go ライブラリ ↗ が報告します。ログメッセージの詳細は quic-go リポジトリ ↗ を参照してください。このログは通常は影響がなく、トラブルシューティング時に無視して問題ありません。ただし、帯域幅の高い特殊な環境に cloudflared をデプロイしている場合は、テスト目的でバッファーサイズを手動で上書きできます。

Linux で受信バッファーサイズの上限を設定する手順は次のとおりです。

1. /etc/sysctl.d/ の下に新しいファイルを作成します。

   sudo vi 98-core-rmem-max.conf

2. ファイル内で、希望するバッファーサイズを定義します。

   net.core.rmem_max=2500000

3. cloudflared を動かしているホストマシンを再起動します。

4. 変更が反映されたことを確認するには、grep コマンドを使います。

   sudo sysctl -a | grep net.core.rmem_max

   net.core.rmem_max = 2500000

Cloudflare Tunnel 経由のプロキシトラフィックは、オリジンサーバーが Content-Type: text/event-stream レスポンスヘッダーを付けない限り、デフォルトでバッファーされます。このヘッダーがあると、cloudflared は応答全体をバッファーせず、到着したデータをその場でストリーミングします。

Cloudflare One 経由で開始した SSH セッションなどの長時間接続は、最大 8 時間続きます。ただし、サービスパス上の障害により、より頻繁に切断されることがあります。多くの場合、これらの切断は、データセンター、サーバー、サービスの更新や再起動など、定期メンテナンスが原因です。ご利用環境の切断がこれらのイベントによるものではないと考える場合は、関連する クライアントログ と トンネルログ を収集し、サポートに連絡してください。

切断が主にアイドル状態の SSH セッション、WebSocket 接続、その他の長時間接続に影響する場合は、トランスポートプロトコルが関係していることがあります。

cloudflared が QUIC を使う場合、アイドルセッションは、UDP トラフィックを積極的にタイムアウトするネットワーク機器の影響を受けやすくなります。アイドル接続が繰り返し切れる場合は、次の 1 つ以上を試してください。

• SSH の ServerAliveInterval など、アプリケーション層のキープアライブを設定します。
• cloudflared を protocol: http2 に設定してテストします。
• ローカルファイアウォール、NAT 機器、上流のネットワーク機器で、短い UDP アイドルタイマーがないか確認します。

ブロックされた QUIC トラフィックによる接続セットアップ失敗については、上記の QUIC トラブルシューティングセクションを参照してください。

Cloudflare Tunnel 配下の IP アドレスに ping するには、システムが cloudflared 経由の ICMP トラフィックを許可する必要があります。設定手順は ICMP プロキシのドキュメント を参照してください。

このエラーは、Cloudflare One Client の CGNAT IP 範囲 に含まれる CIDR ルートを追加しようとしたときに発生します。100.96.0.0/12 範囲（100.96.0.1 から 100.111.255.254）は内部の WARP ルーティング用に予約されており、Cloudflare Tunnel のルートとしては追加できません。プライベートネットワークに接続するには、100.96.0.0/12 と重ならないように IP / CIDR を変更してください。

タイトルが This site can't provide a secure connection で、サブタイトルが <hostname> uses an unsupported protocol のエラーが出る場合は、Advanced Certificate を注文してください。

複数階層のサブドメイン（サブドメインが 2 階層以上）を追加した場合は、そのホスト名向けに Advanced Certificate を注文してください。Cloudflare の Universal Certificate は、デフォルトではその公開ホスト名をカバーしません。

トンネルエラーの詳細は、トンネルログ を確認するか、Cloudflare サポートに問い合わせてください。