Web/Mail Server移行：hostsによる事前検証・SSL化・DNS切り替えで学んだこと

はじめに

2021年当時、前職でWebサイトの移行案件を担当しました。

「何かあってもロールバックできる状態を維持しながら切り替える」という設計を自分なりに調査・実施し、無事に完了できた案件です。当時は「本番のDNSを触る」こと自体が初めてで、かなり慎重に準備しました。特にメール関連は神経を使った部分です。

この記事では、hostsファイルを用いた事前検証、SFTPでのデータ移行、SSL化と記事URLのhttps置換、リダイレクト処理、DNS切り替えといった、現場で実際に行った工夫を順を追ってまとめています。

移行の概要

老朽化したレンタルサーバーで運用していた会社のWordPressサイトを、より安定した環境へ移行する案件でした。移行先・手順設計・実施・事後確認まで担当しました。

移行対象：

旧環境はHTTPのみの運用でしたが、移行を機に 常時SSL化（HTTPS化） も同時に実施することにしました。

Part 1: SFTPでサイトデータを移す

まずはWordPressのサイトデータ（wp-content 配下のテーマ・プラグイン・アップロードファイル）と、MySQLのDBダンプを新環境に持っていく必要がありました。

旧環境はSSHが使えなかったため、SFTPでファイルを吸い出して新環境にアップロードするというシンプルな方法を取りました。

# 旧環境から wp-content 一式をローカルへダウンロード
sftp [email protected]
sftp> get -r /home/oldsite/public_html/wp-content ./wp-content

# 新環境（Xserver）にアップロード
sftp user@sv####.xserver.jp
sftp> put -r ./wp-content /home/newsite/example.com/public_html/

DBは旧環境のphpMyAdminからSQLをエクスポートし、Xserver側のphpMyAdminでインポートしました。画像や添付ファイルが重かったので、SFTPのアップロードはかなり時間がかかった記憶があります。

この時点では 新環境はまだ誰からもアクセスされない状態 なので、落ち着いて作業ができました。

Part 2: hostsファイルで「本番ドメインのまま」事前検証

DNSを切り替える前に、新環境が正しく動くかを「本番と同じドメイン名」で確認したかったため、自分の作業PCの hostsファイル を書き換えて検証しました。

# /etc/hosts (Windowsなら C:\Windows\System32\drivers\etc\hosts)
[XserverのIPアドレス]  example.com www.example.com

こうすることで、自分のPCからだけは example.com が新サーバーを向くようになり、本番URLそのままでリンク切れ・プラグイン動作・画像表示をテストできます。

WordPressはサイトURLに依存する挙動が多く、IPアドレス直打ちや仮ドメインでの検証だとリンクや内部参照がズレてしまうため、hostsによる「本番ドメインのまま検証」は地味ですが非常に効いた工程でした。この事前検証のおかげで、切り替え当日のトラブルを最小限に抑えられました。

Part 3: SSL化と記事URLの http:// → https:// 置換

新環境ではXserverの無料SSL（Let's Encrypt）を有効化し、常時HTTPSで運用する構成にしました。

ところが、ここでひとつ落とし穴がありました。旧環境はHTTPで運用していたため、WordPressのDBには http://example.com/... というURLが大量に残っている 状態だったのです。

• 記事本文内に埋め込まれた画像タグ（<img src="http://...">）
• 内部リンク（<a href="http://...">）
• ウィジェット・オプションテーブルに保存されたサイトURL

このまま放置すると、HTTPSページの中にHTTPリソースが混在して Mixed Content警告 が出てしまいます。そこで、DB内のURLを一括で https:// に置換する作業を行いました。

Search-Replace-DB でシリアライズ対応の置換

WordPressはオプションなどに PHPのシリアライズされたデータ を格納しているため、単純な UPDATE 文で置換すると文字列長がズレてデータが壊れる可能性があります。そのため、シリアライズに対応した Search-Replace-DB を使いました。

検索: http://example.com
置換: https://example.com

念のため事前にDBのバックアップを取ってから実行し、置換後は以下を確認しました。

• トップページ・投稿ページを開いて鍵マークが出るか
• ブラウザの開発者ツールで Mixed Content 警告が消えているか
• wp_options の siteurl / home が https:// になっているか

.htaccess で http:// → https:// へリダイレクト

DB側のURLを https に揃えたうえで、外部から来る古いHTTPリンク対策として .htaccess で常時HTTPSリダイレクト を仕込みました。

# .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# http → https への301リダイレクト
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# WordPress 標準のルール
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

301（恒久的リダイレクト） を選んだのは、検索エンジンに「このサイトは https が正です」と伝えるためです。302にしてしまうとSEO評価が旧URLに残り続ける可能性があるので、ここは301一択でした。

hostsファイルで example.com を新環境に向けた状態で、http://example.com/old-article にアクセスすると https://example.com/old-article に301で飛ぶことを確認できてはじめて、SSL化の工程はひと段落です。

Part 4: DNS切り替えで一番大事だったこと — TTLの事前短縮

ここまでで新環境は本番ドメインでの動作確認・HTTPS化・リダイレクトまで完了しています。いよいよDNS切り替えですが、ここで一番重要だと理解したのが TTL（Time To Live）の事前短縮 でした。

DNSのレコードにはTTLという「このキャッシュを何秒間保持するか」という値が設定されています。デフォルトでは3600秒（1時間）や86400秒（24時間）に設定されていることが多く、切り替え直後でも世界中のDNSキャッシュには古いIPアドレスが残り続けます。

