Webサイトのお助け隊

ネームサーバーを切り替えた日、サイトは新しいサーバーできちんと表示されました。ところが数日たってから、取引先に「先週お送りしたメールの件ですが」と言われる。相手の送信済みトレイには残っているのに、こちらの受信箱には何も来ていない。サーバー移行の事故で一番多いのがこれです。Webの表示は目で見て確認できるので誰でも気づきますが、メールは「届かなかったこと」自体が見えません。気づくのはたいてい数日後で、その間に消えたメールは戻ってきません。原因は技術の難しさよりも、切り替える順番と、着手前に確認しておく項目の抜けにあります。移行の現場で実際に起きたことをもとに、どこで落ちるのかと、落とさない順序を整理します。

サイトは見えているのに、メールだけが消える

ネームサーバーの変更は、感覚としては「サイトの置き場所を変える操作」ですが、実際に起きているのはもっと広い範囲の入れ替えです。レジストラでネームサーバーを書き換えると、そのドメインの権威DNSがまるごと新しい側に移ります。移るのはWebの向き先を決めるAレコードだけではありません。メールの配送先を決めるMXレコード、送信ドメイン認証を書いたTXTレコード、サブドメインのCNAMEも、すべて新しいDNSが持っているゾーン情報に置き換わります。

そして新しいサーバーの初期ゾーンは、たいてい自分自身をメールの受け取り先として指しています。移行先でメールアカウントを1件も作らないままネームサーバーを切ると、そのドメイン宛のメールは、該当するメールボックスが存在しないサーバーに向かって配送されます。旧サーバーのメールボックスは無傷で残っていますが、そこにはもう誰も届けてくれません。

やっかいなのは、この切り替わりが世界中で一斉に起きるわけではないことです。送信元のメールサーバーが新旧どちらを見るかは、そのサーバーが持っているDNSキャッシュの状態で決まります。切替から数十時間のあいだ、あるメールは新サーバーへ、別のメールは旧サーバーへ入る、という状態になります。移行の相談で「新旧どちらのボックスにも届いています」と言われることがありますが、これは異常ではなく、伝播の途中に必ず通る過程です。

依頼者への案内としては、ネームサーバー変更後の48時間はメールが新旧どちらのサーバーに保存されるか確定しない、と伝えています。数字を先に出しておくと、「まだ見えない」「まだ届かない」という問い合わせが目に見えて減ります。逆に「すぐ切り替わります」と言ってしまうと、伝播の途中で必ず来る不安の連絡に、毎回ゼロから説明することになります。

ポート995を疑う前に、DNSを見る

「新しいサーバーのメール設定を入れたのに受信できない」という連絡は、切替当日にほぼ必ず来ます。メールソフトには、POP3の995番やSMTPの587番でタイムアウトした、という趣旨のエラーが出ています。ここで設定値の打ち間違いを疑って総当たりを始めると、時間だけが溶けます。MXレコードがまだ新サーバーを向いていない段階では、新サーバーで受信できないのは正しい挙動です。不具合ではありません。

先に見るのはDNSです。WindowsのコマンドプロンプトかLinuxのシェルで、いまそのドメインがどこを向いているかを直接確認します。

<code>nslookup -type=ns 対象ドメイン 任意のDNSサーバー
nslookup -type=mx 対象ドメイン 任意のDNSサーバー

dig 対象ドメイン ns
dig 対象ドメイン mx</code>

レンタルサーバーにSSHで入れるなら、そこから dig を叩いたほうが手元の環境のキャッシュに邪魔されません。「サイトが見えない」という相談を受けたときも、まず whois でネームサーバー、dig でMXを確認するのが一番速い切り分けです。ここを飛ばしてサーバーの中を探し始めると、原因がDNSにあった場合に何時間でも空振りします。

