トラブルシューティング

このページで、Cloudflare Tunnel のよくある問題を切り分けて解決できます。多くの問題は、最新の cloudflared へアップグレードすると解消します。調査を進める前に cloudflared を更新するを参照してください。

トンネルのヘルス監視、ログ、メトリクスについては、Observability を参照してください。

トンネルが Healthy なのに HTTPS ルートが失敗またはリダイレクトする場合は、HTTPS オリジンのトラブルシューティングを参照してください。

接続エラー

cloudflared が Cloudflare ネットワークに到達できないとき、ログには、問題が DNS 解決、QUIC（UDP）、TCP 接続のどれかを示す具体的なエラーメッセージが出ます。

DNS 解決の失敗

`edge discovery: error looking up Cloudflare edge IPs`

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 172.19.64.1:53: no such host"

このエラーは、マシンに設定された DNS リゾルバーが、cloudflared が Cloudflare Tunnel の宛先 IP を見つけるために使う SRV レコードを解決できないことを意味します。よくある原因は、SRV レコードを除去またはブロックする企業向け DNS リゾルバーと、圧縮された SRV レコードを返す DNS リゾルバーです。

切り分け:

cloudflared のホストマシンで、次を実行します。

dig SRV _v2-origintunneld._tcp.argotunnel.com

SERVFAIL、NXDOMAIN、または空の応答が返った場合は、Cloudflare のパブリックリゾルバーで試します。

dig SRV _v2-origintunneld._tcp.argotunnel.com @1.1.1.1

解決方法:

1.1.1.1 では結果が返るのにローカルリゾルバーでは返らない場合は、ホストの DNS を Cloudflare DNS（1.1.1.1）または別のパブリックリゾルバーにします。
どちらのリゾルバーでも結果が返らない場合は、ファイアウォールが送信 DNS クエリ（UDP ポート 53）をブロックしている可能性が高いです。ネットワーク管理者と連携し、DNS トラフィックを許可してください。

`DNS query failed ... i/o timeout`

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 127.0.0.11:53:
    read udp 127.0.0.1:53467->127.0.0.11:53: i/o timeout"

この場合は、cloudflared からの DNS クエリがブロックまたは破棄され、リゾルバーが応答していません。内部 DNS リゾルバー（127.0.0.11）に到達できない、または設定が誤っているコンテナ環境（Docker、Kubernetes）でよく起きます。

解決方法:

Docker では、コンテナの DNS 設定（/etc/resolv.conf）を確認します。コンテナ実行時に --dns 1.1.1.1 でリゾルバーを上書きできます。
Kubernetes では、kube-dns または CoreDNS サービスが稼働し、ポッドから到達できることを確認します。
cloudflared のホストでは、/etc/resolv.conf に記載されたリゾルバーへ到達でき、クエリに応答していることを確認します。

QUIC ハンドシェイクのタイムアウト

`Failed to dial a quic connection`

ERR Failed to dial a quic connection error="failed to dial to edge with quic:
    timeout: handshake did not complete in time" connIndex=0 ip=198.41.192.227
INF Retrying connection in up to 2s connIndex=0 ip=198.41.192.227

このエラーは、cloudflared が Cloudflare Tunnel の宛先 IP を解決できたものの、UDP ポート 7844 での QUIC ハンドシェイクを完了できなかったことを意味します。ネットワークまたはファイアウォールが、Cloudflare への送信 UDP トラフィックをブロックしています。

cloudflared は指数バックオフ（2、4、8、16、32、最大 64 秒）で再試行します。再試行を使い切ると、TCP 上の HTTP/2 へフォールバックします。

INF Switching to fallback protocol http2 connIndex=0

フォールバックも失敗した場合は、TCP 接続タイムアウトエラーが出ます。

切り分け:

cloudflared のホストマシンで、ポート 7844 の接続をテストします。

nc -uvz -w 3 198.41.192.227 7844

198.41.192.227 は、エラーメッセージに表示された IP に置き換えます。ポートが閉じている、またはファイアウォールでブロックされている場合、コマンドは Connection refused を返すかタイムアウトします。