TTL を短縮しなかった場合:
  DNS切り替え後も最大 TTL 分（1〜24時間）は
  古いサーバーにアクセスされ続ける
  → 旧環境を早めに停止すると一部ユーザーがアクセス不能になる

TTL を事前に短縮した場合（今回の対応）:
  切り替えの24時間前に TTL を 3600秒 → 300秒（5分）に変更
  → 切り替え後、最大5分で全リゾルバに新しいIPが伝播する
  → ロールバックも5分以内で効く

なぜ24時間前に変更するのか： TTLを300秒に変更しても、すでにキャッシュしている値は元のTTL（3600秒）が切れるまで使われ続けます。変更が全体に行き渡るまでの安全マージンとして24時間前に実施しました。

切り替え当日の確認コマンド

# TTLが300秒に反映されているか確認
dig A example.com
# → example.com. 300 IN A xxx.xxx.xxx.xxx
#                ↑ ここが300になっていることを確認

# 切り替え後、Xserver側のIPに変わっているか確認
dig A example.com @8.8.8.8 +short   # Google DNS
dig A example.com @1.1.1.1 +short   # Cloudflare DNS

# HTTPS疎通 & 301リダイレクト確認
curl -I https://example.com
# → HTTP/2 200

curl -I http://example.com
# → HTTP/1.1 301 Moved Permanently
#    Location: https://example.com/

Part 5: メール — 一番神経を使った部分

メールの移行は、Webの切り替えより慎重に進めました。メールは「届かない」と気づきにくい からです。Webサイトなら画面が壊れればすぐわかりますが、メールは静かに消えます。

やったこと

1. MXレコードの切り替えタイミングを意図的にWebより遅らせた

WebサイトのDNS切り替えが安定してから、数時間後にMXレコードを切り替えました。全部を同時にやると、問題が起きたときにどこが原因か切り分けにくいためです。

2. 切り替え前後で実際にメールを送受信して確認した

確認した内容:
  ✅ 社外のGmailアドレスから自社ドメイン宛に送信 → 受信確認
  ✅ 自社ドメインから社外のGmailアドレスに送信 → 受信確認
  ✅ 送信メールのヘッダーを確認（SPFがPASSになっているか）
  ✅ 問い合わせフォームからの送信テスト（HTTPS経由）

3. 旧サーバーのメールを並走期間中も受信できる状態にしておいた

MXレコードのTTLも事前に300秒に短縮し、切り替え後も旧環境のメールサーバーへのアクセスが来ていないか24時間監視しました。

SPF設定

メール送信の信頼性を高めるためにSPFも設定しました。

SPF（送信元IPの認可）:
  v=spf1 +a +mx include:spf.sender.xserver.jp ~all
  → Xserverのサーバーからの送信を正当と認める

並走期間の設計

移行で「ゼロダウンタイム」を実現するための核心は、新旧両環境を同時に動かす期間を設けること です。

フェーズ1: 新環境構築（旧環境はそのまま）
  → SFTPでデータ移行 → SSL化 → URL置換 → リダイレクト設定
  → hostsファイルで本番ドメインのまま動作確認
  → 旧環境には一切触れない

フェーズ2: TTL短縮（切り替えの24時間前）
  → DNS TTLを 3600秒 → 300秒に変更

フェーズ3: DNS切り替え（本番）
  → ネームサーバーをXserverに変更
  → 5分で伝播完了

フェーズ4: 並走期間（24〜48時間）
  → 旧環境はそのまま起動状態を維持
  → 新環境の動作・メール送受信を監視
  → 問題があればDNSを旧IPに戻すだけでロールバック可能

フェーズ5: 旧環境停止
  → 全リゾルバが新環境を向いていることを確認後
  → 旧サーバーのデータをバックアップして停止

ロールバック計画

「問題が起きたときどうするか」を事前に書き出しておきました。

並走期間中に旧環境を生かしておくことで、どの問題が起きても DNS操作だけでロールバックできる 状態を維持できました。

振り返り：やってよかったこと・次回への教訓

やってよかったこと：

• hostsファイルで本番ドメインのまま事前検証したことで、切り替え当日に「URLが違うから出るトラブル」が一切なかった
• SFTP → DB置換 → リダイレクト、の順番を守ったことで、SSL化の作業が事故なく進んだ
• .htaccess で301リダイレクトを先に仕込んでおいたので、DNS切替後にHTTPで来たユーザーも自動的にHTTPSへ誘導できた
• TTLを24時間前に短縮したことで、切り替え後の不安な時間が5分に収まった
• メールの切り替えをWebより遅らせて、問題の切り分けをしやすくした
• 並走期間を48時間設けて、旧環境を保険として残しておいた

次回への教訓：

• 切り替え手順書は事前に細かく書いておく（焦るとコマンドを間違える）
• DB置換の前には必ずエクスポートでバックアップを取る（シリアライズ破損の保険）
• メールの到達確認は複数の宛先（Gmail・会社メール・スマホ）で行う
• DNSの伝播状況は dnschecker.org で視覚的に確認できる

まとめ

私立高校常駐SEとしての経験の中で、この移行案件は最も手応えのあった仕事のひとつです。特に hostsでの事前検証 → SFTP移行 → SSL化と記事URLの置換 → リダイレクト → DNS切り替え という順序で進めたことが、事故のない移行につながったと感じています。

「止めない移行」の本質は、切り替えを一瞬で完了させるのではなく、ゆっくり安全に移行できる状態を丁寧に作ること だと思います。hostsによる事前検証、URL置換とリダイレクトの仕込み、TTLの短縮、並走設計、ロールバック計画 — これらのシンプルな準備の積み重ねが、それを実現してくれました。