もうひとつ、切替直後は回線によって見え方が変わります。PCは自分自身とプロバイダのDNSキャッシュを経由するため反映が遅く、スマートフォンのモバイル回線は早い傾向があります。切替の確認は、スマートフォンのWi-Fiを切ってモバイル回線で行うと状況がつかみやすくなります。逆に、モバイル回線では見えるのにPCとWi-Fiでは見えない状態が長く続く場合、原因は手元のルーターやプロバイダのキャッシュで、サーバー側からは手が出せません。ここを切り分けずに調査を続けても終わりません。

証明書の発行可否も判定材料になります。Let’s Encryptはドメイン認証で発行するため、DNSが新サーバーを向いていなければ申請が通りません。2〜3時間おきに申請してみて、通った時点が浸透の目安になります。

実際に落ちた三つのパターン

「メールは使っていません」を信じてしまった移管

静的HTMLで作られた会社サイトを、ドメインの移管とセットで別のサーバーへ移した案件です。着手前のヒアリングで「特に必要なメールアドレスはありません」という回答をもらい、メールの設定を飛ばしてネームサーバーを変更しました。切替後、メールが届かないという連絡が入りました。実際には使っているアドレスがあり、依頼者は「メール設定」という言葉が何を指すのかを正確には把握していなかった、というだけのことです。

対処として、旧サーバーの管理画面でメールアカウントの一覧を直接確認し、新サーバー側に同じアドレスを作り直して設定情報を渡しました。同じ移行では、トップページ以外の全ページが文字化けする症状も出ています。旧サーバーと新サーバーでデフォルトの文字コード設定が違うことが原因で、.htaccess の AddDefaultCharset と各HTMLの meta charset を突き合わせて揃えました。トップだけ正常でほかが化けるのは、トップにだけ meta charset が書かれていた、という典型パターンです。さらに、渡したメール設定情報のSMTPサーバー名を依頼者が手で打ち直した際に綴りを1文字落としており、それだけで送信できない状態になっていました。設定情報は必ずコピーして貼り付けてもらうよう明記しています。

最終的にメールの送受信は戻り、全ページの文字化けの修正と常時SSL化まで含めて完了しましたが、ドメイン移管の待ち時間とDNS反映、切替後の手直しが重なって、当初の予定より6日ずれ込みました。ここから引き出せる予防策は単純で、「メールは使っていますか」と聞かないことです。「いま使っているアドレスを全部挙げてください」「名刺やサイトに載せているアドレスはありますか」と具体的に聞き、可能なら旧サーバーのアカウント一覧をこちらで直接確認します。

ゾーン編集ができない管理画面だった

制作会社を経由した企業サイトの移行です。ダウンタイムを出さない手順を取るつもりでドメイン管理画面を開いたところ、できるのはネームサーバーの変更だけで、AレコードやMXレコードのゾーン編集ができませんでした。そのDNSサービスでは、ゾーン編集機能が別申し込みになっていたためです。

この構成では、Webとメールの切替タイミングを手元で決められません。ネームサーバーを変えた瞬間から、どちらのサーバーに配送されるかはDNSホストの反映速度任せになります。しかもそのDNSホストは自社DNSへの反映自体が遅く、数日を見込む必要がありました。できないことを黙って進めるとあとで揉めるので、「切替のタイミングは選べません。反映まで数日かかる可能性があります」と先に伝えて合意を取ってから着手しています。

そのうえでメール側の取りこぼしを減らすため、新旧両方のメールアカウントをメールソフトに並行して登録してもらい、浸透が終わってから旧側を削除する形にしました。旧側のメールパスワードは開示されなかったので、新サーバー側には任意のパスワードを新規に設定し、あとで本人に変更してもらう運用にしています。旧サーバーのパスワードをそのまま引き継げないことは珍しくないので、依頼者側でメールソフトの再設定作業が発生する前提でスケジュールを組みます。

この案件で明確になったのが、テストメールの送り方です。同じサーバーの中から自分宛に送っても検証になりません。サーバーは自分の中にそのドメインのメールボックスがあると判断すると、DNSを見ずに内部で配送してしまうためです。必ず別のサーバー、別のプロバイダのアドレスから独自ドメイン宛に送り、新旧どちらのボックスに落ちるかを見ます。「両方に届く」という報告の多くは、この確認方法の違いから生まれています。

