原文は左右大佬から提供されました。リンク
読者の皆さんは、筆者のウェブサイトが自宅の 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 の公式な回答（日本語に翻訳）です。
この背後にある理由を再確認させてください：私たちは（Cloudflare として）QUIC プロトコルを「強制」しているのは、それがインターネットの未来において重要な要素であると考えているからです。しかし、まだ多くのネットワークが UDP をブロックしています。私たちは、これらのネットワークの管理者がこの「痛み」をいかに感じるかをいくつかの方法で強制する必要があります。そして、UDP の出口を許可し始めるようになるために、人々が気付き、許可し始めるようにするためです。
たとえば、私たちのプライベート DNS 解決は UDP を使用しており、QUIC プロトコルにのみ対応しています。したがって、ユーザーがデフォルトで http2（UDP プロキシをサポートしていない）のトンネルを起動し、プライベート DNS 解決が機能しないというのは非常に不満です。
さて、謎が解けました。Cloudflare は意図的にデフォルトパラメータで quic プロトコルを設定し、自動的なダウングレード / 切り替えをサポートしていません。http2 を使用したい場合は、手動で指定する必要があります。これほどシンプルで直接的な方法で、Cloudflare は多くのユーザーのために苦労しています！
解決策#
筆者は問題の原因と解決策を徹底的に調査しました。それでは、次の手順は簡単です。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に強制的に指定できます。これにより、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 でトンネルを確立できない問題の原因と解決策についての説明です。もちろん、個々のマシン環境やネットワーク状況などは異なるため、操作中に予期しない問題が発生する可能性があります。解決できない場合は、この記事の後にコメントを残していただければ、筆者ができる限りお手伝いいたします。オリジナルの作成は容易ではありません。この記事が役に立ったと思われる場合は、いいねやブックマーク、フォローなどをしていただけると、私の創作意欲が持続する励みになります！