wwwありは動くのに、なしは503。Cloudflare Workersに独自ドメインを設定した話

ブログを自分のドメインで公開したい

前回の記事では、静的配信していたNext.jsブログをvinext＋Cloudflare Workersへ移行しました。

次に進めたのが、独自ドメインでの公開です。使うのは、お名前.comで取得した bpacket.com。別のサイトやメールでは使っていないドメインでした。

ただ、私はまだCloudflareの操作や設定に慣れていません。DNS、Workers、Custom Domains、Routesといった項目を見ても、それぞれどこまで設定すればよいのか、最初から理解できていたわけではありませんでした。画面と公式ドキュメントを確認しながら、一つずつ進めました。

ところが設定を進めると、少し分かりにくい状況になりました。

wwwありではブログが表示されるのに、wwwなしでは「An error occurred.」と表示される。

Cloudflare側の設定が足りないのか、Next.js側にも何か設定が必要なのか。その切り分けにも迷いましたが、今回不足していたのは、Cloudflare側のWorkerへのルーティングでした。

この記事は、Cloudflareに慣れていない私が、独自ドメインでブログを表示できるようになるまでの作業記録です。同じように「ドメインは登録したのに表示されない」と迷ったときの参考になればと思います。

お名前.comとCloudflareの役割

まず、お名前.comとCloudflareの役割を整理しました。

ドメインの契約・更新はお名前.comで続け、DNSの管理とブログの公開にはCloudflareを使います。 設定する場所を混同しないよう、それぞれの役割を次の3つに分けて考えました。

• お名前.com：ドメインの契約・更新と、利用するネームサーバーの指定。
• CloudflareのDNS：ドメインやサブドメインのDNSレコードを管理。
• Cloudflare Workers：ブログを実行し、アクセスに応じてページを返す。

ドメインを取得すること、CloudflareでDNSを管理すること、Workerにアクセスを届けることは、それぞれ別の作業です。この区別が、今回のつまずきを理解するポイントでした。

お名前.comのドメインをCloudflareで使う準備

一般的なネームサーバー切り替えの流れは、次のとおりです。

1. Cloudflareに bpacket.com を追加する。
2. Cloudflareがそのドメインに割り当てたネームサーバーを確認する。
3. お名前.com Naviで対象ドメインのネームサーバー設定を開く。
4. 「その他のネームサーバーを使う」を選び、Cloudflareが指定した値を登録する。
5. Cloudflare側でドメインが有効になったことを確認する。

ネームサーバー名は、Cloudflareの画面に表示された値を使います。他の人の設定例をそのままコピーする部分ではありません（参考：お名前.comの公式案内）。

今回のドメインは未使用でしたが、すでにメールや別サイトで使っているドメインなら、切り替え前に既存のDNSレコードを確認し、必要なレコードを引き継ぎます。

ここまでの準備と、ブログのWorkerへの接続は別です。Cloudflare上にドメインが登録されていても、それだけで目的のWorkerにアクセスが届くとは限りません。

wwwありは表示されるのに、wwwなしはエラー

設定途中に確認した応答は、次の状態でした。

• https://bpacket.com：HTTP 503。nginxのエラーページ。
• https://www.bpacket.com：HTTP 200。ブログのHTMLを返す。

wwwなしで表示されたページには、次のメッセージがありました。

An error occurred.

ページ末尾にはnginxの表記もありました。一方、wwwありではvinextで生成されたブログのHTMLが返ってきていました。

少なくとも、ブログ自体が動いていないわけではありません。ホスト名によって応答が違うので、まず接続先の設定を確認することにしました。

前回の移行中には、デプロイ失敗で「Hello World」が表示されることもありましたが、今回はそれとは別の問題です。ブログが動いているURLと、503になるURLが分かれていました。

オレンジの雲は、Workerへの接続完了ではなかった

CloudflareのDNS画面には、bpacket.com と www.bpacket.com のAレコードがあり、どちらも「プロキシ済み」になっていました。ただし、それぞれの接続先IPは異なっていました。

Cloudflareに慣れていないこともあり、オレンジの雲と「プロキシ済み」の表示を見て、「これでブログにつながる設定は終わっているのでは」と思っていました。

ですが、Cloudflareのプロキシを経由する設定と、対象Workerを実行する設定は別でした。

今回、wwwなしではDNSに設定されていた接続先からエラーが返っていた可能性があります。ただし、nginxのサーバーログまで確認したわけではないので、そのサーバー内部で503になった理由までは分かりません。

切り分けで確認できたのは、wwwなしからブログのWorkerへ渡す設定が不足しており、その追加で表示できるようになったことです。

Workerにルートを追加すると表示された