ネームサーバーが別のサービスを向いていた

「WordPressの管理画面にログインしようとすると、まったく別のサービスのログイン画面に飛ばされる」という相談から始まった移行です。調べると Jetpack が有効で WordPress.com のアカウント連携が入っており、依頼者は連携先のログイン画面を自分のサイトの管理画面だと思い込んでいました。/wp-login.php を直接開けば、自分のサイトのログイン画面が出ます。

本当の問題はDNS側にありました。ネームサーバーが依頼者の意図しない先を向いており、Web表示だけでなくMXレコードまで巻き込まれていたのです。whois でネームサーバー、dig でMXを確認したところ、依頼者が使っているつもりのサーバーとは別のところを指していました。この状態は、非技術者が管理画面から自己流で設定を触った結果として珍しくありません。

対処の進め方はシンプルで、現状を正確に把握したうえで「最終的にどのサーバーで運用したいか」だけを決めてもらい、そこから逆算しました。作業前に「およそ1時間、サイトが正常に表示されない時間があります」と告知してから着手し、実際に1時間ほどで切替まで終えています。停止時間を先に伝えておけば、途中の不安定な状態がクレームになりません。SSLはDNSが新サーバーを向いたことを確認してから取得しました。結果として、管理画面の入口が自分のサイトに戻り、メールの配送先も想定どおりになっています。

落とさない順番はどう組むか

分岐点はひとつだけです。いま使っているDNSでゾーン編集ができるかどうか。ここで手順が変わります。

ゾーン編集ができるなら、ネームサーバーの変更を最後に回します。

1. 新サーバーにドメインを追加し、サイトのデータを配置する。メールアカウントもこの時点で全部作っておく
2. いま使っているDNSのAレコードを、新サーバーのIPアドレスに向ける。ネームサーバーはまだ触らない
3. 新サーバーで表示を確認する。トップだけでなく下層ページ、フォーム、会員ページまで踏む
4. 問題がなければMXレコードを新サーバーに向ける。ここでメールの切替タイミングを自分の手で決められる
5. 仕上げにネームサーバーを新しいDNSへ変更する

この順番なら、ネームサーバーを変える時点で、外から見えているのはすでに新サーバーです。切替の瞬間に落ちるものがありません。サイトが表示されなくなったり古いほうのサーバーが使われたりすることなく、常に新しいサーバーのデータを利用させられます。ゾーン編集ができる案件では、必ずこの型を取ります。

ネームサーバー変更しかできない場合は、旧サーバーを消さずに残し、新旧の両方に同じサイトデータが載っている状態を作ります。どちらに解決しても同じサイトが表示されるので、Web側のダウンタイムは出ません。手順としては、移行先にドメインを追加してデータを移し、メールアカウントを作り、移行先のDNS設定を整えてから、レジストラでネームサーバーを変更し、SSLを設定し、Web表示を確認し、締めくくりにメールの着信を確認する、という流れになります。SSLは切替後でないと発行できないため、切替からSSL設定までの短い時間、http:// では見えるが https:// ではまだ見えない、という状態が生まれます。ここも先に説明しておく箇所です。

どちらの型を取るにせよ、着手前に埋めておく項目は共通です。対象ドメインで使っているメールアドレスの一覧とパスワードが分かるか。旧サーバーに未受信のまま残っているメールがないか。ドメイン管理画面でゾーン編集ができるか。旧サーバーのSSL証明書は有効期限と自動更新がどうなっているか。旧サーバーの .htaccess に転送設定が残っていないか。問い合わせフォームやCGIが外部の有料サービスに依存していないか。この最後の項目は見落とされがちで、前の制作会社が作った動的機能はデータだけ譲り受けても動かないことが多く、移行後にフォームだけ止まる、という形で表面化します。

