ERR_CONNECTION_TIMED_OUT

このエラーの意味と見分け方

• ブラウザーに「このサイトにアクセスできません」などのメッセージと ERR_CONNECTION_TIMED_OUT が表示される。
• 失敗するまでに、すぐに失敗する場合よりも明らかに長く待たされる。
• あるネットワークではホスト名にアクセスできるが、別のネットワークではタイムアウトする。
• ホスティングコンソールではインスタンスが稼働中と表示されていても、サーバーのパブリックアドレスへのリクエストがタイムアウトすることがある。
• ホスト、ネットワークインターフェース、経路、または上流ネットワークが利用できない場合、多数の訪問者に影響する。
• CPU、メモリ、プロセス、接続数に深刻な負荷がかかっているサーバーは、電源が入ったままでも新しい接続を速やかに完了できないことがある。
• CDN、リバースプロキシ、ロードバランサーには到達できても、オリジンへの接続がタイムアウトすることがある。

可能性の高い順の主な原因

1. ホストまたはネットワークインターフェースに到達できない — サーバー、VM、ネットワークインターフェース、経路、または上流ネットワークが利用できない可能性があります。
2. ファイアウォールまたはセキュリティグループが通信を黙って破棄している — 破棄ルールではタイムアウトが発生することが多い一方、明示的な拒否では通常より速く失敗します。
3. サーバーが過負荷になっている — リソース不足、プロセス数の上限、または開きすぎた接続により、TCP ハンドシェイクやアプリケーションの応答を完了できないことがあります。
4. DNS が誤った接続先を示している — ホスト名が古いアドレス、到達できないアドレス、またはサイトを提供しなくなったインフラに解決されている可能性があります。
5. 訪問者のネットワーク経路が壊れている — ISP のルーティング問題、VPN、プロキシ、ローカルファイアウォール、フィルタリング装置によって、特定のネットワークからのアクセスがブロックされることがあります。
6. IPv6 の設定が正しくない — 利用できない AAAA レコードにより、IPv4 のサービスが動作していても IPv6 を優先するネットワークで失敗することがあります。
7. CDN、リバースプロキシ、ロードバランサー、または上流の保護レイヤーの設定が誤っている — オリジン自体は稼働していても、フロントエンドからオリジンに接続できない可能性があります。

修正方法

1. 2つ目のネットワークからテストする

モバイルデータ通信または関係のない別の接続を使ってサイトを開きます。VPN やプロキシが有効な場合は、許可される範囲で無効にしてテストしてください。

• 2つ目のネットワークでは動作する場合： 元の Wi-Fi、ISP の経路、ローカルファイアウォール、VPN、プロキシ、またはフィルタリング装置を調査します。
• どのネットワークでもタイムアウトする場合： DNS、サーバー、ファイアウォール、ホスティングプロバイダーの確認に進みます。

1回のテストが成功したからといって、すべてのユーザーに対してサイトが正常だと判断しないでください。ルーティングやアドレスファミリーの問題は、一部のネットワークだけに影響することがあります。

2. DNS と両方のアドレスファミリーを確認する

nslookup や dig などの DNS ルックアップツールを使い、ホスト名に対して返される IPv4 アドレスと IPv6 アドレスを確認します。返されたすべてのアドレスを、通信を受けるべきサーバー、ロードバランサー、CDN、その他のサービスと照合してください。

古いアドレス、予期しないレコード、または設定されていない IPv6 の接続先がないか確認します。DNS を最近変更した場合は、権威 DNS のレコードを確認し、1つのネットワークから変更を判断する前に、設定されたキャッシュ期間を考慮してください。

3. ブラウザーに依存せずサービスをテストする

サイトに到達できるはずのネットワークから、次のような読み取り専用のリクエストを実行します。

curl -v --connect-timeout 10 https://[your hostname]

詳細出力により、ホスト名の名前解決、TCP 接続の確立、HTTPS ネゴシエーションのどの段階で失敗しているかを確認できます。実際に使用するサービスのポートとプロトコルをテストしてください。ping の失敗だけでは結論を出せません。ICMP がブロックされている可能性があります。