解決方法:

ファイアウォールまたはセキュリティグループで、ポート 7844 への送信 UDP トラフィックを許可します。IP とポートの一覧を参照してください。
UDP を開けない場合、cloudflared は自動的に TCP 上の HTTP/2 へフォールバックします。--protocol http2 の run パラメーターで HTTP/2 を強制することもできます。ただし、パフォーマンスのため QUIC を推奨します。

TCP 接続タイムアウト

`DialContext error: dial tcp ... i/o timeout`

ERR Unable to establish connection with Cloudflare edge
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0
ERR Serve tunnel error
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0

このエラーは、cloudflared が TCP ポート 7844 で Cloudflare に到達できないことを意味します。上の QUIC ハンドシェイクのタイムアウトも出ている場合は、UDP と TCP の両方がブロックされており、トンネルは接続できません。

切り分け:

簡単なテストとして、次を実行します。

curl -v https://region1.v2.argotunnel.com:7844

接続がハングする場合、ホストと Cloudflare の間でトラフィックが破棄されています。

cloudflared がポート 7844 で接続できるかをテストするには、次を実行します。

nc -vz -w 3 198.41.200.43 7844

198.41.200.43 は、エラーメッセージに表示された IP に置き換えます。ポートが閉じている、またはファイアウォールでブロックされている場合、コマンドは Connection refused を返すかタイムアウトします。

解決方法:

Cloudflare Tunnel の IP レンジ向けに、ポート 7844 への送信 TCP トラフィックを許可します。
環境がポート 7844 を完全にブロックしている（UDP と TCP の両方）場合、トンネルは機能しません。ネットワーク管理者と連携し、このポートの送信トラフィックを許可してください。

`cloudflared service is already installed` と表示されます。

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

`An A, AAAA, or CNAME record with that host already exists` と表示されます。

トンネルの公開ホスト名を保存できない場合は、別のホスト名を選ぶか、既存の 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 でもう一度ログインし、証明書を再生成する必要があります。または、管理者が認証専用のサービスユーザーを作成できます。

`x509: certificate signed by unknown authority` エラーが表示されます。

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

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

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

トンネル実行時にエラー 1033 が表示されます。

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

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

ステータス	意味	推奨される対応
Healthy	トンネルは稼働中で、Cloudflare グローバルネットワークへの 4 本の接続経由でトラフィックを処理しています。	対応は不要です。トンネルは正常に動作しています。
Inactive	トンネルは作成済み（API またはダッシュボード経由）ですが、接続を確立するために `cloudflared` コネクタが一度も実行されていません。	オリジンサーバーに `cloudflared` をインストールして実行し、トンネルを Cloudflare に接続します。インストールコマンドは、Cloudflare ダッシュボードの Networking > Tunnels で対象のトンネルを選び、Overview タブで Add a replica を選ぶと確認できます。API で設定する場合は、トンネルをインストールして実行するを参照してください。
Down	以前は接続されていましたが、`cloudflared` プロセスが停止したため、現在は切断されています。	1. サーバー上で `cloudflared` サービスまたはプロセスが動いていることを確認します。 2. マシンの電源オフ、アプリケーションのクラッシュ、最近のネットワーク変更など、サーバー側の問題がないかを確認します。
Degraded	`cloudflared` コネクタは動いており、トンネルはトラフィックを処理していますが、少なくとも 1 本の接続が失敗しています。トンネルの可用性がさらに低下すると、トンネルがダウンしてトラフィックを処理できなくなるおそれがあります。	1. `cloudflared` のログで接続失敗やエラーメッセージを確認します。 2. ローカルネットワークとファイアウォールのルールを調べ、Cloudflare Tunnel の IP とポートへの接続がブロックされていないことを確認します。

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

トンネル経由で HTTP または HTTPS アプリケーションに接続すると 502 Bad Gateway エラーが表示されます。

トンネルルートで 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）で確認できます。

オリジンサービスの URL のプロトコルが違う

