ウェブサイトがダウンすると、その故障はしばしばブラックボックスのように感じられます。訪問者はくるくる回るローディングアイコン、暗号化されたエラーコード、あるいは真っ白なページを目にします。そのサイトをオンラインに保つ責任のある人々にとって、最初の質問はいつも同じです：何が壊れたのか？
実際には、ウェブサイトが「落ちる」方法は一つではありません。ブラウザからのリクエストは複数のステップを経由します—DNS 解決、TCP 接続、TLS 協議、そして HTTP 応答。各ステップは前のステップに依存しています。そして各ステップで、異なる問題が発生し得ます。
だからこそ、賢い稼働監視は単にサイトが「ダウン」であると通知するだけではありません。チェーンのどこで故障が発生したかを教えてくれます。DNS エラーはある方向を指し、TCP エラーは別の方向を指します。TLS/SSL エラーは HTTP の 5xx とは異なる根本原因を示します。どのレイヤーが失敗したかがわかれば、どのチームやプロバイダに連絡すべきかがわかり、解決時間を劇的に短縮できます。
この記事では、ブラウザが実際にサイトを読み込む順序に沿って各エラー種別を説明します：DNS、TCP、TLS、HTTP。それぞれについて、そのステップが何をするのか、何が問題になり得るのか、そして監視がどのように顧客より先に問題を検出できるかを説明します。
DNS エラー
DNS はすべての Web リクエストが始まる場所です。ユーザーがブラウザにあなたのドメインを入力すると、まずそのドメインを IP アドレスに解決するための照会が行われます。このステップが失敗すると、他のことはすべて無意味になります—接続は確立できず、証明書も検証できず、HTTP 応答は届きません。だからこそ DNS エラーはしばしば障害の最も早く、最も重要なシグナルになります。
一般的な DNS エラー
以下は一般的な DNS 障害のいくつかです：
- NXDOMAIN — ドメイン名がそもそも存在しないことを意味します。実際には、期限切れの登録、ゾーンの誤設定、レコードの入力ミスから生じることが多いです。ドメインの期限切れはサイト全体を瞬時にオフラインにすることがあり、入力ミスによるレコードは単一のサブドメインやサービスにのみ影響するかもしれません。
- SERVFAIL — 権威ある DNS サーバーがリクエストを処理できなかったことを示すサーバーエラーです。壊れたゾーンファイル、欠落したグルー（glue）レコード、DNSSEC 検証の問題を指すことが多いです。SERVFAIL は設定変更の後に突然現れる傾向があり、不適切なデプロイの早期警告として有用です。
- タイムアウト — 期待される時間内に応答が返ってこない場合、クライアントは最終的にあきらめます。タイムアウトは、名前サーバーの過負荷、ネットワーク障害、またはリゾルバを飽和させる DDoS 攻撃によって引き起こされることが多いです。DNS の照会はキャッシュが効く前に発生するため、ここでの小さなレイテンシのスパイクでさえユーザーベース全体のページ読み込み遅延に波及する可能性があります。
DNS の監視方法
DNS の健全性を監視することは、ドメインが一度解決されるかを確認する以上のことを意味します。実際のユーザーが体験する方法で解決パスをテストする必要があります：
- グローバルチェック: 合成監視エージェントは複数の地理的場所やネットワークから DNS クエリを実行すべきです。あるレコードはあなたのオフィスからは正常に解決されるが、Anycast ルーティング問題やプロバイダの地域的な障害のためにアジアや南米で失敗することがあります。
- TTL の意識: 各レコードにはキャッシュを制御する time-to-live (TTL) 値があります。長い TTL は通常の閲覧を速くしますが、変更後の伝播を遅らせることがあります。監視は、新しい値が実際にライブクエリに反映されているか、古いキャッシュが残っていないかを検証するべきです。
- 異常のアラート: 最も実行可能なシグナルはトレンドから来ます。NXDOMAIN や SERVFAIL の急増、あるいは解決レイテンシのスパイクは、多くの場合、顧客が不満を言い始める前の最初の手がかりです。
DNS 監視が失敗すると、何が問題でないかについての確信も得られます。もし照会が解決されないなら、TCP、TLS、HTTP のチェックは試行されていません。それによりトリアージは迅速に狭められます。ほとんどの場合、修正は DNS ホスティングプロバイダ、レジストラ、またはゾーンファイルを管理する担当者に関わるものです。成熟したチームはこれらのベンダーと関係性やエスカレーション経路を構築し、問題を迅速に報告・解決できるようにします。
TCP 接続の失敗
DNS が IP アドレスを解決したら、次のステップは TCP ハンドシェイクです。これはデジタルな握手に相当します：クライアントが SYN を送り、サーバーが SYN-ACK を返し、クライアントが ACK で応答します。この交換が完了して初めて通信チャネルが確立されます。
TCP が失敗すると、ブラウザはサーバーがどこにあるかは知っているが、実際に通信できません。結果はブラックホールのように感じられます—ページがハングし、ソケットが開かれず、ユーザーは終わりのない読み込みアイコンを見ることになります。通常素早く明白な DNS エラーとは異なり、TCP の障害はサイトが一部の人にはアクセス可能で他の人には不可という混合的な部分障害を引き起こすことが多く、混乱を招きます。
一般的な TCP エラー
- Connection refused — クライアントはホストに到達したが、期待されるポートで何もリッスンしていない。これはサービスのクラッシュ、コンテナの終了、あるいはロードバランサの誤設定によく起こります。ポート 443 にバインドし忘れたウェブサーバーは、マシン自体が正常でも見えなくなります。
- Connection timed out — パケットが経路上のどこかでドロップされている。これはファイアウォールが静かにトラフィックをブロックしている場合、ルーティングの誤設定、あるいは上流の混雑が原因かもしれません。タイムアウトは特にフラストレーションを招きます—クライアントが諦めるまでただ沈黙が続くだけです。
- Connection reset — ここではハンドシェイクは完了するが、ほとんどすぐに切断される。リセットは通常、プロキシの過負荷、攻撃的なアイドルタイムアウト、または WAF のようなミドルボックスが疑わしいセッションとして切断することを示します。
TCP の監視方法
基本的な稼働チェックだけでは不十分です。ICMP ping は成功する一方で TCP ハンドシェイクが失敗し、健康状態の誤った認識を与えることがあります。適切な TCP 監視は接続の挙動に焦点を当てます：
- ハンドシェイクの検証: ツールは実際のサービスポートで明示的に SYN/SYN-ACK/ACK の交換を試みるべきです。これによりリスナーが到達可能で応答していることを確認できます。
- 経路分析: 異なる地域からの traceroute や MTR により、接続が停滞している場所—データセンター内、CDN エッジ、あるいは上流 ISP—を明らかにできます。
- プロトコルの整合性: IPv4 と IPv6 の両方をサポートしているなら、両方を監視してください。実際のインシデントの多くは一方だけに影響し、片方のみをテストしていると顧客に見える問題が見逃されることがあります。
TCP 監視はサーバーが単に動作しているだけでなく、トラフィックを受け入れる準備ができていることを保証します。またトリアージを狭めます：TCP が失敗しているなら DNS 解決は既に成功しているため、問題はホストかネットワーク経路にあります。この明確さにより、チームがアプリケーション層で無駄な追跡をするのを防げます。実際の問題はファイアウォールルールやロードバランサのプールが最後の健全ノードを静かに失ったことかもしれません。
TLS/SSL エラー
今日では、ほぼすべてのサイトが HTTPS で運用されています（数十年前には SSL が普及していなかったのと比較して）。つまり、TCP ハンドシェイクの後にブラウザとサーバーは TLS（Transport Layer Security）セッションを交渉する必要があります。TLS は一度に二つの役割を果たします：通信中のデータを暗号化し、デジタル証明書を介してサーバーが主張する通りの存在であることを証明します。
その信頼は複雑さを伴います。証明書が期限切れ、ホスト名と一致しない、または検証できない場合、ユーザーはブラウザの警告を目にするか—あるいはページ自体が読み込まれるのを拒否します。実務上、TLS エラーはサイトが遭遇する最も目立ち、かつ恥ずかしいインシデントの一つです。なぜならユーザーを入口で止め、安全に回避できない警告を表示するからです。
一般的な TLS/SSL エラー：
- 証明書の有効期限切れ — 証明書の有効期間が切れています。自動化がないか、更新がすべての場所に伝播していなかったために起こる、最も一般的な障害の一つです。
- ホスト名の不一致 — 証明書は www.example.com に対して発行されているが、ユーザーは api.example.com を訪れている。これは新しいサブドメインを追加した場合やサービスを CDN の背後に移動した場合によく起こります。
- 信頼されていない認証局（CA） — ブラウザが発行元の CA を認識していない場合。通常は自己署名証明書か、クライアントデバイスにインストールされていないプライベートルートにチェーンされていることが原因です。
- ハンドシェイクの失敗 — 暗号交渉そのものが失敗します。原因はサポートされていない暗号スイート、廃止されたプロトコルバージョン、または破損した証明書チェーンなどが考えられます。
TLS の監視方法：
TLS 監視は予防的かつ継続的である必要があります。証明書は徐々に壊れるわけではありません—ある日は機能していて、翌日にはアクセスを遮断することがあります。良い監視は次のことを行うべきです：
- 証明書の有効性を追跡する とともに、有効期限のかなり前にアラームを上げる—理想的には複数のしきい値（30 日、7 日、1 日）を設定します。
- 複数の地域から完全な証明書チェーンを検証する、中間証明書の欠落や地域的な CA 問題が世界各地で異なる影響を与える可能性があるためです。
- プロトコルと暗号のサポートをチェックする、ブラウザが TLS 1.0 や 1.1 のような古いバージョンを廃止していく中で互換性を保つことを確認します。
- ハンドシェイクエラーの急増を監視する、これらはしばしばロードバランサの誤設定や CDN のロールアウトに伴って発生します。
TLS の失敗が監視で検出されると、それはコンテキストも提供します：DNS 解決は成功し、TCP 接続も問題なかったが、安全なチャネルが確立できなかった—という具合に。これによりトラブルシューティングは即座に絞り込まれます。修正は通常、証明書の更新、ロードバランサの設定、あるいはエッジでの終端に関するものであり、アプリケーションコードではありません。
多くのチームにとって運用上の教訓は単純です：証明書をコードのように扱いなさい。発行と更新を自動化し、ディスク容量を監視するのと同じくらい積極的に有効期限を監視し、ローテーションをリハーサルして、期限切れの証明書が深刻な公開障害にならないようにします。
HTTP エラー
最後に、DNS、TCP、TLS が成功した後にブラウザは HTTP リクエストを送信します。サーバーは HTTP ステータスコードで応答します—すべて順調なら 200、問題があればエラーコードです。
HTTP の監視は、多くの人が「稼働監視」と考えるものです。しかし前段のステップからのコンテキストがなければ、HTTP エラーは物語の一部しか語りません。
一般的な HTTP エラー：
- 404 Not Found – リソースが存在しない。壊れたリンク、削除されたページ、あるいは誤ったルーティングの可能性があります。
- 500 Internal Server Error – サーバーが予期しない状態に遭遇した。通常はコードや設定のバグです。
- 502 Bad Gateway – プロキシやロードバランサが上流サーバーから有効な応答を得られなかった。
- 503 Service Unavailable – サーバーが過負荷かメンテナンス中である。
- 504 Gateway Timeout – 上流サービスの応答が遅すぎた。
HTTP の監視方法：
- グローバルエージェントから合成 GET リクエストを実行して応答を検証します。
- レスポンスコードをキャプチャし、200–299 範囲外のものに対してアラートを出します。
- 単一ページだけでなく、トランザクションワークフロー（ログイン、その後カートに追加、そしてチェックアウトなど）を監視します。
- 可用性だけでなく、応答時間のしきい値を設定します。
HTTP 監視はアプリケーション層が壊れていることを示します。DNS/TCP/TLS の問題とは異なり、HTTP エラーはしばしば外部プロバイダではなく、開発チームや運用チームの担当です。
まとめ：層別のエラー監視戦略
エラーを種別に分ける価値は明確性です。すべての障害は順序に従って発生します。DNS が失敗すれば、他は何も発生しません。TCP が失敗すれば、DNS は正常でした。TLS が失敗すれば、DNS と TCP は機能していました。HTTP が失敗すれば、それまでのすべてが機能していたということです。
層別の監視アプローチはこの順序を反映します：
- まず DNS チェックから始める。
- TCP 接続の監視を追加する。
- TLS 証明書の監視を重ねる。
- HTTP 応答の監視で仕上げる。
この層モデルにより、根本原因を迅速に特定できます：
- DNS エラー？ DNS プロバイダに連絡してください。
- TCP エラー？ ホスティングまたは ISP を関与させてください。
- TLS エラー？ 証明書やエッジ設定を修正してください。
- HTTP エラー？ ウェブチームと相談してください。
漠然とした「サイトがダウン」というアラートの代わりに、何が壊れているのか、誰が修正すべきかの正確な地図が手に入ります。それにより平均修復時間（MTTR）が短縮され、チーム間の責任の押し付けを避けられます。
結論
ウェブサイトは一つの方法でだけ故障するわけではありません—層ごとに故障します。DNS、TCP、TLS、HTTP はそれぞれ固有のリスクとエラー署名を持ちます。エラー種別ごとの監視は、その複雑さを明快さに変えます。
適切な監視戦略（および Dotcom-Monitor のようなツール）を用いれば、単にサイトがダウンしていることがわかるだけでなく、なぜダウンしているのかがわかります。DNS ホスト、ネットワークプロバイダ、セキュリティチーム、あるいは開発者のどこにエスカレーションすべきかが明確になり、その可視性をサポートチケットや顧客クレームを待たずに迅速に得られます。
結局のところ、エラー種別ごとの監視は単なる可用性の問題ではありません。責任と速度に関するものです。次回サイトが障害を起こしたときに「何かが壊れた」で済ませないでください。どの層が故障したのか、それが何を意味するのか、どう修正するのかを正確に把握してください。