Cloudflare Pagesで公開しているサイトに独自ドメインを設定した。
example.com 自体はすでに表示できている。
次にやりたかったのが、
www.example.com ↓ 301example.comという、よくあるwwwなしへの統一。
まあCNAMEを追加して、Cloudflareでリダイレクト設定すれば終わるやろ。
と思っていた。
終わらなかった。
ちなみに、解決方法や確認ポイントだけサクッと見たい場合は、HowTo版にまとめている。
→ Cloudflare Pagesでwww→apexへリダイレクトする設定方法
設定手順だけ抜き出してまとめているので、「Wi-Fiが犯人とかはええねん、設定だけ教えてくれ」という場合はこちらへ。
wwwのカスタムドメインがずっと「検証中」
まずCloudflare Pagesのカスタムドメインに、
www.example.comを追加した。
Cloudflareからは、
名前: wwwターゲット: xxxx.pages.devというCNAMEを追加するように言われる。
DNSを見ると、CNAMEは設定したはず。
ところがPages側はずっと、
検証中から変わらない。
「Proxyが悪いんかな？」
と思って、ProxiedからDNS onlyに変えてみたりもした。
変わらない。
「DNSレコードを確認」も何度か押した。
変わらない。
この辺から、最初は簡単なwww対応だったはずなのに、だんだん雲行きがCloudflare色になってきた。
DNS一覧を見たら、wwwにNSレコードがいた
DNSレコードをwwwで絞り込んでみた。
すると、妙なものが見つかった。
www.example.com NS dns1.onamae...www.example.com NS dns2.onamae...wwwにNSレコードが2ついる。
今回やりたいのは、
www.example.com ↓Cloudflare Pagesなので、ここに昔のお名前.com向けのNSがいるのはどう考えても気になる。
この2つを削除。
そのうえで改めて、
Type: CNAMEName: wwwTarget: xxxx.pages.devを設定した。
すると、
PagesのカスタムドメインがActiveになった。
よし。
終わった。
と思った。
終わってなかった。
今度はERR_QUIC_PROTOCOL_ERROR
www.example.comをChromeで開いてみる。
出たのはサイトではなく、
ERR_QUIC_PROTOCOL_ERRORだった。
さっきまではERR_TIMED_OUTだったので、何かは変わっている。
「Cloudflareまで届くようにはなったんかな？」
と考えた。
PagesはActiveになったばかりなので、SSL証明書やCloudflare Edgeへの反映に時間がかかっている可能性も疑った。
じゃあ別ブラウザならどうか。
Firefoxで開いてみる。
今度は、
SSL_ERROR_RX_RECORD_TOO_LONGだった。
エラーの種類まで変わった。
やめてほしい。
SSL証明書を見る。でもActive
CloudflareのSSL/TLS設定を確認する。
モードは、
FullEdge Certificatesを見ると、
*.example.comexample.comのUniversal SSLが、
Activeになっている。
wwwはワイルドカードの対象なので、証明書がないという感じでもない。
PagesのカスタムドメインもActive。
DNSのwwwも、
www.example.comCNAMExxxx.pages.devProxiedになっている。
だんだん、
設定画面を見る限り全部正常
という、トラブルシューティングで一番嫌な状態になってきた。
nslookupしてみる
まず、
nslookup www.example.comを実行した。
すると、18.x.x.x系のIPが返ってきた。
一方で、
nslookup xxxx.pages.devでは、
172.66.x.x172.66.x.xが返ってきた。
結果が違う。
「wwwが別のところを向いてる？」
と疑った。
Google Public DNSやCloudflare DNSに直接問い合わせても、wwwには同じ18.x.x.x系が返ってきた。
さらに、
nslookup -type=CNAME www.example.comも試した。
結果は、
Can't find www.example.com: No answerただし、wwwはCloudflareでProxiedにしている。
この状態ではCloudflareがCNAMEそのものを外から見せず、A/AAAAとして応答するため、CNAMEが見えないこと自体は異常とは限らない。
また一つ、決定打にならなかった。
リダイレクトが悪い？
そもそもの目的は、
https://www.example.com/*を、
https://example.com/${1}へ301リダイレクトすることだった。
Cloudflareにはすでにそのルールを作っていた。
「もしかして、このルールがおかしい？」
と思い、一旦無効化。
その状態でwww.example.comを開いてみる。
変わらない。
リダイレクト、お前でもないのか。
ルールは元に戻した。
ここでスマホから開いてみた
調査がCloudflareの設定画面をぐるぐる回り始めたところで、スマホからアクセスしてみた。
Wi-Fiを切って、モバイル回線から、
https://www.example.comへアクセス。
普通に開いた。
ん？
これはかなり大きな違和感だった。
Cloudflare側の設定そのものがおかしいなら、PCでもスマホでもダメになりそうなものだ。
ところが、
スマホ + モバイル回線 → OKMac + 自宅Wi-Fi → NGになっている。
そこでMacもスマホのテザリングにつないでみた。
開いた。
さらにスマホを自宅Wi-Fiに戻す。
開かない。
ここまで来ると、疑う場所が変わった。
Cloudflareじゃない。
自宅Wi-Fi側では？
最後に見つかったのはJ:COMのアプリ
使っていたのはJ:COMのWi-Fi。
そのアプリでは、接続している端末ごとの状況を確認できる。
そこで対象端末の状態を見てみると、
今回設定していたドメインが拒否される状態になっていた。
ドメインを拒否しないように設定変更。
そのあとwww.example.comへアクセス。
普通に表示された。
終わった。
DNSでもなかった。
SSLでもなかった。
QUICでもなかった。
IPv4でもIPv6でもなかった。
最後に立っていたのは、Wi-Fi側のフィルタだった。
DNSを触りまくったせいだったのか？
ここは断定できていない。
今回、wwwを有効化する過程で、
- カスタムドメインの追加
- CNAMEの変更
- Proxy設定の変更
- NSレコードの削除
- SSLが安定していない状態でのアクセス
などを短時間に繰り返していた。
そのため、何らかのタイミングでWi-Fi側のセキュリティ機能に引っかかった可能性は考えた。
ただし、
「CloudflareのDNS設定を何度も変更したからJ:COMにブロックされた」ことまでは確認していない。
分かった事実は、
J:COMのWi-Fiアプリ上で対象ドメインが拒否されており、許可したらアクセスできるようになった
ここまで。
原因を綺麗に説明したくなるけど、確認できていないところまで物語を完成させると、また別の沼が始まる。
今なら、もっと早く別ネットワークで試す
今回の調査で一番効いたのは、難しいコマンドではなかった。
スマホのWi-Fiを切ったことだった。
途中では、
nslookup www.example.comを実行したり、
dig A www.example.comdig AAAA www.example.comを見たり、SSL証明書を確認したりした。
もちろん、それぞれ切り分けとして意味はあった。
でも、
自宅Wi-Fi → NGモバイル回線 → OKが分かった瞬間、調査対象がCloudflareから自宅ネットワークへ一気に移った。
今同じ症状に遭遇したら、
- 別ブラウザで試す
- 別端末で試す
- 別ネットワークで試す
をかなり早い段階でやると思う。
特に、
DNSは合っている SSLもActive サービス側もActive なのに自分の環境だけ繋がらない
となったら、ルーターやISP側のセキュリティ機能も候補に入れる。
設定を触った直後ほど、設定を疑いすぎる
今回ハマった理由は分かりやすい。
直前までCloudflareのDNSを触っていた。
だから繋がらなくなれば、
「さっき触ったCloudflareがおかしい」
と思う。
実際、途中には不要なNSレコードも残っていたので、その疑い自体は間違っていなかった。
ただ、それを直してPagesがActiveになったあとも、頭の中ではCloudflareの調査が続いていた。
DNS。
SSL。
QUIC。
IPv6。
リダイレクト。
一通り回ったところで、Wi-Fiを切ったら普通に開いた。
今回のJ:COM側のブロックも、結果だけ見れば、ホテルのフロントが「怪しそうだったので預かっておきました」と荷物を止めていたようなものだった。
守るための仕組みなのは分かる。
ただ、そのことをこっちには特に知らせてくれない。
荷物が届かないので配送業者に問い合わせて、住所を確認して、配送経路まで調べたあと、フロントに聞いてみたら、
「あ、それならこちらで止めてます」
みたいな感じ。
いや、止めるのはええとして、止めてることはどっかで言っといてくれ。
今なら、同じ状態になったらかなり早い段階で別ネットワークを試す。
DNS、SSL、ブラウザ、端末。切り分ける対象はいろいろあるけど、回線そのものを変えるという手も忘れないようにしたい。
ということで今回、一番仕事をしたデバッグツールは、nslookupでもdigでもなくスマホのテザリングだった。