序

私のサーバーはVultrに移行したタイミングでCloudFlareを使うようになった。

それ以前は基本的にConoHaに依存したつくりになっていたものを構成し直した形で、それから2年ほど経っている。

現在となっては私のサーバー群においてCloudFlareは主要なインフラコンポーネントのひとつであるが、すべてのサイトに適用しているわけではない。現に、ChienomiはCloudFlareのプロキシを使わないサイトのひとつだ。 そして、CloudFlareを使うもの/使わないものを混ぜて2年間使ってきたことで、CloudFlareの良し悪しが見えてきた。

ここではCloudFlareを使っていない人向けに、ここまでで感じたメリット・デメリットを話す。

なお前提として私はフリープランであり、なおかつなるべくCloudFlareへの依存度を下げるように運用している。

以降、CloudFlareのことをCFと表記する。

CFの仕組みと料金

仕組みといっても主に設定周りの話で、プロキシの仕組みの話は基本的にしない。

CFはまずドメインを登録するところから始まる。 CFドメインを使っている場合はCFのDNSを使う前提となり、CFのサイトとして登録される。

CFは登録されているドメインを「サイト」という単位で取り扱う。 これはウェブサイトにとって大きな制約となる場合がある。サブドメインを含めて同一サイトとされるため、基本的にサブドメインごとに構成を変更することはできない。 (部分的には構成ルールによって適用することができるものもある。)

つまり、サブドメインで全く異なる性質のものをホストするのには適さない。 ただし、CF経由のアクセスにしないのであれば、DNSでプロキシを「DNS のみ」に設定すれば良い。

有料プランもサイト単位での適用になる。 サブドメインの話はひとつのドメインにまとめていると不便な話だったが、課金に関しては細かくドメインを分けている場合のほうが厄介である。

アクセス削減

CFのプロキシを有効にしている場合、CFがリバースプロキシとして動作する。 この場合、CFのDNSはCFのアドレスを返し、HTTP/HTTPSのリバースプロキシになる。

CFでプロキシを有効にすると、そのドメインを名前解決してアクセスできるのは80/443ポートだけである。

自分が管理していないリバースプロキシが存在することで、トラフィックが減少し、帯域が節約される。 これは主たるメリットのひとつである。

私の管理しているサイトでは、少ないもので1%、多いもので40%程度リクエストが削減されている。 宇宙庭園が20%程度だから、アプリの場合がこれくらいだろうか。

これにより帯域とサーバーリソースを節約することができる。

防御機能

CFを使うとわずかだが悪意あるアクセスを遮断することができ、特別な状況ではBot Fight ModeでさらにBotアクセスを抑制することができる。

これが役に立つ場面は非常に限定的だが、DDoSを目的としていない悪意あるアクセスによりDDoS的な効果が発生してしまうケースにおいてはBot Fight Modeが役に立ったこともある。

IPアドレスの隠蔽

サーバーインスタンスに対してプロキシされたアクセスのみを返すようにDNSを設定すると、サーバーインスタンスのIPアドレスがDNSによって公開されない。

CFのプロキシはそもそもHTTP(s)以外のアクセスを中継しないため、SSHなど非HTTPの攻撃的アクセスが劇的に減る。 これ自体がセキュリティとして機能するわけではないが、HTTPのみを提供するサーバーでは結構有用である。

可用性

CFは非常に安定していて、CFが機能しないせいでアクセスできなかったことは、この2年で1度しかない。 これはVultrが年数回はアクセス障害を起こすのと比べて圧倒的に低い。

ただし、CFに起因する問題でアクセスできなくなったことは他にもある。 最近で言うと2025-04-16に、525エラーを発生させるようになったという問題があった。

Cipherやバージョンを最大限ゆるめても解決せず、最終的にはssl_prefer_server_ciphers no;にすることで解決したのだが、このような「CF経由にしたときだけ問題が生じる」というのは時々ある。

レジストラとDNS

CFでドメインを取得することができる。 「原価で」ということで安価ではあるのだが、ドル建てなので日本のレジストラより安いかは微妙。

CFをレジストラとして使うと必然的にDNSを使うことになるが、DNS設定もかなり扱いやすいため、プロキシを使わない場合でもDNSだけ使うのはアリ。

悪くないサービスもある

例えばオブジェクトストレージのR2は、0.015USD GB/Mo。

これは0.025USD GB/MoのAmazon S3や、Vultr Object Storageの0.018USD GB/Moより安い。

MEGA S4は容量単価にすると0.005EUR GB/MoなのでS4のほうが圧倒的に安いように思えるが、3TB以上1TB単位の上限容量での支払いになるため実際はS4のほうが大抵高い。 Wasabiも0.0068GB/Moではあるが、1TB単位である。

