同様のトラブルに遭遇したときに初動判断を早められるよう、 今回のハングアップ事象で「何を見て、どう判断したか」を先に共有しておきたいと思い、この記録を書いています。
この記事では、公開中のコンテンツ配信サーバーで発生したハングアップ事象について、 当時の観測事実を時系列で整理します。
事の始まりはヘルスチェック異常のアラート
ある日、特定サーバーに対して 「ヘルスチェック NG」のアラートが発報されました。
対象は、メインサービス本体とは分離された WordPress 用のコンテンツ配信サーバーです。
構成は以下の通りです。
- 単一 EC2 インスタンス
- ロードバランサーなし
- WAF なし
インターネットへ直接公開された シングルインスタンス構成でした。
CloudWatch メトリクスが途中で停止
CloudWatch Dashboard を確認すると、 該当インスタンスのメトリクスのグラフが途中で途切れており、 以降更新されていない状態でした。
CloudWatch Agent からのメトリクス送信が 停止しているように見えました。
SSH 接続も不可
続いて SSH 接続を試みましたが、 セッションを確立できません。
ネットワークレベルでは応答があるものの、 OS 側の処理が詰まっているように見え、 インスタンスがハングアップしている可能性が高いと判断しました。
強制リブートを実施
やむを得ずインスタンスを強制リブートしました。
再起動後、コンテンツ配信は復旧し、 SSH 接続も可能になりました。
Apache ログで確認できた兆候
ログを確認したところ、 ハングアップそのものを直接示す致命エラーは残っていませんでした。
一方で、ハングアップ直前に Apache の HTTP/2 関連警告が連続して出力されていました。
[Mon Feb 14 10:03:09.046163 2026] [http2:warn] [pid 1940096:tid 1940116] [client xxx.xxx.xxx.xxx:38810] h2_stream(1940096-2-1,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Mon Feb 14 10:03:09.046199 2026] [http2:warn] [pid 1915817:tid 1915839] [client xxx.xxx.xxx.xxx:38594] h2_stream(1915817-362-1,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Mon Feb 14 10:03:10.207426 2026] [http2:warn] [pid 1940136:tid 1940156] [client xxx.xxx.xxx.xxx:38838] h2_stream(1940136-0-1,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
...
アクセス元 IP を確認
ログに記録されていたアクセス元 IP の Geo 情報を確認したところ、 ドイツ国内のアドレスでした。
外部アクセスの影響は疑われたものの、 この時点では原因の断定には至りませんでした。
本サーバーは業務上の優先度が低かったため、
暫定対応として iptables で該当 IP をブロックし、
ひとまず監視を継続する運用に切り替えました。
再発
しかし後日、 別 IP・別地域からのアクセス時に同様の事象が再発しました。
サーバーは同様にハングアップ状態となり、 SSH 接続も不能となりました。
この時点で、 一過性障害ではなく継続的要因があると判断しました。
この時点では原因は未確定でした。以降、ログ整理と再現確認へ進みました。