2023年の障害では、cloudflaredコンテナがQUIC接続のタイムアウトを吐き続け、サイトも落ちた。HTTP/2を指定したら接続は戻った。ただしこれはあくまで診断の手段であって、キャリアがUDPを遮断していると断定できる材料ではないし、今のバージョンなら自動フォールバックしないと決めつけるのも間違いだ。
ログから読み取れること
当時のエラーはこれだった。
Failed to create new quic connection
failed to dial to edge with quic: timeout: no recent network activity
QUIC接続が失敗したということまでは分かるが、この2行だけでキャリアのUDP遮断と断言はできない。ホストのファイアウォール、ルーター、ネットワークポリシー、そのときの回線状況なども疑ってみる必要がある。
QUICはUDPベースで、cloudflaredがQUICを使うには外向きUDP 7844が必要になる。HTTP/2なら外向きTCP 7844だ。現在の--protocol autoはデフォルト値で、まずQUICを試し、張れなければHTTP/2にフォールバックする。QUICのタイムアウトが続くからといって、自動切り替えに非対応だと解釈してはいけない。
説明図：cloudflared：autoが現在のデフォルトのプロトコル選択
一時的にHTTP/2を指定する
ログがQUICタイムアウトばかりなら、--protocol http2を明示して復旧するか見てみるといい。以下はtunnel tokenをComposeのコマンドに直書きせず、tokenファイルを使う例だ。
services:
cloudflared:
image: cloudflare/cloudflared:latest
restart: unless-stopped
command: tunnel --no-autoupdate --protocol http2 run --token-file /run/secrets/tunnel_token
volumes:
- ./tunnel-token:/run/secrets/tunnel_token:ro
--token-fileにはcloudflared 2025.4.0以降が必要だ。まず自分のtokenを書いた実ファイルを用意し、必要なアカウントだけが読める権限にする。コンテナの実行ユーザーが読めることも確認しよう。rootしか読めないのに非rootのコンテナから開こうとしても無理だ。このファイルはGitにコミットしたり、公開ディレクトリに同期したりしないこと。
docker compose up -d
docker compose logs --tail=100 cloudflared
コンテナを作り直す前に、自分が使える管理用の入口があるか確認しておく。成功時のログにはRegistered tunnel connectionと使用プロトコルが出るはずだ。これはあくまで観察の仕方であって、今回実際に試した結果のスクリーンショットではない。
HTTP/2でもTCPの外向き接続は必要だ。TCP 7844まで塞がれているなら、パラメータを変えても解決しない。Tunnelでは、自宅ルーターに7844の受信ポートマッピングを追加する必要はない。
トンネルはオンラインなのにサイトが開かない
cloudflaredからCloudflareエッジへの接続が正常なのは、最初のホップが通っているというだけのこと。cloudflaredが自分で設定したオリジンに到達できるかも確認する必要がある。
説明図：トンネルがオンラインでも、オリジンというホップも確認する
cloudflaredがDockerの中にいる場合、オリジンにlocalhostと書くとそれはcloudflared自身のコンテナを指し、NASにはならない。オリジンが別コンテナなら、適切な同じDockerネットワークに入れてサービス名を使う。オリジンがLAN上のマシンなら、コンテナから実際に届くアドレスとポートを使う。証明書検証を全部オフにするのではなく、オリジンのプロトコルと証明書を確認しよう。
この記事は当時の障害の経緯を踏まえ、現在のデフォルトのプロトコル動作、ポート、認証情報の扱いを説明したものだ。設定例はドキュメントと照合済みだが、実際のTunnelで実機テストはしていない。
参考：実行パラメータ、ファイアウォール要件。