R2の場合、クラスA操作(write/list)が100万回あたり4.5USDと割と高めに設定されており、クラスB操作(read)は100万回ごと0.36USDとなっている。 ログ置き場にしたりするとかなり高くなるが、メディアアップロード先のようなread主体の使い方であればかなり安い。

対して安価なVultrの場合は、エグレス料金が1TB無料枠で、以降1GBあたり0.01USDとなっている。 エグレス料金がかかるため、こちらはwrite主のほうが安い。

このほか個人的に注目したいのは、ビデオ配信のインフラとして使えるStream。 これは普通にVPSでやろうとすると負担の重い機能なので、必要になったときには非常に有用な気がする。

最大の問題はログ

CFは前述したように、プロキシとして利用することでCFがリバースプロキシとなり、キャッシュすることによりトラフィックを削減する。

しかし言い換えるならば、すべての接続がオリジンサーバーに到達しない。 これにより、アクセスの計測が不可能になる。

また、アクセスはCFによって行われるため、接続元がCFのものになる。 これによりIPアドレスベースのパケット制御ができなくなり、ログとしても専用の仕組みが必要になる。¹

ただ実際のところキャッシュでトラフィックが節約されている時点でアクセス計測・分析にはあまり意味がないため、IPアドレスの問題は相対的にどうでもいい感じではある。

すると正しいやり方はCloudFlareのログを使うことになるところだが、CloudFlareでログをpushさせると節約されたトラフィックを上回るトラフィックが発生してしまうし、pullするにしても「7日以内の1時間幅」という厳しい制限により実用は結構厳しい。

ログをきちんと分析したい場合はCFは使えない。

速度面はCFがいまいち

これは非常に環境に依存するところで、サーバーの処理能力や帯域、アクセス量やレスポンスサイズに大きく左右される。

だが、CFを介しているとリクエストの立ち上がりが遅くなるため、私のように小さなテキストや画像を主体とするサイトでは全体的にかなり遅くなる。 サーバー処理能力も高く、余裕もあるため、なおさら直接アクセスのほうがずっと速い。

これはNginxで静的配布しているChienomiのみならず、PiecesのようにNginx+Lighttpdで配布しているケースよりも遅い。

結局「帯域節約」にどれくらいの価値が生じているかに左右されているという結論になる。

メール機能は微妙

うちの場合はメールサーバーはかなり手の込んだ運用をしているため単純には比べにくいが、「設定したメールアドレス宛のメールを他のメールアドレスに転送する」という機能であり、送信能力もなく、メールアドレスを柔軟に設定できるわけでもないため使い勝手はよくない。

恐らく独自ドメインを使えるメールサービスを契約するほうが良い。

レスポンスの悪さ

CFのインターフェイスがウェブベースであり、ページ遷移を伴う場合はかなり遅い。

DNSの設定など、ページ内で完結している部分は快適なのだが、ページ遷移が遅いため設定や操作するときにかなり煩わしさを感じることがある。

キャッシュの不便

細かいキャッシュのコントロールはあまりやりやすくなく、特にフリープランではあまり細かなことはできない。

また、構成がしっかり決まっている完成したものを動作させる場合はキャッシュが邪魔になることはそれほどないのだが、開発やテスト中はだいたい邪魔になる。

それ用に開発モードが存在し、キャッシュを一時的に無効にできるのだが、サイト単位になるためキャッシュしておきたい別のサブドメインまで響いたりする。

もっとも、開発モードによってキャッシュを無効にしていることは少なくともCFがマイナスに作用しているわけではないのだが。

総合的な所感

CFの噛み合いは、現代的なインスタントWebアプリ構成とよく噛み合う。 つまり、Dockerベース、あるいはKubernetesを用いた実行環境との組み合わせだが、AWS, GCP, Azureなどは自前でCDNを持っているのでそのような実行環境においてCFを組み合わせるということがそもそも少ないだろう。

それ以外のケースを考えると、典型的WordPressサイトにおいてはメリットが少なく、熱心なブロガーの場合はアクセス解析をWordPress側で行えないことに不満を覚えるだろう。

静的ファイルをホストしているサイトよりはアプリに適している。 実際、AkkomaやMisskeyではかなり効果を感じている。

CFに依存したアプリ開発をする場合はもっと強力に活用できる。 コンテンツ配信に関する様々な機能が提供されており、合理的なインフラ構成としてCFを組み込むという選択肢は結構有力だと思う。

私のウェブサイトの作りではそのほとんどにおいてあまり意味はないが、CFのレジストラとDNSの機能は便利なので、根本的なレベルでCFを使うということ自体は結構メリットを感じている。 一方で、CFの中核的機能であるプロキシに関しては必要性に乏しく、Akkomaのような一部のものを除けば別に必要ない感じである。

プロキシよりは、R2やStreamなどの機能のほうが魅力的に映り、「CFの機能を使うためにアプリを作る」というモチベーションにもなる気がした。