サブドメインを作ったのにページが表示されないとき、原因はDNSだけとは限りません。DNSは正しくても、サーバーの受け付け設定、SSL証明書の発行待ち、WordPressの転送、ブラウザやCDNのキャッシュのどこかで止まっていることがよくあります。この記事では、サブドメインが「反映されない」状態を、DNS → サーバー → SSL → WordPress → キャッシュの順に1つずつ確かめる方法と、それぞれの直し方を説明します。
まず「どこまで届いているか」を確かめる
最初に、ブラウザに何が表示されているかを確認します。表示内容から、止まっている場所の見当がつきます。
- 「サイトにアクセスできません」「サーバーのIPアドレスが見つかりませんでした」 → DNSで止まっている
- サーバー会社の初期ページ、「ファイルが見つかりません」、メインサイトのトップ → サーバーまでは届いているが、サブドメイン用の設定が無いか違う
- 「この接続ではプライバシーが保護されません」 → SSL証明書がまだ無い、または名前が合っていない
- アドレスバーのURLがメインドメインに変わる → WordPressやサーバーが転送している
同じ状態がスマートフォンのモバイル回線（Wi-Fiを切った状態）でも起きるかも見ておくと、自分のパソコンや社内ネットワークだけの問題かどうかが分かります。
1. DNS: 名前が引けているか
ターミナルで次のコマンドを実行します。Windowsなら nslookup sub.example.com でも確認できます。
dig +short sub.example.com
dig +short NS example.com
dig @8.8.8.8 +short sub.example.com1行目でサーバーのIPアドレスが返れば、DNSは機能しています。何も返らないときは、2行目で表示されたネームサーバーのサービスにレコードを登録しているかを確認してください。ドメインを買った会社とサーバー会社の両方にDNSの設定画面がある場合、実際に使われていない方を編集しているケースがよくあります。
返ってくるIPアドレスが、サブドメインを置いたサーバーと違うこともあります。サーバー会社の管理画面に表示されているIPアドレスと比べてください。IPv6のAAAAレコードが古いサーバーを指したまま残っていると、IPv6が使える環境だけ古いサーバーに届くので、dig +short sub.example.com AAAA も確認します。
DNSを変更した直後や、作る前にその名前にアクセスしていた場合は、古い結果がキャッシュに残っていることがあります。ネームサーバーに直接問い合わせて正しく返るなら、設定は正しいので時間を置いてください。
2. hostsファイルが邪魔していないか
以前にテストのためhostsファイル（Windowsは C:\Windows\System32\drivers\etc\hosts、macOSやLinuxは /etc/hosts）にサブドメインを書いたまま忘れていると、DNSを直しても自分のパソコンだけ古い向き先に行き続けます。dig はhostsファイルを見ないため、「digでは正しいのにブラウザでは違う」ときは、hostsファイルを開いて確認してください。
3. サーバー: サブドメインを受け付けているか
DNSが正しくても、サーバー側にそのサブドメインの設定が無いと、初期ページやメインサイトが表示されます。Webサーバーは届いたリクエストのホスト名を見て、どのフォルダーのサイトを返すかを決めているためです。
レンタルサーバーの場合: 多くのサーバーでは、DNSとは別に、管理画面でサブドメインを追加する作業が必要です。ドメインのDNSを外部サービスで管理している場合は、サーバーの管理画面でサブドメインを追加したうえで、外部のDNSにもレコードを作る必要があります。サーバー側の設定が反映されるまで少し時間がかかることもあります。
公開フォルダーの確認: サブドメインごとに公開フォルダー（ドキュメントルート）が割り当てられます。ファイルを別のフォルダーに置いていると「ファイルが見つかりません」になります。管理画面で設定されているフォルダーに index.html などのテスト用ファイルを置き、表示されるかを確かめると切り分けが早くなります。
VPSの場合: NginxならそのサブドメインのWebサイト設定（server ブロック）に server_name sub.example.com; があるか、Apacheなら VirtualHost の ServerName か ServerAlias に含まれているかを確認します。設定を変えたら、nginx -t や apachectl configtest で文法を確認してから再読み込みします。
DNSと切り離してサーバーだけを試すには、curl の --resolve で名前とIPアドレスを指定します。
curl -sI --resolve sub.example.com:80:203.0.113.10 http://sub.example.com/これで正しいページが返るなら、サーバー側は準備できていて、残りはDNSの問題です。
4. SSL: 証明書が発行されているか
HTTPでは開けるのにHTTPSで警告が出る場合は、証明書の問題です。
- レンタルサーバーの無料SSLは、サブドメインを追加した後に別の操作で有効にする必要があったり、有効化から利用できるまで時間がかかったりします。管理画面で状態を確認してください。
- 無料SSLの発行は、DNSがそのサーバーを向いていないと失敗します。DNSを直す前に申し込んで失敗している場合は、DNSが正しくなってから申し込み直します。
- VPSなら、証明書にサブドメインが含まれているかを確認します。
echo | openssl s_client -connect sub.example.com:443 -servername sub.example.com 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName表示された名前にサブドメインが無ければ、そのサブドメイン用の証明書を取得するか、既存の証明書に名前を追加して取り直します（certbotなら --expand を付けて -d で名前を並べます）。DNSでCAAレコードを設定している場合は、使う認証局が許可されているかも確認してください。
5. WordPress: メインドメインに転送されていないか
サブドメインにWordPressを入れたのに、開くとメインサイトに飛ばされる場合は、WordPressの「サイトアドレス」の設定が原因のことが多いです。たとえばメインサイトのデータベースを複製して使ったときは、設定がメインドメインのままになっています。
WP-CLIが使える環境なら、次のコマンドで今の設定を確認できます。
wp option get siteurl
wp option get home値がサブドメインになっていなければ、管理画面の「設定」→「一般」で直します。管理画面に入れないときは、wp-config.php に WP_HOME と WP_SITEURL を定義して一時的に上書きする方法もあります。設定を変える前に、データベースと wp-config.php のバックアップを取ってから作業してください。
キャッシュ系のプラグインや、.htaccess に書いたリダイレクトの設定がメインドメインに飛ばしている場合もあります。転送の様子は次のコマンドで追えます。
curl -sIL https://sub.example.com/ | grep -iE '^(HTTP|location)'location: の行を見れば、どの段階でどこへ転送されているかが分かります。マルチサイトのサブドメイン型で子サイトだけが開かない場合は、ワイルドカードDNSとサーバー側のワイルドカード設定も確認してください。
6. キャッシュ: 古い結果を見ていないか
設定は直っているのに自分のブラウザだけ古いままなら、キャッシュを疑います。
- ブラウザ: プライベートウィンドウで開く。以前の301リダイレクトはブラウザに長く記憶されるので、別のブラウザでも試します。
- OSのDNSキャッシュ: Windowsなら
ipconfig /flushdnsで消せます。 - CDN: Cloudflareなどを使っているなら、そのサブドメインのレコードがプロキシの対象か、CDN側のキャッシュが残っていないかを確認します。
まとめ
- 表示内容から、DNS・サーバー・SSL・WordPress・キャッシュのどこで止まっているかの見当をつけます（2026年10月現在の一般的なレンタルサーバー・VPSの構成を前提にしています）。
- DNSは
digで、使われているネームサーバーとIPアドレス（AAAAを含む）を確認します。hostsファイルの書き忘れにも注意します。 - サーバー側は管理画面のサブドメイン追加と公開フォルダー、VPSなら
server_nameなどを確認し、curl --resolveでDNSと切り離して試します。 - SSLは証明書に名前が含まれているか、WordPressはサイトアドレスと転送の設定を確認します。