Cloudflareリバースプロキシの設定方法(チュートリアル)

Cloudflareリバースプロキシは、自分のWebサーバーの前段に配置される。DNSレコードをProxiedに設定すると、訪問者からのリクエストはまずCloudflareのエッジネットワークに届き、Cloudflareがそれをオリジンへ転送する。このチュートリアルでは、自分で運用するサイトでCloudflareをリバースプロキシとして設定する具体的な手順を紹介する。プロキシ設定されたDNSレコードとSSL/TLSモードから、キャッシュ、オリジンルール、curlによるテスト、よくある522・525エラーまでを扱う。

一般的な概念とフォワードプロキシとの違いについては、リバースプロキシとフォワードプロキシの比較の解説を参照してほしい。本記事ではCloudflare固有の設定に絞って解説する。

DataImpulseは倫理的に調達されたプロキシを提供するプロバイダーで、195か国にまたがる9000万以上のレジデンシャル、モバイル、データセンターIPアドレスを提供している。1GBあたり1ドルからの従量課金制で、トラフィックの有効期限もなく、Webスクレイピング、広告検証、価格モニタリング、市場調査、マルチアカウント管理などに利用されている。

始める前に必要なものは?

ドメイン、Cloudflareアカウント、そしてすでにサイトを配信しているパブリックIPを持つWebサーバーが必要である。リバースプロキシとは、クライアントからのリクエストを受け取り、1つまたは複数のバックエンドのオリジンサーバーへ転送するサーバーのことであり、ドメインでCloudflareのネームサーバーを使用すると、Cloudflareがエッジでこの役割を担う。

設定を進める前に、まず以下を用意しておく。

• 稼働中のオリジン: HTTPまたはHTTPSでパブリックIPアドレス(例:203.0.113.10)にアクセスできる自分のサイト。
• Cloudflareのネームサーバー: ドメインのレジストラは、サイト追加時にCloudflareが割り当てる2つのネームサーバーを指す必要がある。
• オリジン側のTLS証明書: 安全なSSLモードを使用するために必要な有効な証明書(Let’s Encryptまたは無料のCloudflare Origin Certificate)。

トラフィックの流れをイメージすると理解しやすい。Cloudflareリバースプロキシのリクエストパスは、DNS -> エッジ -> キャッシュ -> WAF -> オリジンという5段階のモデルである。リクエストはCloudflareエッジのIPに解決され、検査を受けてキャッシュから応答される場合があり、Webアプリケーションファイアウォールを通過して、初めてオリジンに到達する。リクエストパスを把握しておけば、後のトラブルシューティングが容易になる。

Cloudflareリバースプロキシを段階的に設定するには?

サイトをCloudflareに追加し、DNSレコードをProxiedに切り替え、厳格なSSLモードを選択する。DNSレコードのオレンジ色の雲は、そのホスト名に対してCloudflareをリバースプロキシとして機能させるスイッチであり、灰色の雲はDNSのみを意味しエッジを完全にバイパスする。

DNSをオリジンに向け、オレンジ色の雲を有効にする。 DNSタブで、ルートドメインとwww用にオリジンのIPを保持するA(またはAAAA)レコードを作成し、プロキシステータスをProxiedに設定する。

Type   Name   Content        Proxy status
A      @      203.0.113.10   Proxied (orange cloud)
A      www    203.0.113.10   Proxied (orange cloud)

SSL/TLS暗号化モードを選択する。 SSL/TLS設定では、このモードによりCloudflareがオリジンとどう通信するかが決まる。オリジンに有効な証明書がある場合は常にFull(strict)を使う。

SSL/TLS encryption mode
  Off            no HTTPS, do not use
  Flexible       browser-to-Cloudflare only, origin unencrypted (avoid)
  Full           encrypts to origin, accepts any certificate
  Full (strict)  encrypts to origin, requires a valid certificate

キャッシュルールまたはオリジンルールを追加する。 ルールを使うと、エッジが何をキャッシュするか、あるいはオリジンにどう到達するかを制御できる。シンプルなCache Ruleでは静的なパスをキャッシュ対象としてマークし、Cloudflareがサーバーに触れずに応答できるようにする。

# Rules > Caching > Create rule
When incoming requests match:
  (http.request.uri.path contains "/static/")
Then:
  Cache eligibility = Eligible for cache
  Edge TTL = 1 day

Origin Rulesでは、Cloudflareが接続するホストヘッダーやポートを上書きできる。これはバックエンドが非標準のポートで待ち受けている場合に便利である。これらを保存すると、Cloudflareはオリジンの前段でリバースプロキシとして動作するようになる。

リバースプロキシが機能しているかを確認するには?

自分のドメインにリクエストを送り、レスポンスがCloudflare経由で返ってくることを確認する。最も手早い確認方法は、curlによるHEADリクエストで、Cloudflareが付与するserverヘッダーとcf-rayヘッダーを確認することである。

curl -I https://example.com

# Expected headers when proxied:
#   server: cloudflare
#   cf-ray: 8a1b2c3d4e5f6789-FRA
#   cf-cache-status: HIT | MISS | DYNAMIC

