Webサイトを公開した直後によくあるのが、「自分のパソコンでは開けるのに、ほかの人はエラーになる」「DNSを変更したのに、いつまでも反映されない」「HTTPSは正常に見えるが、証明書の期限が迫っている」「CDNやWAFを導入したものの、実際に保護ノードを経由しているか分からない」といったトラブルです。
こうした問題は、単一の設定ミスだけで起きるとは限りません。ユーザーがブラウザにURLを入力すると、リクエストはDNS名前解決、ネットワーク接続、CDN、WAF、Webサーバー、HTTPS暗号化の順に処理されます。どこか一つでも設定に問題があると、「サイトが開かない」「表示が遅い」「安全ではないと警告される」といった症状につながります。
ここでは、ブラウザですぐに使える18のWebサイト診断ツールを、実際のトラブルシューティング手順に沿って5つのカテゴリにまとめました。新規サイトの公開、サーバー移行、ドメイン変更、HTTPS化、日常の運用保守まで、このチェックリストに沿って順番に確認できます。
ヒント：各ツールはゲストでも一定回数お試しいただけます。ログインすると利用上限が増え、プロ会員はさらに多く利用できます。実際の上限は各ツールのページでご確認ください。
1. ドメインとDNSが正常か確認する
Webサイトにアクセスできない場合、すぐにサーバー設定を変更するのではなく、まずドメインが有効か、DNSから正しいレコードが返されているかを確認しましょう。
1. DIG検索：DNSレコードを詳しく確認
DIG検索は、複雑なDNS名前解決の問題を調査するのに適しています。A、AAAA、CNAME、MX、NSなどのレコードを検索でき、問い合わせ先のDNSサーバーも指定できます。
主な用途：
- ドメインが新しいサーバーのIPアドレスを参照しているか確認する
- DNSサーバーごとの応答結果を比較する
- メール送受信の不具合に関係するMXレコードを調べる
- NSサーバーの切り替えが完了しているか確認する
DNSを変更した直後は、権威DNSと一般的なパブリックDNSの両方に問い合わせるのがおすすめです。設定ミスなのか、キャッシュがまだ更新されていないだけなのかを判断しやすくなります。
2. NSLOOKUP検索：名前解決の結果をすばやく確認
NSLOOKUP検索は、日常的な簡易チェックに便利です。ドメインを入力するだけで、A、AAAA、CNAME、MX、NSなどの名前解決結果を確認できます。
DIGとNSLOOKUPの用途は似ていますが、DIGは出力情報が詳しく、詳細な分析向けです。NSLOOKUPは結果が分かりやすく、「このドメインが現在どこを参照しているか」をすぐに確かめたい場合に適しています。
3. WHOIS検索：ドメインの登録情報と有効期限を確認
WHOISドメイン検索では、レジストラ、登録日、有効期限、ドメインステータスなどを確認できます。
ドメインに突然アクセスできなくなった場合は、DNS設定だけでなく、次の点も確認しましょう。
- ドメインの有効期限が切れていないか
clientHoldなど、名前解決を停止する状態になっていないか- レジストラやレジストリによってドメインがロックされていないか
- ネームサーバーが意図せず変更されていないか
4. ドメイン診断：DNSとHTTPステータスをまとめて確認
ドメイン診断ツールは、DNSレコードとHTTPステータスコードを同時に確認できるため、最初の簡易診断に便利です。
IPアドレスは取得できるのにHTTPリクエストが失敗する場合は、サーバー、ポート、ファイアウォール、Webサービス側に原因がある可能性が高いでしょう。IPアドレス自体を取得できない場合は、DNSを優先して確認します。
5. サブドメイン検出：公開中のWeb資産を把握
サブドメイン検出ツールでは、対象ドメインで現在も使われているサブドメインを検出できます。公開前の資産棚卸しやセキュリティチェックに役立ちます。
セキュリティ問題は、メインサイトではなく、古い管理画面、テスト環境、期間限定ページ、忘れられたサブドメインで発生することも少なくありません。各サブドメインが今も必要か確認し、不要なサービスを停止することで、攻撃対象となる範囲を減らせます。
2. CDN・WAF・リダイレクト経路を確認する
DNSが正常なら、次にアクセスが想定どおりCDNやセキュリティ保護レイヤーを経由しているか確認します。
6. CDN事業者検出：高速化ノードが有効か確認
CDN事業者検出では、WebサイトがCDNを利用しているか、どの事業者を利用している可能性があるかを調べられます。
次のような確認に役立ちます。
- CNAMEがCDNを参照しているか
- Webサイトへのアクセスがエッジノードを経由しているか
- CDNの切り替え後も古い設定が残っていないか
- 競合サイトや外部サイトがどのCDNを利用しているか
実際の経路を隠しているWebサイトもあるため、検出結果だけで判断せず、DNSレコード、レスポンスヘッダー、実際の接続先ノードもあわせて確認してください。
7. WAF検出：Webアプリケーションファイアウォールを識別
WebサイトWAF検出では、Webアプリケーションファイアウォールが導入されているかを判定し、WAFの種類やベンダーを識別します。
WAFを導入しても、Webサイトが完全に安全になるわけではありません。ただし、一般的な不正リクエスト、スキャン、攻撃トラフィックの遮断には役立ちます。管理システム、APIサービス、ユーザーデータを扱うサイトでは、公開前にWAFルールが正しく機能しているか確認しましょう。ルールが厳しすぎて、正常なリクエストまで誤検知しないことも重要です。
8. URLリダイレクトチェック：301・302の転送経路を確認
URLリダイレクトチェックでは、URLが最終ページへ到達するまでの転送経路と、各段階のHTTPステータスコードを確認できます。
特に次の確認に便利です。
- HTTPからHTTPSへ正しく転送されるか
- ルートドメインと
www付きドメインが統一されているか - 旧URLから301永久リダイレクトが設定されているか
- リダイレクトループや長すぎる転送チェーンがないか
- ランディングページが外部リンクによって再転送されていないか
転送回数が増えるほど表示までの時間が長くなり、クローリング、計測、SEOにも悪影響を与えやすくなります。旧URLから最終URLへ、できるだけ1回で転送するのが理想です。
3. SSL証明書とHTTPSの安全性を確認する
HTTPSでページが開けても、証明書、HSTS、TLSの設定がすべて正常とは限りません。
9. SSL証明書チェック：期限切れやドメイン不一致を防止
SSL証明書チェックでは、証明書の有効性、発行者、有効期間、暗号化アルゴリズム、ドメインとの一致を確認できます。
公開前の主な確認項目：
- 現在アクセスしているドメインが証明書に含まれているか
- 中間証明書チェーンが正しく構成されているか
- 証明書の期限が切れておらず、更新まで十分な余裕があるか
- 新旧両方のサーバーに正しい証明書が設定されているか
- 自動更新処理が実際に成功するか
証明書の問題は、多くのユーザーにブラウザ警告が表示されて初めて発覚することがあります。有効期限は日常の監視項目に含めておきましょう。
10. HSTSテスト：ブラウザでHTTPSを強制できているか確認
HSTSテストツールでは、Strict-Transport-Securityレスポンスヘッダーを検出し、max-age、includeSubDomains、プリロード関連の設定を確認できます。
HSTSは、HTTPSのダウングレードやSSLストリッピングのリスク低減に役立ちます。ただし、設定前に関連するすべてのドメインがHTTPSに対応していることを確認してください。特にincludeSubDomainsの有効化やHSTS Preloadへの登録前には、過去に使っていたサブドメインも確認しましょう。古いサービスがHTTPSを強制され、アクセスできなくなる可能性があります。
11. TLS LOGJAM脆弱性チェック
TLS LOGJAM脆弱性チェックでは、サーバーのDiffie-Hellman鍵交換設定を評価し、脆弱なパラメータによるダウングレード攻撃のリスクを確認できます。
問題が検出された場合は、TLS設定とサーバーソフトウェアを優先して更新し、安全でない古い暗号スイートを無効化したうえで、十分な強度のパラメータを使用してください。
12. SSL Heartbleed脆弱性チェック
SSL Heartbleed脆弱性チェックでは、対象のSSL/TLSサービスにCVE-2014-0160のリスクがないか確認できます。
Heartbleedは過去の脆弱性ですが、長期間更新されていない機器、旧システム、レガシーサービスは今も確認する価値があります。問題が見つかった場合、証明書を交換するだけでは不十分です。影響を受けるソフトウェアを更新し、古い秘密鍵や機密データが漏えいした可能性も評価してください。
13. TLS Ticketbleed脆弱性チェック
TLS Ticketbleed脆弱性チェックでは、TLSセッションチケットに関連するCVE-2016-9244のメモリ情報漏えいリスクを確認できます。
このような個別の脆弱性チェックは、サーバー保守、セキュリティ監査、レガシー機器の調査に適しています。異常が検出された場合は、機器メーカーのセキュリティ情報、ソフトウェアのバージョン、サーバー設定を照合して詳しく確認してください。
セキュリティチェックは、自身が所有するWebサイトやサーバー、または明確な許可を得た対象にのみ実施してください。許可のない対象へのスキャンや脆弱性診断は行わないでください。
4. Webページの圧縮とサーバー応答速度を確認する
セキュリティを確認したら、次はページが効率よく配信されているかを調べます。ページが開けることと、十分に速く表示されることは同じではありません。
14. GZIP圧縮チェック
GZIP圧縮チェックでは、WebページのレスポンスでGZIPが有効になっているかを判定し、圧縮前後のデータサイズを比較できます。
HTML、CSS、JavaScript、JSON、SVGなどのテキスト形式は、一般的に圧縮に適しています。サイズの大きいテキストを圧縮せずに配信すると、通信量とダウンロード時間が増加します。
15. Brotli圧縮チェック
WebページBrotli圧縮チェックでは、レスポンスヘッダーからBrotli圧縮が有効かどうかを確認できます。
Brotliはテキストデータを効率よく圧縮でき、HTTPSとモダンブラウザでの配信に適しています。運用時は互換性のためにGZIPも残し、ブラウザのAccept-Encodingに応じてサーバーが自動選択する構成がおすすめです。
16. TTFBテスト：サーバーの初期応答が遅くないか確認
TTFBテストツールでは、リクエスト開始から最初の1バイトを受信するまでの時間を測定し、DNS、TCP、SSL、サーバー応答の各段階にかかった時間を分析できます。
TTFBが長くなる主な原因：
- DNS名前解決やネットワーク接続に時間がかかっている
- サーバーがユーザーから遠い地域にある
- 動的ページの検索処理やレンダリングが遅い
- キャッシュがヒットしていない
- 上流APIの応答待ちが発生している
- CDNからオリジンサーバーへの接続が遅い
TTFBは、パフォーマンス診断の出発点の一つです。ページ内リソースの容量、キャッシュ戦略、フロントエンドのレンダリング時間もあわせて分析しましょう。
5. ネットワーク接続とポートを最終確認する
DNSとHTTPSが正常に見えてもサービスへ接続できない場合は、ホストとポートの到達性を確認します。
17. Pingテスト：遅延とパケットロスを確認
Pingテストでは、対象ホストへの接続可否、ネットワーク遅延、パケットロスを確認できます。
サーバーやクラウドファイアウォールがICMPを無効にしている場合もあるため、Pingに応答しなくてもWebサイトが停止しているとは限りません。HTTPリクエストやポートチェックの結果もあわせて判断してください。
18. ポートチェック：サービスが外部公開されているか確認
ポートチェックでは、ドメインまたはIPアドレスのTCPポートが開いているか、閉じているか、フィルタリングされているかを確認できます。
一般的には、80（HTTP）、443（HTTPS）、そのほかサービスで実際に使用するポートを確認します。Webサイトのポートへ接続できない場合は、クラウドのセキュリティグループ、OSのファイアウォール、コンテナのポートマッピング、リバースプロキシのリッスンアドレス、サービスプロセスの状態を順番に確認してください。
また、データベース、キャッシュ、管理画面など、インターネットへの公開が不要なポートは、接続元IPを制限するか、内部ネットワークからのみアクセスできるようにしましょう。
そのまま使えるWebサイト公開前の確認手順
どこから確認すればよいか迷ったら、次の順番で進めてください。
- WHOISでドメインが有効か、ステータスが正常か確認する
- DIGとNSLOOKUPでA、AAAA、CNAME、MX、NSレコードを確認する
- ドメイン診断ツールで名前解決先のIPとHTTPステータスを確認する
- CDN・WAF検出で通信経路と保護機能が有効か確認する
- URLリダイレクトチェックでHTTP/HTTPSと正規ドメインを統一する
- SSLチェックで証明書、対象ドメイン、有効期限を確認する
- HSTSとTLS脆弱性チェックでHTTPSの安全設定を再確認する
- GZIPとBrotliでテキストデータの圧縮を確認する
- TTFBでサーバーやオリジンの応答が遅くないか確認する
- Pingとポートチェックでネットワーク接続の問題を調査する
- サブドメイン検出で古いテストサイトや不要なサービスを整理する
まとめ
Webサイトの障害は、どのレイヤーに問題があるのかを直接教えてくれるとは限りません。ブラウザに表示される「アクセスできません」という短いメッセージの裏には、ドメインの期限切れ、DNSキャッシュ、CDNのオリジン接続、WAFの誤検知、証明書チェーンの不足、ポートの未開放、サーバーの初期応答遅延など、さまざまな原因が考えられます。
障害が起きるたびに経験だけを頼りに設定を変更するのではなく、確認手順を標準化しておきましょう。公開前に一通り確認し、移行やリニューアル後にも再チェックします。通常運用では、ドメイン、証明書、重要なAPIを重点的に監視してください。この18のツールをブックマークしておけば、Webサイトが開かない、HTTPSエラーが出る、表示が遅いといった問題が起きても、通信経路に沿って原因を切り分けられます。