先日、ConoHa WINGから、さくらインターネットのレンタルサーバへ引っ越ししました。
ConoHa WINGを使う前、元々さくらインターネットは使用していました。要は出戻りですね。
前回、さくらインターネットからConoHa WINGに移行したのは、契約していた当時のさくらインターネットのレンタルサーバが、CGI版PHPしか対応していなく、WordPressも少々重かったからが理由です。
また、さくらのレンタルサーバは、2016年から契約していて、モジュール版PHPが対応したのは2018年。
使用する場合は、新規に契約をし直さないといけないことや、再契約時の初期費用や初期ドメインが変わるということもあり、ConoHa WINGに移行した。という過去があります。(コンパネも現代的で良かった)
その備忘録も兼ねて記事を起こします。
レンタルサーバ引っ越し理由
コントロールパネルの不安定さ
ConoHa WINGに移行したての頃は、あまり知名度がなかったため、コントロールパネルも軽く、また、サーバ自体も混雑していなかったので、大変満足はしていました。
ですが、今現在コントロールパネルを触ると、とにかく不安定。ぐるぐる回って読み込みに時間がかかるのはしょっちゅう。
さくらのレンタルサーバの無料体験期間で、様々なことを見ていくとこれでええやん！ということに。
Cloudflareとの相性が悪い
弊サイトのドメインとDNSサーバは、Cloudflareを使用しており、DNSサーバ自体は問題なく使用できますが、プロキシ機能がどうしても相性が悪かった。
理由は、オリジン(レンタルサーバ)⇔Cloudflareの証明書の認証問題です。
ConoHa WINGでは、証明書にLet’s encryptとAlphaSSLが使用できます。
ですが、証明書発行時にはプロキシ設定を外さないと、証明書の発行ができないという問題がありました。
これは、CDNを使用する場合、結構あるあるらしく、証明書の発行の時点で、オリジンと直接通信がしなければ発行ができず、証明書が発行できないという感じです。プロキシしてる時はCloudflareにアクセスしてるしね。
証明書の更新をする際も同様で、その際にプロキシを外さないといけませんので、そんな高頻度にプロキシ外すのはめんどくさいですよね。
また、Cloudflareをもう少し勉強がてら使用したいということもあり。
値段が高い割にそんなに性能要らなかった。
ConoHa WINGは月額1,400円ちょっと払っていましたが、私のブログは月間PVが4,000にも満たない弱小ブログなので、対して、ConoHa WINGほどの高性能なレンタルサーバが要らなかった。
適当に気軽に記事を書いてるだけなので、そんなスペック要らんやんけという感じ。
まぁ、急激にPV伸びたらCloudflareくん頑張って！という感じで任せればいいや〜って感じ。
さくらのレンタルサーバがDKIM対応した
ConoHa WINGに移行した時には、さくらのレンタルサーバはDKIMには対応していませんでした。
ConoHa WINGは契約時にDKIMを自動的に設定してくれてラッキー。といった感じでセキュリティが担保できていた。
2023年にGoogleは、SPF、DKIM、DMARCにしないと2024年から迷惑メールにするからな(要約)というガイドラインを出し、レンタルサーバ各所は対応に追われたのが記憶に新しいところです。
2024年1月末にようやく、さくらインターネットがDKIMに対応して、メールのセキュリティも担保できるということもあり、出戻りできるなということもあり。
これは余談なんですけど、実は2018年からDKIM対応は要望にも出されてて、ずっと放置されていたんですけどね…笑
まぁセキュリティ対策は費用対効果的にも後回しにされがちなため、しょうがない部分もあります。
主に4つの理由で移行を決意いたしました。
移行の手順
移行には主に以下のことをやります。
- さくらインターネットと契約し、レンタルサーバの設定
- 移行の24〜36時間前にはTTLを最小限に設定
- 移行元WordPressでプラグインを入れのデータを吸い出す
- DNSレコード切り替え
- 移行先WordPressでプラグインを入れデータをリストア
こういった感じのことを行います。
移行にあたり、以下の記事を参考にしました。大変助かりました。
さくらインターネットとの契約
まずは、さくらインターネットと契約しないといけません。
詳細は割愛しますが、とりあえず契約してレンタルサーバのコントロールパネルとアクセスできるようにしておきましょう。
また、サーバ情報はDNSを移行する際に必要なので控えておきましょう。
DNSサーバのTTLを短くする
スムーズに移行できるよう、移行の24時間前ぐらいにはTTL(Time To Live)を60秒に設定しておきましょう。設定できない場合はデフォルトで3600秒(1時間)と設定されています。その場合は、ルータやPCのDNSのキャッシュをすべてリセットするか、または、プロバイダのDNSサーバが1時間キャッシュしている可能性があるので、その時は待ちしましょう。
巷では、よく「DNSの浸透を待ちましょう！」「DNSの反映を待ってください」など言われますが、これは誤解であり、DNSは浸透しません。
DNSサーバから得た情報はキャッシュされている
DNSは覚えにくいIPアドレスをドメインネームと紐づけるものです。
ですので、このドメインネームはどこのIPアドレス？とPCやブラウザが要求を出しDNSサーバが登録されているIPアドレスを応答します。これをルータ内部のDNSサーバもしくはPCやブラウザにTTLの指定した時間キャッシュしているだけに過ぎないのです。
また、TTLは3600秒がデフォルトで設定されている事が多く、反映しないな…。浸透しないな…。とかよく勘違いされてしまいます。ですが、移行時にはTTLをできる限り短くしておき、移行が完了したら戻す。ということを適切に行えばそんな日本語が出てこないはずなのです。
たまに、TTLがデフォルトから変更できない変なDNSサーバがあったり、TTLをガン無視しずっとキャッシュし続けているお行儀の悪いDNSサーバもあったりして、浸透待ちや反映待ちと言いたくなる気持ちもわからなくもないですが、サービス事業者がしっかり説明していないことも責任の一つだと私は考えています。
DNS界隈では、DNS浸透いうなと言われております。
詳しくは以下の記事が参考になります。正しい知識をつけて運用していきましょう。
さくらのレンタルサーバとCloudflareの設定
DNS周りで話が逸れましたが、戻します。
さくらのレンタルサーバでサーバの設定をします。
さくらのレンタルサーバにドメインを追加
１．ドメイン/SSL→ドメイン/SSLに行き、ドメイン追加→新規追加で、他社で取得したドメインを移管せずに使うで追加をクリック。
２．ドメインを入力し、追加をクリック。
３．ドメイン/SSLのドメイン一覧に追加したドメインが追加されました。
SSL証明書の設定(Cloudflareのオリジン証明書を使用)
さくらのレンタルサーバとCloudflareのプロキシ機能を使用した構成のため、証明書にCloudflareのオリジン証明書を使用します。
オリジン(レンタルサーバ)⇔Cloudflare間では、Cloudflareとちゃんと通信できればいいので、Let’s encryptを使用する必要はなく、オリジン証明書をCloudflareで発行し、さくらのレンタルサーバにインストールすれば利用可能です。
まぁ実質的にオレオレ証明書的な感じで通信を行う形にはなりますが、SSL/TLS通信は担保されるので、これはこれでOKです。
１．ドメイン/SSLで追加したドメインの設定をクリックし、SSL設定を選択し、SSL証明書の種類を選択をクリックし、独自SSLを選択
３．秘密鍵の登録をクリックし秘密鍵を生成をクリックし、秘密鍵を作成。
４．秘密鍵を生成したらCloudflareで証明書を作成してもらうためのCSRの作成を行います。
５．CSRでのコモンネームをワイルドカードに設定しておくと、同一ドメインでは秘密鍵とオリジン証明書を流用することができるようになります。また、都道府県等は適当でOKです。
６．CSRが発行されたら内容をコピーしCloudflareの設定へ移ります。
７．Cloudflareへログインし、SSL/TLS→オリジンサーバーへ行き、オリジン証明書を作成をクリック。
６．自分のプライベートキーとCSRを使用するにチェックを入れ、先程作成したCSRを貼り付け。サブドメインも同じオリジン証明書を利用したいので、ワイルドカードのホスト名も入れておく。(デフォルトのままでOK)有効期限は15年でいいと思います。
８．オリジン証明書が出来上がるので、内容をコピー。
９．さくらインターネットの管理画面へ戻り、証明書の証明書インストールを選択し、先程のオリジン証明書の内容を貼り付け。
１０．このままだと、証明書は使用できないため、中間証明書をインストールします。中間証明書は下記のリンク先のCloudflare Origin RSA PEMをダウンロードしテキストエディタで開き、内容をコピペ。
https://developers.cloudflare.com/ssl/origin-configuration/origin-ca
１１．無事にSSL証明書が表示され、エラーが無くなったらOKです。
１２．最後にドメイン設定で、SSLを利用するにチェックを入れ完了です。HTTPSの転送はWordPressのクイックインストールすると自動的にHTTPSに飛ぶのであまり気にしなくて大丈夫かと思います。
サブドメインも同じオリジン証明書を使用したい場合
サブドメインも同様のオリジン証明書を使用したい場合、前述で作成した秘密鍵をダウンロードし、設定したいサブドメインのSSL設定で秘密鍵のアップロードが行えるので、秘密鍵の流用を行えば同じオリジン証明書の利用が可能です。
あとは同様に中間証明書とオリジン証明書をインストールして完了です。
移行元WordPressのデータをプラグインで吸い出し
移行元WordPressでデータ移行の準備を行います。
引っ越しはWPvivid Backup Pluginを使用します。
データベース＋ファイル（WordPress ファイル）を選択し、バックアップをローカルに保存するバックアップ感じで行います。
完了したらファイルが何個かに分割されているのでこれをダウンロードします。
さくらのレンタルサーバでWordPressをインストール
さくらのレンタルサーバでWordPressをクイックインストールでインストールしデータベースも合わせて作成します。
なお、ここで入れたWordPressのユーザ名とパスワードはプラグインでリストアした際にすべて上書きされます。
また、WordPressをインストールまではDNSを切り替えることなくできます。
この時、PHP.iniの容量を増やしておくといいと思います。
post_max_size = 1000M
upload_max_filesize = 2000MDNSの切り替え
移行まで準備ができたらDNSの切り替えを行います。
Cloudflareで控えたIPアドレスをAレコード、AAAAレコードに入力しプロキシにチェックを入れ保存をします。
これで、数分待つとすぐに切り替わります。切り替わらなかったらブラウザを再起動しましょう。
※IPv6はデフォルトで利用しない設定になってるため、さくらのレンタルサーバドメイン設定であれかじめ有効にしておく必要があります。こちらはここの判断で。(AAAAレコードを入れなくてもIPv6が有効であればIPv6でプロキシが行われるため)
プロキシにチェックを入れないと、オリジン証明書が登場し証明書エラーが出ます。
移行先WordPressにデータをリストア
データをリストアします。WPvivid Backup Pluginを移行先WordPressにインストールしリストア。
また、クイックインストールでインストールされたプラグインは生き残りますので、いらなければ削除しましょう。
後は、Cloudflareのプラグインを入れると、記事更新した後に自動的にパージしてくれます。
リストアで問題がおきた点
ページインデックスのパーマリンクが404 Not Foundになった
記事一覧にて2ページ目以降が、404エラーが吐き出されてしまいました。
どうやら原因はパーマリンクの設定がうまいこと移行できていなかったぽく、一度デフォルトに戻して再度使用しているパーマリンクの様式に戻したら直りました。
コンタクトフォームが機能しなくなった
移行した途端Contact Form7のフォームが機能しなくなりました。
これは、コンタクトフォーム自体をキャッシュしているから発生している現象で
Cloudflareのページルールにフォームを設置しているディレクトリのキャッシュをバイパスするようにルールを設定し解消。
Adsense広告の挙動がイマイチ
当ブログAdsense広告を配置しているんですが、Cloudflareを通してから広告が表示されたりされなかったりでなんかいまいち挙動が安定していません。
まぁ、趣味ブログですので正直収益性はあまり気にしてはいませんが、挙動がおかしいのは改善したいところですね。
2025年2月13日追記：Adsenseの広告の設定が間違っていました。インフィード広告をなぜかディスプレイ広告として利用していたことが原因でした。
WAFを使用するとERR_TOO_MANY_REDIRECTSとエラーを吐く
さくらインターネットの設定でWAFを有効化すると、ERR_TOO_MANY_REDIRECTSというエラーが発生し、HTTPSリダイレクトでループする現象があり、解消すべく調べてみると以下の記事が見つかりました。
さくらのレンタルサーバの443番ポートは80番ポートへの単なるプロキシでした…
調べた所、わかりづらく記載されていました。
- クライアントがCloudFlare(https)に対して要求を送信する
- CloudFlare(https)がさくらのレンタルサーバ(https)に対して要求を送信する
- さくらのレンタルサーバ(https)の443番ポートは80番ポートへのプロキシなので名前解決を行う
- 名前解決した結果、当然CloudFlareのIPアドレスが返ってくるので、そのアドレスを使用し接続を試みる
- CloudFlare(https)はさくらのレンタルサーバ(https)へ接続を試みてコンテンツを取得する
- 2番に戻り無限ループ。 CloudFlareは下記の様なエラーを吐く
どうやらさくらのレンタルサーバの仕様がこのような感じなので、ループをした。という形になります。
対策としては、Cloudflare側のHTTPSリダイレクト設定を無効化し、解消しました。
さくらのレンタルサーバ側は、HTTPSリダイレクトをオンの設定でも問題はありませんでしたので、この運用で行きたいと考えています。
まとめ
今回は、ConoHa WINGからさくらのレンタルサーバ＋Cloudflareの構成に移行した手順をお伝えしました。
Cloudflareは無料サービスでかなり充実しているので、なんでこんな機能が無料なんだって思うほどです。
CDN周り勉強が必要ですが、私も勉強の一環で導入しているのでみなさんもCloudflareトライしてみてはいかがでしょうか。
コメント