オリジンが 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 に変更します。ローカル管理トンネルを使っている場合は、設定ファイルのイングレスルールを更新します。

オリジンサービスの URL が誤ったポートを指している

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

`cloudflared` がオリジン証明書を検証できない

オリジンが提示する 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
```

公開アプリケーションが `ERR_TOO_MANY_REDIRECTS` を返します。

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

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

`cloudflared access` が `websocket: bad handshake` エラーを表示します。

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) を使う）。

トンネル接続が SSL エラーで失敗します。

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

トンネル接続が `Too many open files` エラーで失敗します。

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

cloudflared のログに `failed to sufficiently increase receive buffer size` と表示されます。

このバッファーサイズの増加は、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_max
```
```
net.core.rmem_max = 2500000
```

Cloudflare Tunnel がストリーミング応答をライブで送らず、バッファーしています。

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

Palo Alto Networks Next-Generation Firewall 経由で Cloudflare Tunnel が接続できない

Cloudflare は最近、Palo Alto Networks Next-Generation Firewall（NGFW）の App-ID データベースバージョン 9128 の変更が、Cloudflare Tunnel および Cloudflare One Client のトラフィック許可要件に影響することを確認しました。

Palo Alto Networks Next-Generation Firewall（NGFW）は、App-ID データベースのバージョンに関係なく、Cloudflare Tunnel（cloudflared）と Cloudflare One Client（Zero Trust 付き WARP）の両方を cloudflare-warp として検出します。現時点では、cloudflared 専用の App-ID はありません。

この問題は、Palo Alto Networks NGFW がトラフィックを cloudflare-warp として識別するため、Cloudflare One Client と WARP クライアントに影響しやすいです。

この節では、QUIC（UDP ポート 7844）で Cloudflare に接続する Cloudflare Tunnel（cloudflared）に焦点を当てます。

App-ID データベースバージョン 9128（2026 年 7 月 27 日リリース）以降、NGFW はこのトラフィックを許可するための要件を変更しました。バージョン 9128 以降では、従来必要だった App-ID とその依存関係に加え、quic-base アプリケーションを明示的に許可する必要があります。

接続を復旧するには、App-ID データベースを戻すか、必要なアプリケーションと UDP ポートを明示的に許可します。

オプション 1: App-ID データベースを戻す

App-ID データベースをバージョン 9127 に戻し、Palo Alto Networks が恒久的な解決策を提供するまで、自動 App-ID 更新を無効にします。

App-ID データベースを戻す場合は、一時的な緩和策として扱い、セキュリティチームと連携してください。Palo Alto Networks が恒久的な解決策を提供したら、自動更新を再有効化します。

オプション 2: 明示的なファイアウォールポリシーを設定する

UDP ポート 7844 のカスタムサービスを作成する

PAN-OS で Objects > Services を開きます。
次の設定でサービスを作成します。

設定値

Name cloudflared_7844_udp

Description 任意

Protocol UDP

Destination Port 7844

Source Port 空欄のまま

Session Timeout Inherit from application
OK を選びます。

設定	値
Name	`cloudflared_7844_udp`
Description	任意
Protocol	UDP
Destination Port	`7844`
Source Port	空欄のまま
Session Timeout	Inherit from application

ファイアウォールルールを作成または更新する

Policies を開きます。
universal または interzone のファイアウォールルールを作成または変更します。
環境の該当トラフィックに合うように Source と Destination を設定します。
- Source: 適切な Source Zone または Source Address を選びます。
- Destination: 適切な Destination Zone または Destination Address を選びます。
Application で、次のアプリケーションをすべて追加します。
- cloudflare-warp
- quic-base
Service/URL Category で、カスタムサービス cloudflared_7844_udp を追加します。
ルールの Action を Allow にします。
組織のセキュリティポリシーに従ってログを有効にします。
ポリシー変更をコミットしたあと、Cloudflare Tunnel がファイアウォール経由で接続を確立・維持できることを確認します。

サポートへの問い合わせ方法

できるだけ早くトラブルシューティングできるよう、サポートチケットには十分な詳細を含めてください。状況を詳しく書くほど、問題の特定と解決が早くなります。

