先に結論
訪問者向けのキャッシュ削除だけでは運営側障害を見落とします。誰が・どの経路で・接続のどの段階まで到達したかを外側から確認します。
最初に「利用者限定」か「全体」かを分ける
- エラー全文、URL、発生時刻、回線・地域を保存する。
- モバイル回線、別地域の外部監視、IPv4/IPv6で同じURLを確認する。
- DNS解決結果と接続先IPが想定どおりか確認する。
- TCP 443の接続、TLS handshake、HTTP応答のどこで止まるか分ける。
- CDN/LB/オリジンの到達ログと、同時刻のFW・負荷指標を確認する。
結論：外部からもTCP接続前に止まるなら、ブラウザではなく経路、FW、待受、過負荷を優先します。HTTP応答待ちなら502/504の切り分けへ進みます。
観測結果から次を決める
| 観測 | 優先箇所 | 次の確認 |
|---|---|---|
| 一人・一社だけ失敗 | 端末/VPN/社内経路 | 別回線、プロキシ、DNS、セキュリティ製品 |
| 特定地域・回線だけ | 経路/CDN/IPv6 | POP別監視、A/AAAA、経路差 |
| 全地点でTCP timeout | FW/待受/オリジン | ポート、許可元、NACL、ルート、サーバー状態 |
| 接続拒否 | 待受・プロセス | サービス稼働、ポート割当、再起動履歴 |
| TLSで停止 | TLS終端 | 証明書・SNI・プロトコル |
| HTTP応答が遅い | アプリ/依存先 | LB、アプリ、DB、外部APIの時間 |
運営側で確認する順序
- DNS：A/AAAA/CNAMEとTTL、意図しない旧IPが残っていないか。
- CDN/LB：健全性チェック、オリジンプール、接続失敗、リージョン差。
- FW/NACL：CDN/LBの送信元、443、戻り通信、直前のルール変更。
- 待受：正しいIP/ポートでプロセスが待ち受け、接続枯渇がないか。
- 容量：CPU、メモリ、ファイル記述子、接続数、キュー、ディスクI/O。
- 依存先：DB、名前解決、外部APIがアプリ全体を待たせていないか。
してはいけないこと
- 一人の端末だけの症状で全体DNSを変更する。
- 検証のために管理ポートやオリジンを全世界へ公開する。
- FWを恒久的に無効化して原因確認を終える。
- 過負荷時に無制限の再試行や同時接続を増やす。
ネットワーク・ホスティングへ渡す情報
- 失敗/成功した接続元、時刻、IPv4/IPv6、対象IPとポート
- DNS結果、TCP/TLS/HTTPのどこまで進んだか
- FW/NACL/LBの同時刻ログ、直前のルール変更
- CPU・メモリ・接続数・健全性チェックの推移
- 暫定回避と、その実施時刻・影響範囲
公式情報
よくある質問
自分だけタイムアウトする場合は？
別回線と外部監視が正常なら、端末、VPN、プロキシ、社内FW、DNSキャッシュを優先します。サイト全体のDNSやサーバーを変更しません。
Connection refusedとの違いは？
refusedは宛先から明示的に拒否された可能性が高く、timeoutは応答が戻らない状態です。待受ポート、FWのDROP/REJECT、経路、過負荷を分けて確認します。
pingが通ればWebも正常ですか？
いいえ。ICMPとTCP 443は別です。HTTP/TLSを実際に外部から確認し、CDN/LB/オリジンの到達ログで判断します。