日曜の深夜にCloudflareの隠れたバグを見つけた方法(curlの喜び)
ちょっとした週末プロジェクトのはずだった。あの手のやつだ。「出力用VMを立ち上げて、トラフィックをルーティングして、コーヒーをすすって、昼までに終わらせる」というやつだ。読者よ、昼までには終わらなかった。

ちょっとした週末プロジェクトのはずだった。あの手のやつだ。「出力用VMを立ち上げて、トラフィックをルーティングして、コーヒーをすすって、昼までに終わらせる」というやつだ。読者よ、昼までには終わらなかった。
セットアップ
いくつかの開発環境用に小さなアクセス層を構築していた。Cloudflare Zero Trustを前に置いた出力用VM、2つの特定の開発ドメイン用のホスト名ベースのルーティング、そしてソースIPをチェックするAWS WAFを反対側に配置するものだ。「チームに安全なアクセスを提供し、パブリックインターネットに公開しない」というごく標準的な構成だ。
TLS復号を有効にする必要がある部分に当たるまではすべて順調だった。これはCloudflareのゲートウェイがトラフィックを実際に検査し、単なるIPではなくホスト名に基づいてルーティングできるようにする魔法だ。これがないと、美しいホスト名ルールはただそこに座っているだけで何もしてくれない。
チュートリアルの迷路
Cloudflareの公式ラーニングパスに従った。3つの異なるブログ記事に従った。本当にチャンネル登録してほしそうな声の人のYouTubeチュートリアルにも従った。みんな同じことを言っていた:
Zero Trust > Settings > Network > Firewall > TLS decryption に移動してスイッチを入れる。
そこでそこに行った。スイッチを入れた。すると画面の上部に赤いバナーが表示された。そこにはただこう書かれていた:
TLS設定の構成中にエラーが発生しました。
それだけだった。コードなし。ヒントなし。「詳細はこちら」のリンクもなし。ただ「何かがうまくいかなかった、がんばって」という雰囲気だけ。
もう一度試した。同じエラー。更新した。同じエラー。Firefoxで試した。同じエラー。キャッシュをクリアした。同じエラー。コーヒーを淹れようかと考えた。コーヒーを淹れた。同じエラー。
探偵作業
ここで私の大好きなツールの出番だ。UIが何が問題かを教えてくれないときは、ネットワークタブとcurlが教えてくれる。デベロッパーツールを開き、トグルが送信しているリクエストを監視し、curlとしてコピーしてローカルで実行した:
{
"result": null,
"success": false,
"errors": [
{
"code": 2211,
"message": "TLS decryption cannot be enabled without a certificate. Please disable TLS encryption or configure a certificate using the 'certificate' setting."
}
],
"messages": []
}そこにあった。明確で、役に立ち、行動可能なエラーメッセージ。UIに表示されていれば、私の人生の約90分を節約できたはずのメッセージだ。代わりにそれはJSONレスポンスの中に隠れ、APIと画面の間のどこかで飲み込まれていた。
メッセージは基本的に「まず証明書が必要だ、このポテト野郎」と言っていた。(要約です。)
本当の修正方法
インターネット上の誰も言及していないように見えることがある: 証明書管理が移動している。
私が読んだすべてのガイドは古い場所を指していた。実際の現在の場所は完全に別のセクションに埋もれている。具体的には:
Zero Trust > Traffic policies > Traffic settings > Certificates (上部のタブ)Networkではない。Firewallではない。Traffic policies > Traffic settingsだ。
そこでCloudflare管理の証明書を生成する。それをAvailableとIn-Useとしてマークする。そして5〜10分待つ(この部分も誰も言及しない。ステータスフィールドを見つめながら静かに人生の選択を問い直すだけだ)。証明書が完全にアクティブになったら、ようやく戻ってTLS復号を有効にできる。
それで動く。トグルが切り替わる。赤いバナーは現れない。世界は再び意味を成す。
教訓
この小さな冒険から2つのことが心に残った。
第一に: ドキュメントは間違っていなかった。ただ古かっただけだ。 Cloudflareは速く動き、ダッシュボードを頻繁に再編成する。これは不満ではなく、単なる現実だ。急速に進化する製品のガイドに従うときは、メニューパスがずれている可能性があることを想定すべきだ。概念は同じだが、ボタンはスクリーンショットが示す場所に常にあるとは限らない。
第二に: ネットワークタブは最高の友達だ。 UIが役に立たないエラーを出すとき、APIはほぼ常により多くを知っている。ブラウザのデベロッパーツール、curl、あるいは単に生のレスポンスを読むことこそが、5分でデバッグするのと5時間でデバッグするのとの違いだ。UIのエラーハンドリングは、より冗長なシステムの上に塗られた薄い層であり、そのシステムは通常そこにいて、丁寧に尋ねるのを待っている。
ボーナス
これはCloudflareに報告した。エラーコード2211には完全に良いメッセージが付属している。それが画面に届いていないだけだ。誰かが気付いて、将来の週末戦士があいまいなバナーではなく役立つバナーを目にすることを願っている。
それまでは、「TLS設定の構成中にエラーが発生しました」という詳細のないメッセージを見たら、答えはおそらく:
- 最初に証明書を生成する(Traffic policies > Traffic settingsの下で)
- AvailableとIn-Useにマークする
- 待つ
- それからTLS復号を有効にする
では失礼する。ようやく動く出力用VMと、2回冷めたコーヒーがあるので。
日曜の深夜(02:42 AM)のデバッグ机から乾杯。
Ercan の他のサイト
同じ著者、別の領域のサイトが2つ。