サービスを管理している場合は、適切な読み取り専用テストを使って IPv4 と IPv6 の接続動作を個別に比較します。一方のアドレスファミリーだけで失敗する場合は、その経路、リスナー、ファイアウォールポリシー、または DNS レコードに調査範囲を絞れます。

4. ホスティングプロバイダーのコンソールを確認する

ネットワークアクセスに問題がある場合は、SSH だけに頼らず、プロバイダーのダッシュボードまたは帯域外コンソールを使用します。インスタンスが稼働していること、ネットワークインターフェースが接続されていること、パブリックアドレスが正しいこと、プロバイダーのヘルスチェックで障害が報告されていないことを確認してください。

コンソールでホストが応答していないと表示された場合は、承認済みの復旧手順を使用します。再起動や電源の入れ直しは運用上の変更です。権限を確認し、アクティブなユーザーや保存されていない作業への影響を把握したうえで、プロバイダーの文書化された復旧手順に従ってください。

5. クラウドとホストのファイアウォールルールを確認する

セキュリティグループ、ネットワーク ACL、プロバイダーのファイアウォールポリシーで、想定する受信サービスのポート（通常は設定に応じた HTTP または HTTPS）が許可されているか確認します。その後、コンソールにアクセスできる場合は、ufw や iptables などの OS のファイアウォールを確認します。

セキュリティ強化、デプロイ、アドレス変更、移行の際に追加されたルールを確認します。該当する送信元範囲からの通信が許可され、ルールが正しいインターフェースとアドレスファミリーに適用されていることを確認してください。保護機能を広範囲に無効化しないでください。承認された最小限の変更だけを行い、記録してください。

6. リソース不足を確認する

プロバイダーのコンソールまたは既存の管理セッションから、CPU、メモリ、ディスクの逼迫状況、プロセス数の上限、待ち受けソケット、接続数を確認します。マシンの電源が入っていても、新しい接続を受け入れられないほど過負荷になっていることがあります。

現在の値を通常時の水準と比較し、最初に失敗した時刻の前後のログを確認します。サービスがリソースを使い果たしている場合は、何度も再起動するのではなく、承認済みの容量拡張または復旧手順に従ってください。再起動するとアクティブな通信が中断され、根本的な負荷問題が隠れてしまう可能性があります。

7. プロキシ、CDN、ロードバランサーを確認する

DNS が CDN、リバースプロキシ、またはロードバランサーを指している場合は、フロントエンドから設定済みのポートでオリジンに接続できることを確認します。オリジンアドレス、ヘルスチェックの状態、TLS 設定、ネットワーク経路、許可リストを確認してください。

オリジンが正常でも、フロントエンドとオリジンの間のポリシーや経路が壊れている可能性はあります。反対に、フロントエンドが正常でも、オリジンが接続を受け入れているとは限りません。

8. 有用な証拠を添えてエスカレーションする

影響を受けるホスト名、おおよその発生時刻とタイムゾーン、クライアントのネットワーク、解決された IPv4 および IPv6 アドレス、各アドレスファミリーで挙動が異なるかどうか、詳細な接続出力、プロバイダーコンソール上のヘルス状態を記録します。これらの証拠は、DNS、ルーティング、フィルタリング、ホスト、中間システムのどこに障害があるかを切り分けるのに役立ちます。

予防と修正確認

• 複数の外部拠点からサイトを監視し、HTTP ステータスの失敗とは別に接続タイムアウトを検知して通知します。
• DNS レコード、パブリックアドレス、CDN のオリジン、IPv4/IPv6 の設定を文書化し、移行後に確認します。
• ファイアウォールとセキュリティグループの変更は、プロバイダーコンソールからの復旧手段を用意した管理されたプロセスでテストします。
• CPU、メモリ、ファイルディスクリプター、プロセス、接続数に余裕を確保し、トラフィック急増によって新しい接続が妨げられないようにします。
• オリジンのヘルスを CDN またはロードバランサーのヘルスとは別に監視します。
• インシデント対応チェックリストに、2つ目のネットワークからのテストと接続タイムアウトの証拠を含めます。
• 正規のサービス用ポートには明確で意図したファイアウォール動作を使用しつつ、環境に必要なセキュリティポリシーを維持します。

よくある質問