Tunnel

Cloudflare Tunnel でよくある問題と対処を確認します。

リモート管理トンネルのインストール時にこのエラーが出る場合は、このマシンでサービスとして動いているほかの 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 は応答全体をバッファーせず、到着したデータをその場でストリーミングします。

詳細は、Tunnel のトラブルシューティングガイド全体を参照してください。