【ITニュース解説】Cloudflare workersのリバースプロキシ
2025年09月13日に「Dev.to」が公開したITニュース「Cloudflare workersのリバースプロキシ」について初心者にもわかりやすく解説しています。
ITニュース概要
Cloudflare Workersをリバースプロキシとして使う仕組みを解説。WorkersドメインのCNAMEをオリジンドメインに設定し、Workers Routesでスクリプトを紐付ける。Workers内の`fetch(request)`は、CNAME先のオリジンにリクエストを送り、ループせずにプロキシとして機能する。
ITニュース解説
Cloudflare Workersは、ウェブサイトやアプリケーションの機能をインターネットのユーザーに近い場所で実行できる、エッジコンピューティングと呼ばれるサービスである。JavaScriptでコードを記述し、Cloudflareが世界中に持つデータセンターにデプロイすることで、ユーザーからのリクエストに対して高速なレスポンスを返すことが可能になる。
リバースプロキシとは、クライアント(Webブラウザなど)からのリクエストを直接Webサーバーに送るのではなく、一旦別のサーバーが受け取り、そのサーバーが適切なWebサーバーへリクエストを転送する仕組みを指す。この役割を果たすサーバーがリバースプロキシサーバーである。これにより、オリジンサーバー(コンテンツの元となるサーバー)のIPアドレスを隠蔽したり、リクエスト内容に応じて異なるサーバーへ転送したり、セキュリティ対策やキャッシュ機能を追加したりといった、様々なメリットがある。
今回の話題の中心は、Cloudflare Workersをこのリバースプロキシとして利用する仕組みだ。ニュース記事に示された以下のコードに注目する。
1export default { 2 async fetch(request: Request) { 3 return fetch(request) 4 }, 5}
このコードを見ると、Workersが受け取ったリクエストを、Workers自身に再度fetchしているように見えるため、無限ループが発生するように思えるかもしれない。しかし、実際にはこのコードは正常に動作し、Cloudflare Workersがリバースプロキシとして機能する。この一見不思議な動作の背後には、CloudflareのDNS設定とプロキシ機能、そしてWorkersの実行環境の連携がある。
その仕組みを具体的に説明する。まず、二つのドメインを例として考える。
一つはユーザーがアクセスする公開用のドメインworkers.mydomain.comとする。
もう一つは、実際にウェブコンテンツが置かれているサーバーのドメインworkers.myorigin.comとする。このworkers.myorigin.comがコンテンツの元となる「オリジンサーバー」である。
CloudflareのDNS設定において、workers.mydomain.comに対してCNAMEレコードを設定し、その値をworkers.myorigin.comとする。CNAMEレコードは、あるドメインが別のドメインの別名であることを定義するもので、workers.mydomain.comへのアクセスは実質的にworkers.myorigin.comを指し示すことになる。さらに重要なのは、このDNSレコード設定でCloudflareの「プロキシ」機能をONにすることだ。Cloudflareのプロキシ機能がONになると、workers.mydomain.comへのリクエストは直接オリジンサーバーへ送られるのではなく、一旦Cloudflareのネットワーク(エッジサーバー)を経由するようになる。
ユーザーがworkers.mydomain.comにアクセスすると、リクエストはまずCloudflareのエッジサーバーに到達する。Cloudflareは、workers.mydomain.comに紐付けられたWorkersのルート設定を確認し、今回紹介したWorkersのコードを実行する。
Workersが実行されると、コード内のfetch(request)が呼び出される。ここでポイントとなるのは、このfetch(request)がリクエストを送る先がどこか、ということだ。このfetchは、Workers自身にリクエストを投げ返すわけではない。CloudflareのDNS設定でCNAMEとしてworkers.myorigin.comが指定され、プロキシがONになっているため、Workers内のfetch(request)は、ユーザーがworkers.mydomain.comに送った最初のリクエストの内容(URL、ヘッダー、メソッドなど)をそのまま使い、内部的に解決されたオリジンサーバー、すなわちworkers.myorigin.comに対して新しいリクエストを転送するのだ。
つまり、Workersのコードは「ユーザーがアクセスしたworkers.mydomain.comへのリクエストを、設定に基づいてworkers.myorigin.comへ送りなさい」という指示を出していることになる。fetch(request)が送信される先は、Workersがデプロイされているドメインそのものではなく、Cloudflareの設定によって決定される「オリジンサーバー」であるため、無限ループは発生しない。
workers.myorigin.comは、転送されてきたリクエストを受け取り、コンテンツを生成してレスポンスを返す。このレスポンスはCloudflare Workersに返され、Workersは受け取ったレスポンスをそのままユーザーに返す。結果として、ユーザーはworkers.mydomain.comにアクセスしただけで、実際にはworkers.myorigin.comが提供するコンテンツを受け取ることになる。これが、Cloudflare Workersがリバースプロキシとして機能する一連のメカニズムである。
この仕組みを利用することで、Cloudflare Workersは単にリクエストを転送するだけでなく、転送の途中で様々な処理を追加できる。例えば、リクエストヘッダーの変更、URLの書き換え、認証の実施、そして特に強力なのがキャッシュ機能だ。Workersのコード内でキャッシュのロジックを追加すれば、一度オリジンサーバーから取得したコンテンツをCloudflareのエッジサーバーに保存し、次回の同じリクエストに対してはオリジンサーバーに問い合わせることなく、直接エッジから高速にコンテンツを配信できるようになる。これにより、ウェブサイトの表示速度が向上し、オリジンサーバーの負荷も軽減できる。
このように、Cloudflare WorkersはDNS設定とプロキシ機能、そしてエッジで動作するコードの連携によって、柔軟で強力なリバースプロキシとしての役割を果たす。ウェブアプリケーションのパフォーマンス向上、セキュリティ強化、そして運用コストの最適化に貢献する非常に有効なツールと言えるだろう。