server: cloudflareとcf-rayの値が表示されていれば、トラフィックはエッジを経由している。cf-cache-statusがHITであれば、キャッシュルールによってオリジンではなくCloudflareからコンテンツが配信されていることが確認できる。DNSがオリジンの生のIPではなくエッジのIPに解決されていることを確認するには、dig example.com +shortを実行し、返されたアドレスが203.0.113.10ではなくCloudflareのIPレンジであることを確認する。

522エラーと525エラーのトラブルシューティング方法は?

Cloudflareリバースプロキシの障害のほとんどはオリジン側で発生し、リクエストパスの特定の段階に対応している。Cloudflareのブランドが付いたページで5xxエラーが表示される場合、エッジはオリジンの段階に到達しているものの、オリジンが正しく応答しなかったことを意味する。

• エラー522(connection timed out): CloudflareがオリジンへのTCP接続を確立できなかった。ファイアウォールがCloudflareのIPレンジを許可しているか、Webサーバーが稼働しているか、DNSレコードが正しいオリジンIPを保持しているかを確認する。
• エラー525(SSL handshake failed): オリジンがTLSハンドシェイクを拒否した。多くの場合、Full(strict)が設定されているにもかかわらず、オリジン証明書が存在しない、期限切れ、または自己署名であることが原因である。有効な証明書またはCloudflare Origin Certificateをインストールする。
• リダイレクトループ: Flexible SSLモードとHTTPSを強制するサーバーの組み合わせは無限ループを引き起こす。FullまたはFull(strict)に切り替える。

リクエストパスはDNS -> エッジ -> キャッシュ -> WAF -> オリジンであるため、522や525は常に最後のホップを指しているので、デバッグはオリジンとその証明書から始めるとよい。

実際にはどのプロキシタイプが自分の用途に合うのか?

自分が所有するサーバーを保護・高速化したい場合はCloudflareリバースプロキシを使い、多数の異なるIPからアウトバウンドリクエストを送信する必要がある場合はフォワードプロキシを使う。両者は用途が正反対のツールであり、混同はよくある誤りである。

リバースプロキシは自分のサーバーの前段に立ち、インターネットに対してそのサーバーを代表する。フォワードプロキシはクライアントの前段に立ち、インターネット上でクライアントを代表する。以下の比較でその向きの違いが明確になる。

この比較が成り立つ前提として、正直に述べておくべきことがある。Cloudflareリバースプロキシは自分のサイトの前段に立つものであり、アウトバウンドリクエストを多数の異なるIPから発信しているように見せることはできない。もしデータ収集、地域別テスト、または多数の地域からの広告検証が目的なら、それはフォワードプロキシという別のツールの領分である。そのためにDataImpulseは、195か国にわたるローテーティングのレジデンシャルプロキシとデータセンタープロキシを提供している。CloudflareはDataImpulseの製品ではなく、両者は正反対の課題を解決するものである。

次の判断基準を使うとよい。

• Cloudflareリバースプロキシを使うべき場合: WebサイトやAPIをホストしており、キャッシュ、TLS、DDoS対策、そしてオリジンIPの隠蔽を求めている場合。
• 実はフォワードプロキシが必要な場合: スクレイピング、価格モニタリング、広告検証のために、さまざまなIPからアウトバウンドのリクエストを発行する必要がある場合。詳しくはブロックされずにWebサイトをスクレイピングする方法を参照。
• Cloudflareリバースプロキシを避けるべき場合: 自分自身のアウトバウンドトラフィックの匿名性が目的である場合。リバースプロキシが保護するのは宛先であり、リクエスト元ではないためである。

限界とリスクは何か?

Cloudflareリバースプロキシは、自分が所有するサイトを保護するうえで強力だが、汎用的なネットワークツールではない。利用する前にこれらの限界を理解しておく必要がある。

• アウトバウンドトラフィックを匿名化しない: リバースプロキシが隠すのは訪問者から見たオリジンであり、第三者から見た自分のリクエストではない。
• オリジンIPが露出すると無効化される: 攻撃者が古いDNSレコードやメールヘッダーなどから生のオリジンIPを発見すると、エッジを迂回できてしまう。オリジンのファイアウォールはCloudflareのIPレンジのみに制限しておく。
• Flexible SSLは安全ではない: Cloudflareとオリジンの間の区間が暗号化されないままになるため、Full(strict)を優先する。
• キャッシュの正確性: 範囲が広すぎるキャッシュルールは、古いコンテンツや非公開のコンテンツを配信してしまう可能性がある。ルールは静的なパスに限定する。

DataImpulseは倫理的に調達されたプロキシのプロバイダーであり、静的なISPプロキシの販売、マネージド型のスクレイピングAPI、無料のWebプロキシサービスは提供していない。プロキシの用語に慣れていない場合は、ツールを選ぶ前にWebプロキシとは何かのガイドで基本を確認してほしい。

よくある質問

関連ガイド

• NGINXリバースプロキシ
• Dockerリバースプロキシ
• NGINXフォワードプロキシ

リバースプロキシではなくアウトバウンド用IPが必要ですか?

自分のサイトを保護することではなく、多数の地域からデータを収集したり結果を検証したりすることが目的なら、フォワードプロキシこそが適したツールである。DataImpulseは、195か国で1GBあたり1ドルから、従量課金制でトラフィックの有効期限なしのローテーティングレジデンシャルプロキシを提供している。始めるにはアカウントを作成してほしい。