原文は左右大佬から提供されました、リンク
読者の皆さんはおそらく知っていると思いますが、筆者のウェブサイトは自宅の NAS に構築されており、Cloudflare Tunnels を使用してパブリックネットワークアクセスを実現しています。Cloudflare の CDN と組み合わせて使用すると、全体的にはうまく機能しています。しかし、最近はトラブルが増えてきており、Cloudflared コンテナは正常に動作しているのにも関わらず、常に Cloudflare とのトンネルを確立できません。その結果、ウェブサイトがオフラインになり、アクセスできなくなってしまいます。
以下のような状況です。この時点ではウェブサイトも開けません。
問題の特定#
CloudFlared コンテナのログを確認する#
よく言われることですが、「困った時は量子力学！」と言います！信じられないかもしれませんが、この言葉は本当に当てはまります！
筆者は NAS にログインし、Cloudflared コンテナのログを開いてみると、以下のエラーメッセージが表示されていました。
2023-10-13T09:52:58Z ERR Failed to create new quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=1 ip=198.41.192.227
2023-10-13T09:52:58Z INF Retrying connection in up to 2s seconds connIndex=1 ip=198.41.192.227
2023-10-13T09:52:58Z ERR Connection terminated error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=1
特に注目すべき行は次のとおりです。
ERR Failed to create new quic connection error="failed to dial to edge with quic: timeout: no recent network activity"
これは新しいquic接続の作成に失敗し、quicプロトコルを使用してエッジサーバーに接続できないことを意味しています。つまり、quicプロトコルを使用してトンネルを正常に確立できないということです。
偶然にも、Cloudflare はquicプロトコルで確立されたトンネルを「後量子トンネル」と呼んでいます。まさに「困った時は量子力学」と言えるでしょう！
quic の失敗原因#
本題に戻りますが、なぜquicプロトコルを使用してトンネルを作成できないのでしょうか？これにはquicプロトコル自体の特性が関係しています。以下は某度百科からの引用です。
QUIC は Quick UDP Internet Connections の略で、これは実験的なトランスポート層ネットワークプロトコルであり、Google によって 2013 年に開発されました。
つまり、quicは現在の主流のhttpプロトコルとは異なり、UDP 上に構築されています。そして、周知のように、UDP プロトコルは国内のインターネットサービスプロバイダにとって好ましくない、差別されるプロトコルです。その結果、UDP を基にした接続が遮断されることになります。納得できるでしょうか？
CloudFlare の公式回答#
原因と背後の原因がわかりましたが、筆者の頭の中にはまだ一つの疑問が残っています。それは、Cloudflared が何度もquicプロトコルを使用してトンネルを作成できなかった後、なぜhttpプロトコルに切り替えないのかということです。一つの問題に対して徹底的に取り組むという意気込みで、筆者は実際にその理由を見つけました。以下は Cloudflare の公式な Github の回答（日本語に翻訳）です。
この背後にある理由を再確認させてください：私たちは（Cloudflare として）quic プロトコルを「強制」しているのは、それがインターネットの未来において重要な要素だと考えているからです。しかし、まだまだ多くのネットワークが UDP をブロックしています。私たちはこれらのネットワークの管理者にある種の「痛み」を感じさせる必要があります。そうすることで、人々が UDP の出口を許可し始めることに気付き、そして許可するようになるでしょう。
たとえば、私たちのプライベート DNS 解決は UDP を使用しており、QUIC プロトコルにのみ対応しています。したがって、ユーザーがデフォルトで http2（UDP プロキシをサポートしていない）のトンネルを起動し、プライベート DNS 解決が機能しないというのは非常に不満です。
さて、謎が解けました。Cloudflare は意図的にデフォルトのパラメータで quic プロトコルを設定し、自動的なダウングレード / 切り替えをサポートしていません。http2 を使用したい場合は、手動で指定する必要があります。これほどシンプルで直接的な方法で、多くのユーザーのために苦労しています！
解決策#
筆者は問題の原因と解決策を徹底的に調査しました。それでは、以下の手順で簡単に解決できます。Cloudflared コンテナの起動パラメータでプロトコルをhttp2に変更するだけです。
version: '3.8'
services:
cloudflared:
container_name: cloudflared
restart: unless-stopped
network_mode: bridge
environment:
- TZ=Asia/Shanghai
command: tunnel --no-autoupdate --protocol http2 run --token <youtoken>
image: 'cloudflare/cloudflared:latest'
compose ファイルに
--protocol http2を追加するだけで、プロトコルをhttp2に強制的に指定します。これにより、UDP を使用せずに TCP を使用するため、インターネットサービスプロバイダによる遮断を受けなくなります。
もちろん、
--protocol autoに設定することもできます。これにより自動切り替えが有効になり、デフォルトではまだquicが使用されますが、失敗した場合に自動的にhttp2に切り替わります。
その後、コンテナを再作成および起動し、ログを確認すると、http2 を使用してトンネルが正常に作成されたことがわかります。
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=1 connection=b497b5fb-3f4e-45dd-85fb-e18c2439b5d3 event=0 ip=198.41.200.73 location=sjc05 protocol=http2
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=2 connection=3d668d56-73d9-4c2d-bd4b-2b2becbdecbf event=0 ip=198.41.192.47 location=lax01 protocol=http2
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=0 connection=b7c5ebd7-84f6-4070-b5af-abf653d0d345 event=0 ip=198.41.192.67 location=lax07 protocol=http2
2023-10-13T12:01:29Z INF Registered tunnel connection connIndex=3 connection=b5af99db-761c-462c-b793-32ef19d0258a event=0 ip=198.41.200.63 location=sjc05 protocol=http2
Cloudflare コンソールの Tunnels の状態も正常に戻りました！
これで、私のウェブサイトを正常に開くことができます！
以上が Cloudflare Tunnels でトンネルを確立できない問題の原因と解決策についての情報です。もちろん、個々のマシン環境やネットワーク状況などは異なるため、操作中に予期しない問題が発生する可能性があります。解決できない場合は、この記事の後半にコメントを残していただければ、筆者ができる限りお手伝いいたします。オリジナルの作成は容易ではありませんが、この記事がお役に立てば、いいねやブックマーク、フォローなどをしていただければ幸いです。皆さんの励ましは私の創作活動の原動力です！