確認したのは、対象Workerの設定にある 「カスタムドメインとルーティング」 の画面です。英語表記では Settings → Domains & Routes にあたります。

最終的に画面に登録されていたルートは、次の2つでした。

bpacket.com/*
*.bpacket.com/*

bpacket.com/* は、wwwなしのドメイン配下へのアクセスを対象にします。*.bpacket.com/* は、wwwを含むサブドメイン側へのアクセスを対象にするパターンです。

当初登録されていたのは *.bpacket.com/* だけでした。このパターンはサブドメイン（wwwなど）には一致しますが、wwwなしの bpacket.com そのものには一致しません。wwwありだけが表示できていたのは、このためです。

そこで bpacket.com/* を追加すると、https://bpacket.com でもブログが表示されました。今回の解決に、Next.js側のドメイン設定変更は必要ありませんでした。

なお、ワイルドカードのルートを追加しても、サブドメインのDNSレコードが自動で作られるわけではありません。Routes方式では、対象ホスト名にCloudflareでプロキシされたDNSレコードも必要です（参考：CloudflareのRoutes公式ドキュメント）。

実際に使ったRoutesと、Custom Domainsの違い

ここは、今回とくに混同した部分です。「独自ドメインを使う」という目的と、画面にある「Custom Domains」という機能名を、同じものとして考えていました。設定後の画面を確認して、実際に使っていた方式を整理しました。

今回、表示できるようになったときの画面では、登録項目のタイプが「ルーティングする」になっていました。つまり、実際に追加したのはRoutes方式のルートです。

独自ドメインで表示できるようにした、という意味では同じでも、Cloudflareの機能名としての Custom Domains を追加したわけではありません。

Cloudflareの公式ドキュメントでは、次のように使い分けられています。

• Routes：URLのパターンに一致するアクセスでWorkerを実行する。既存のオリジンサーバーの手前でWorkerを動かす構成向け。
• Custom Domains：ホスト名全体をWorkerへ接続する。Worker自身がサイトを提供する構成向けで、DNSレコードや証明書もCloudflareが管理する。

今回のようにWorker自身がブログを提供する場合、公式に案内されているのはCustom Domainsです。新しく同様の構成を作るなら、対象Workerの Domains & Routes → Add → Custom Domain から設定する方法を検討できます（参考：CloudflareのCustom Domains公式ドキュメント）。

この記事は、実際にRoutesを追加して解決した記録です。Custom Domainsへ切り替えた手順や、その後の動作確認までは含めていません。

wwwあり・なしは、それぞれ確認する

今回学んだのは、次の2つをセットで確認することでした。

https://bpacket.com
https://www.bpacket.com

同じブログのURLとして扱いたくても、ホスト名は別です。片方が表示できても、もう片方の接続まで設定済みとは限りません。

また、今回の *.bpacket.com/* はwww以外のサブドメインにも一致します。サブドメインはwwwだけに限定するなら、Routes方式では次のように範囲を限定する考え方もあります。

bpacket.com/*
www.bpacket.com/*

これは設定を整理する際の候補であり、今回その変更まで行った記録ではありません。

両方で表示できるようにすることと、片方へリダイレクトしてURLを統一することも別です。今回のルート追加だけで、どちらか一方への転送（リダイレクト）まで設定されたわけではありません。

同じ症状になったら確認したいこと

独自ドメインでエラーになったとき、アプリのコードを変更する前に、次の順番で確認すると状況を整理しやすくなります。

1. Workerのデプロイが成功しているか。対象のブログが動くURLがあるかを確認する。
2. wwwあり・なしで応答が違わないか。表示だけでなく、HTTPステータスも確認する。
3. CloudflareのDNSレコードがどうなっているか。対象ホスト名、接続先、プロキシ状態を見る。
4. 対象WorkerのDomains & Routesに接続設定があるか。ドメインをCloudflareへ登録しただけで終わっていないかを見る。
5. 設定がRoutesなのかCustom Domainsなのか。方式に合ったDNS設定になっているかを確認する。

今回は、お名前.comで取得したドメインを使い、Cloudflare側で不足していたルートを追加することで表示できました。

まだCloudflareを使いこなせるようになったわけではありません。それでも、今回の作業で「ドメインを登録した」「DNSがプロキシ済みになった」「Workerへ接続できた」は、それぞれ確認する必要があると分かりました。

慣れていないと、設定画面にそれらしい項目があるだけで、接続まで完了したと思ってしまいます。今回はwwwあり・なしの応答を比べ、設定を一つずつ確認したことで、不足していたルートにたどり着けました。

次に独自ドメインを設定するときは、どの画面で何を設定しているのか、今回より落ち着いて確認できそうです。