サポートへ問い合わせる際は、チケットにできるだけ関連情報を含めてください。

状況: シナリオやユースケースを簡潔に説明します（ユーザーの場所、何をしようとしていたかなど）。
再現手順: トラブルシューティング中に問題を再現した手順を説明します。
タイムスタンプ: 問題が起きた正確な時刻とタイムゾーンを含めます。
実施したトラブルシューティング: すでに試した手順や変更をまとめます。
Tunnel ID とトンネル名。
cloudflared のバージョン（cloudflared --version を実行します）。
トンネルのセットアップ方法（ローカル管理、またはダッシュボード経由のリモート管理）。
トンネルログ: ローカルマシンのログを含めます。
トンネル診断ログ: トンネル診断ログを含めます。

デバッグログを収集する

トラブルシューティング用に詳細な出力を取得するには、次を実行します。

ローカル管理トンネル: --loglevel debug フラグ付きで cloudflared を実行します。
```
cloudflared tunnel --loglevel debug run
```
ログをファイルへ残す場合は、--logfile フラグを追加します。
```
cloudflared tunnel --loglevel debug --logfile /var/log/cloudflared/cloudflared.log run
```
リモート管理トンネル（ダッシュボードで作成）: トンネルの run パラメーターでログを設定します。リモートログストリーミングで、ログをリアルタイムにストリーミングすることもできます。

サポートへ連絡するときは、デバッグログを添付してください。含める情報の一覧は、上のチェックリストを参照してください。

トラブルシューティング

接続エラー

DNS 解決の失敗

edge discovery: error looking up Cloudflare edge IPs

DNS query failed ... i/o timeout

QUIC ハンドシェイクのタイムアウト

Failed to dial a quic connection

TCP 接続タイムアウト

DialContext error: dial tcp ... i/o timeout

cloudflared service is already installed と表示されます。

An A, AAAA, or CNAME record with that host already exists と表示されます。

トンネルの認証情報ファイルが存在しない、またはファイルではありません。

トンネルの認証に失敗します。

x509: certificate signed by unknown authority エラーが表示されます。

トンネル実行時にエラー 1033 が表示されます。

トンネル経由で HTTP または HTTPS アプリケーションに接続すると 502 Bad Gateway エラーが表示されます。

オリジンサービスが動いていない

オリジンサービスの URL のプロトコルが違う

オリジンサービスの URL が誤ったポートを指している

cloudflared がオリジン証明書を検証できない

公開アプリケーションが ERR_TOO_MANY_REDIRECTS を返します。

cloudflared access が websocket: bad handshake エラーを表示します。

トンネル接続が SSL エラーで失敗します。

トンネル接続が Too many open files エラーで失敗します。

cloudflared のログに failed to sufficiently increase receive buffer size と表示されます。

Cloudflare Tunnel がストリーミング応答をライブで送らず、バッファーしています。

Palo Alto Networks Next-Generation Firewall 経由で Cloudflare Tunnel が接続できない

オプション 1: App-ID データベースを戻す

オプション 2: 明示的なファイアウォールポリシーを設定する

UDP ポート 7844 のカスタムサービスを作成する

ファイアウォールルールを作成または更新する

サポートへの問い合わせ方法

デバッグログを収集する

`edge discovery: error looking up Cloudflare edge IPs`

`DNS query failed ... i/o timeout`

`Failed to dial a quic connection`

`DialContext error: dial tcp ... i/o timeout`

`cloudflared service is already installed` と表示されます。

`An A, AAAA, or CNAME record with that host already exists` と表示されます。

`x509: certificate signed by unknown authority` エラーが表示されます。

`cloudflared` がオリジン証明書を検証できない

公開アプリケーションが `ERR_TOO_MANY_REDIRECTS` を返します。

`cloudflared access` が `websocket: bad handshake` エラーを表示します。

トンネル接続が `Too many open files` エラーで失敗します。

cloudflared のログに `failed to sufficiently increase receive buffer size` と表示されます。