サービス終了に伴う移行のように期限が決まっている場合は、これらの確認と並行して作業日を先に押さえる必要があります。移行元の事情で選べる手順が限られる例はZenlogic終了で迫られたXserver移行、実際の手順とつまずいた箇所にまとめています。自分で進めるか外に出すかを迷っている段階なら、サーバー移行を自分でやるか業者に頼むか、分かれ目になる条件のほうが判断材料になります。

切替後の確認と、旧サーバーを止める時期

切替が終わってからの確認で外せないのが、メールの着信テストです。前述のとおり、別のサーバーから独自ドメイン宛に送って、新サーバーのボックスに落ちることを確認します。それまでは新旧両方のアカウントをメールソフトに登録したままにして、浸透を確認してから旧側を削除します。移転の前に、旧サーバーに残っている未受信メールを受信させておくことも忘れやすい作業です。

旧サーバーの解約は、新サーバー側で受信できたことを確認してからです。Webが見えている状態は、メールが届いている証明にはなりません。ここを一緒くたにして旧サーバーを止めてしまうと、伝播の途中で旧側に配送されたメールが行き場を失います。

Web側では、トップページだけ表示されて下層が Not Found になる症状がよく出ます。これはパーマリンクとリライトルールの問題で、管理画面の設定からパーマリンクを保存し直すだけで解消することがほとんどです。移行後の確認をトップページだけで済ませると、この症状を見逃します。文字化け、リンク切れ、フォームの送信まで含めて全ページを巡回してください。

「まだ見えない」という連絡が来たときに切り分けるべきキャッシュは三層あります。ブラウザのキャッシュ、サーバー側のキャッシュ、そして回線側のキャッシュです。ブラウザのキャッシュをクリアしても直らないと言われたら、次に疑うのはサーバー側のキャッシュで、海外系のホスティングは独自のWordPressキャッシュやサーバーキャッシュを持っていることがあり、これが移転直後の表示不具合の原因になります。それでも回線によって見え方が変わるなら、ルーターやプロバイダのキャッシュです。移行完了の報告には、ブラウザのキャッシュクリアの手順を最初から添えておくと余計なやり取りが減ります。

常時SSL化は「SSLを設定した」で終わりにせず、http:// から https:// への強制リダイレクトまでを1セットで仕上げます。旧サーバーをいつ止めるか、何を確認してから止めるかはサーバー移行が終わった後に確認する項目と、旧サーバーを止める時期で個別に整理しています。移行そのものの進め方はサーバー移行の対応内容にまとめてあります。

よくある質問

切替作業はいつ始めるのがよいですか

反映を待つ時間と、切替後に必ず出る手直しの時間を、同じ日のうちに確保できるかどうかで決めます。週末や連休の直前に切ると、不具合が出たときにそのまま数日放置になります。実際の案件では、翌日以降も確認と手直しができる曜日をこちらから提案し、停止時間の見込みを先に告知してから着手しています。

新旧どちらのメールボックスにも届くのはなぜですか

送信元のメールサーバーが、新旧どちらのMXレコードを見ているかで配送先が分かれるためです。伝播が終われば片方に収束します。この期間に取りこぼさないよう、新旧両方のアカウントをメールソフトに登録しておき、浸透を確認してから旧側を削除します。なお、同じサーバーの中から送ったテストメールはDNSを見ずに内部配送されるため、検証には使えません。

SSL証明書を移行前に用意しておけませんか

Let’s Encryptのようにドメイン認証で発行する証明書は、DNSが新サーバーを向いてからでないと発行できません。ネームサーバー変更、伝播の確認、証明書取得、という順序になります。伝播の途中で申請すると認証に失敗し、ドメイン管理者宛に失敗通知のメールが届きます。事前に「認証失敗の通知が届くことがありますが想定内です」と伝えておくと驚かせずに済みます。

移行してから検索結果に出なくなりました。移行が原因ですか

時期が重なっているだけで即断はできません。移行中のメンテナンス表示が影響することもありますが、後日あらためて調べたところ、Search Consoleの手動対策が真因だった案件もあります。移行のせいだと決めつける前に、手動対策レポートとインデックスの状況を確認してください。