「このサイトにアクセスできません」エラーの原因を切り分ける方法

「このサイトにアクセスできません」（またはブラウザーごとの同等の表示）は、意図的に曖昧な表現です。URLの入力ミスから、サーバーの完全なダウン、手元の接続のネットワーク障害まで、あらゆる原因を含みます。効率よく調べるには、最も手軽で速い確認から順に進めます。

まずは単純なDNS検索から

サーバーがダウンしていると決めつける前に、ブラウザーとは切り離して、ドメインそのものを名前解決してみてください。正常なIPアドレスが返ってくれば、DNSは原因ではないので、接続そのもの（ポートが開いているか、TLSのネゴシエーションが進むか、サーバーが実際に応答しているか）の確認に進めます。NXDOMAIN、タイムアウト、あるいはプライベートや到達不能に見えるアドレスが返ってきた場合は、問題がDNSにあると特定でき、ほかのトラブルシューティングの分野を一気に除外できます。

各結果が示すもの

障害の最中に、登録不要で素早く使える検索ツールが本当に役立つのもこのためです。ターミナルを開いたり、dig／nslookupの構文を思い出したりしなくても、数秒でDNS層の答えが得られます。ほかの場所に時間を使う前に、そもそもDNSの問題なのかどうかをすぐに絞り込めます。

DNSの次に確認すること（順番に）

1. 想定ポート（通常は443）での、解決されたIPへのTCP接続。DNSが完全に正しくても、ファイアウォールやサーバーの完全なダウンがあると、ここで拒否されるか応答が止まります。
2. TLS証明書の有効性。期限切れや不一致の証明書は、ブラウザーに不安を煽るセキュリティ警告を表示させますが、DNSやサーバーへの到達性とは無関係です。
3. HTTPレベルの応答。接続は受け付けるが5xxエラーを返すサーバーは、稼働していて到達できており、アプリケーション層で失敗しているだけです。DNSが原因となり得る範囲から、いくつも先の段階です。

DNS、トランスポート、TLS、アプリケーションの順に確認していけば、1つ除外するごとに残りの可能性が大きく絞られます。スタック全体を一度に推測する必要はありません。

なぜこの順番なのか

この順序の各層は、前の層が成功していることに完全に依存しています。最も可能性が高そうなところに飛びつくのではなく、順番に確認するのが効率的なのはそのためです。TCP接続がそもそも完了していないのにTLS証明書を調べても意味がなく、TLSのネゴシエーションに失敗しているのにHTTPの応答コードを調べても意味がありません。ほかのすべてが可能になる前に必ず起きるDNSから始めて、1層ずつ外側へ進めば、実はもっと単純で手前の層の問題が原因だった症状を、延々と調べて時間を無駄にすることがなくなります。