Webサイトを開こうとして、読み込みが続いたまま突然「ERR_CONNECTION_TIMED_OUT」。急いでいるほど焦りますが、原因は大きく 端末の設定・回線の不調・相手サイト側の問題 のいずれかです。やみくもにキャッシュ削除や設定変更を始めると、ログイン情報が消えたり、セキュリティ設定を崩したまま戻し忘れたりして、かえって時間を失いがちです。
本記事では、まず 3分で原因の当たりを付ける切り分けフロー を提示し、影響が小さい操作から順番に「どれを試せば直るか」を迷わない形で整理します。シークレットモードや拡張機能の確認、VPN・プロキシの見直し、DNSフラッシュ、ルーター再起動まで、状況別に最短ルートで解説。さらに、直った後に再発を減らすコツと、サイト運営者側で疑うべきポイントもまとめています。いま目の前のエラーを最短で解消し、同じトラブルに振り回されない状態を一緒に作りましょう。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
ERR_CONNECTION_TIMED_OUTで困ったときに最初に読むこと
今すぐ確認したい安全チェック
設定変更に入る前に、まずは「安全で簡単、しかも切り分けに効く」確認を行ってください。ここを飛ばすと、遠回りになりがちです。
別のサイトは開けますか
例：検索エンジン、ニュースサイト、動画サイトなど。ほとんどのサイトが開けない → 回線やルーター側が濃厚です。
特定サイトだけ開けない → 端末側（DNS/ブラウザ）か、相手サイト側が濃厚です。
同じURLをスマホで開けますか（できればモバイル回線で）
Wi-Fiにつないだスマホではなく、4G/5Gのモバイル回線が理想です。スマホ（モバイル回線）では開ける → 自宅/社内の回線やPC側の要因が濃厚です。
スマホでも開けない → 相手サイト側の障害・混雑の可能性が上がります。
いまだけ混んでいる可能性はありませんか
サイトが混雑している、メンテナンス中、障害中の場合、こちらでできることは限られます。時間を置いた再試行や、公式SNS/障害ページの確認が有効です。仕事や手続きで急ぎの場合、回避策があるか
例：別端末、別回線、別ブラウザ、アプリ版、キャッシュ済みページ、ミラーサイトなど。
まず回避策を確保してから原因究明すると、焦りが減り、余計な設定変更を避けられます。
ここまでで「自分の環境（端末/回線）に寄っていそうか」「相手側に寄っていそうか」の方向性が見えてきます。次章で、もう一段はっきり切り分けます。
ERR_CONNECTION_TIMED_OUTの原因を切り分ける
端末側の可能性が高いサイン
端末側（PC・ブラウザ・セキュリティ設定・プロキシ設定など）が原因の場合、次のような“端末依存の差”が出ます。
スマホでは開けるのにPCだけ開けない
端末固有のDNSキャッシュ、ブラウザ設定、拡張機能、プロキシ、セキュリティソフトが疑わしいサインです。別ブラウザだと開ける（ChromeはダメだがEdgeはOKなど）
ブラウザのキャッシュ・Cookie・拡張機能、またはブラウザごとのプロキシ設定差が疑われます。シークレットモードでは開ける
多くの場合、拡張機能が無効化されたり、キャッシュ/セッションの影響が減ったりして改善します。つまり「拡張機能かサイトデータ（Cookie等）が原因」になりやすい状況です。拡張機能やVPNアプリを入れた直後から起きる
変更直後に症状が出るのは、原因特定の大きなヒントです。まず追加したものを一時停止して再試行すると、短時間で答えが出ます。
端末側の特徴は「同じ回線でも端末を変えると結果が変わる」ことです。次の「回線側」「相手サイト側」のサインと比較し、当たりを付けてください。
回線側の可能性が高いサイン
回線側（ルーター・Wi-Fi・プロバイダ・社内ネットワーク）に問題がある場合、「端末を変えても同じ回線だとダメ」「別回線にすると急に直る」という形が典型です。
自宅Wi-Fiではダメだが、テザリングだと開く
自宅回線、ルーター、DNS設定、IPv6経路などが疑わしい状況です。家の端末が複数台、同じサイトで同様にダメ
端末個別ではなく、回線やルーターの共通部分に原因がある可能性が高いです。夜だけ遅い、混雑時間帯に悪化する
回線混雑やプロバイダ側の状況で、タイムアウトが起きやすくなります。速度テストだけでは分からず、特定の宛先への経路が混む場合もあります。ルーター再起動で一時的に改善するが再発する
ルーターの不調、DNSの不安定、Wi-Fi干渉、IPoE/PPPoE周りの相性など、継続的な見直しが必要なサインです。
回線側が疑わしい場合は、「ルーター再起動」「別回線で検証」「DNS変更」が切り札になりやすいです。後半で手順を詳しく解説します。
相手サイト側の可能性が高いサイン
相手サイト側（サーバー負荷、障害、ネットワーク障害、DDoS、CDNやWAFの問題）で起きている場合、こちらの設定を変えても改善しません。次のサインが強いほど、相手側要因の確度が上がります。
どの端末・どの回線でも同じサイトだけ開けない
端末や回線の共通点がないのに同じサイトが落ちるなら、相手側の可能性が高いです。同じ時間帯にSNSなどで報告が増える
“自分だけ”ではなく“みんな”が困っている状態は、相手側の障害や混雑を示唆します。時間を置いたら直る
しばらくして復旧するのは、メンテナンスや一時的な過負荷、ネットワーク障害が解消したサインであることが多いです。
相手側が濃厚なときは、無理に設定をいじらず、回避策（別回線、ミラー、アプリ、キャッシュ、問い合わせ）へ切り替えるほうが安全です。
症状から原因を絞る早見表
まずは「いまの症状」をここに当てはめてください。次にやることが決まります。
| 症状 | 原因候補 | 最初に試す手順 |
|---|---|---|
| スマホはOK、PCだけNG | PCのDNSキャッシュ、プロキシ/VPN、拡張機能、キャッシュ/Cookie、セキュリティソフト | シークレット→拡張OFF→VPN/プロキシ確認→DNSフラッシュ |
| 家のWi-FiだけNG | ルーター不調、DNS不安定、回線混雑、IPv6経路、Wi-Fi干渉 | ルーター再起動→別回線（テザリング）→DNS変更 |
| 特定サイトだけNG | DNSが古い、サイト側混雑/障害、拡張機能のブロック、HSTS/証明書周り | DNSフラッシュ→拡張停止→別回線→時間を置く |
| 会社だけNG | 社内プロキシ、フィルタリング、FW/WAF、ゼロトラスト系の制限 | プロキシ確認→社内手順で例外申請→情シスへ共有 |
| VPN導入直後 | VPN出口の混雑、DNS、分割トンネル、MTU | VPN OFF→出口変更→DNS変更→MTU/経路の見直し |
この表のとおり、切り分けに効く順番で進めれば、最短で「直る／原因が分かる／相手側だと判断できる」のいずれかに到達できます。次章から具体手順です。
端末側でERR_CONNECTION_TIMED_OUTを直す手順
まずは再読み込みとブラウザ切替で切り分け
最初に行うのは「失敗しても影響がほぼゼロ」な操作です。ここで直れば最短ですし、直らなくても切り分けの材料が集まります。
再読み込み
まず通常の再読み込み
次に強制再読み込み（WindowsならCtrl+F5が目安）
ブラウザが古いデータを見ているだけなら、これで解決する場合があります。
ブラウザを完全終了して再起動
タブを閉じるだけでなく、ブラウザ自体を終了し、タスクに残っていないか確認します。残っていると古いセッションが温存されることがあります。別ブラウザで同じURLを開く
ChromeでダメならEdge、EdgeでダメならFirefoxなど。別ブラウザで開く → 元のブラウザ側（拡張機能・サイトデータ）の疑いが強い
どれもダメ → ネットワーク設定（DNS/プロキシ/VPN）や回線側へ進む
シークレットモードで開く
シークレットでは拡張機能が無効（または制限）になり、キャッシュ/Cookieの影響も減ります。シークレットで開く → 拡張機能かサイトデータが原因である可能性が高い
この段階で「どの方向を疑うべきか」がかなり絞れます。次は、拡張機能とキャッシュを整理します。
キャッシュと拡張機能を整理する
“とりあえず全部消す”は手っ取り早そうで、実は遠回りになりやすいです。ログイン状態が消え、二要素認証が必要になり、復旧に時間がかかることがあります。おすすめは、次の順で「影響を小さく」進めることです。
拡張機能を一時停止（特に広告ブロック、セキュリティ、VPN系）
ブロック系拡張は、特定サイトの通信だけを止めることがあります。まず全停止して再試行
直ったら、1つずつ戻して“犯人”を特定
こうすると、今後も同様のトラブルを避けられます。
当該サイトのCookie/キャッシュだけ削除
ブラウザ設定で「サイトごとのデータ削除」ができる場合、まずそれを使います。当該サイトのCookieが壊れている
ログインセッションがループしている
古いリダイレクト情報が残っている
といったケースで改善します。
全体のキャッシュ削除は最後に
どうしても改善しない場合に限り、期間を選んでキャッシュを削除します。Cookieまで消すとログインが全滅するので、必要性を見極めます。
あわせて、次も意外と効きます。
ブラウザの更新：古いバージョンの不具合や証明書周りで問題が出ることがあります。
拡張機能の更新/削除：更新が止まった拡張はトラブルの温床になりがちです。
次は、プロキシ/VPNを確認します。ここが原因だと、タイムアウトが頻発します。
プロキシとVPNを確認する
プロキシやVPNは「通信経路を変える」仕組みです。経路が変わるということは、途中に詰まりポイントが増えるということでもあります。結果として、特定サイトだけタイムアウトするケースが起きます。
VPNを使っている場合
いったんVPNをOFFにして同じURLを開く
直った場合は、次のどれかが原因になりやすいです。
VPN出口（国/地域）の混雑や制限
VPNのDNS設定（VPN内DNSが不安定）
分割トンネル設定の不整合（特定ドメインだけ変な経路になる）
直った後の対処としては、
出口（リージョン）を変える
VPNアプリの「DNS保護」「広告ブロック」機能を一時OFFにして相性を見る
VPNを必要な作業時だけ使う
といった方向が有効です。
Windowsのプロキシ設定
会社PCや一部セキュリティソフトで、自動プロキシ設定が入ることがあります。自覚なく有効化されている場合もあります。自動構成スクリプトが設定されていないか
「プロキシサーバーを使用する」がONになっていないか
を確認し、社内ルールに従って調整します（勝手にOFFにすると業務システムに入れなくなることもあります）。
ブラウザ側のプロキシ系拡張
ブラウザ拡張でプロキシを挟んでいる場合も、OFFで比較してください。
プロキシ/VPNが原因なら、OFFにした瞬間にスパッと直ることが多いです。直らない場合はセキュリティソフト・ファイアウォール、あるいはDNSへ進みます。
セキュリティソフトとファイアウォールを安全に確認する
セキュリティソフトやファイアウォールは「怪しい通信を止める」役割があります。誤判定があると、正常なサイトでも通信が遮断され、結果としてタイムアウトになります。ただし、ここは扱いに注意が必要です。無効化はリスクがありますし、戻し忘れが起きやすいからです。
安全な優先順位は次のとおりです。
ブロックログ（履歴）を確認する
“このサイトを止めた”記録が出ていれば原因はほぼ確定です。許可（例外）にすれば改善します。自動復帰する一時停止で比較する
「5分だけ停止」など、時間で自動復帰する機能があるならそれを使い、短時間で検証します。例外設定（ホワイトリスト）で許可する
無効化し続けるのではなく、対象ドメインだけ許可するのが基本です。どうしても必要な場合のみ、短時間だけ無効化して即復帰
それでも原因が分からない場合の最終手段です。
危険操作をするときのチェックリスト
作業前に、元へ戻す手順（画面やスイッチの位置）を確認した
検証は1〜2分など短時間に限定する
終了したら必ず再有効化し、状態を再確認した
直った場合でも“無効化し続ける”のではなく、例外設定へ切り替えた
会社端末の場合、情シスのルールに反しない範囲で実施した（不明なら相談）
ここまでやって端末側の要因が薄い場合、ネットワークスタック（DNSやTCP/IP周り）に進みます。多くのケースでここが決め手になります。
PCのネットワークスタックをリセットする
タイムアウトの原因が「名前解決（DNS）」「古い経路情報」「一時的な通信不整合」にある場合、ネットワーク周りのリセットが非常に有効です。ポイントは、影響が小さい順に進めることです。
PC再起動
侮れません。バックグラウンドのネットワーク処理が詰まっている場合、再起動だけで直ることがあります。DNSキャッシュをフラッシュ
「特定サイトだけ開けない」「移転直後っぽい」「昨日まで開けたのに急に」というときに特に効きます。IPアドレス更新
DHCP周りが不安定な場合に効くことがあります。ネットワークリセット（最終手段）
保存済みWi-FiやVPN設定が消える場合があるため、最後に実施します。
WindowsでDNSをフラッシュする手順
管理者としてコマンドプロンプト、またはPowerShellを開きます。
次を実行します。
ipconfig /flushdns
ブラウザを完全終了して再起動し、対象サイトへ再アクセスします。
DNSフラッシュは比較的安全で、まず試す価値があります。直った場合は「DNSが古い情報を持っていた」「DNS応答が不安定だった」可能性が高いので、次章のDNS変更も検討すると再発が減ります。
macOSでDNSキャッシュを削除する目安
macOSはバージョンによってコマンドが異なることがありますが、代表例として次の形がよく使われます。
sudo killall -HUP mDNSResponder
実行後はブラウザを再起動して再試行してください。もしコマンドで不安がある場合は、Mac自体の再起動でも一定の効果があります。
ネットワーク設定でERR_CONNECTION_TIMED_OUTを直す手順
ルーターと回線を切り分ける
回線側が疑わしいときは、「どこが悪いか」を分けて考えるのが最短です。自宅の場合、ざっくり以下の構成になっています。
端末（PC/スマホ）
Wi-Fi（電波、干渉、距離）
ルーター（設定、性能、熱、ファームウェア）
回線（プロバイダ、混雑、障害、経路）
切り分けは次の順で行うと効率的です。
ルーター再起動
電源を抜いて30秒待って入れ直します。単なる再起動より、完全に電源を落とすほうが改善することがあります。直ったが再発する → ルーターの不安定、DNS不安定、負荷、熱、ファームウェアが疑わしい
Wi-Fiではなく有線LANで試す（可能なら）
有線で直るなら、Wi-Fi干渉や電波品質が原因の可能性があります。ルーターの置き場所、周囲の障害物、電子レンジなど干渉源の影響も考えます。
別回線で試す（テザリングや別Wi-Fi）
ここが決定打になりやすいです。別回線で開く → 自宅回線/ルーター/DNSが濃厚
別回線でもダメ → 相手サイト側の可能性が上がる
急いでいる場合は、まずテザリングで作業を完了させ、落ち着いてから自宅回線の原因を詰めるのが現実的です。
DNSをフラッシュして名前解決を更新する
DNSは「ドメイン名（例：example.com）をIPアドレスに変換する仕組み」です。ここが古い情報を持っていたり、応答が不安定だったりすると、ブラウザは正しい場所へ行けず、結果としてタイムアウトになります。
DNSフラッシュが効く典型例は次のとおりです。
サイト移転やサーバー変更があった（運営側の変更）
以前は開けたのに、急に特定サイトだけ開けない
別の端末では開けるが、自分のPCだけダメ
時間を置くと直ることがある（キャッシュの更新待ちに近い状態）
Windowsの手順は前章のとおりです。フラッシュ後は、ブラウザだけでなくPCの再起動も組み合わせると改善することがあります。
DNSサーバーを変更する
DNSフラッシュでも改善しない、あるいは「直ったけれど再発する」場合、DNSサーバー自体の変更が有効になることがあります。DNSは、ルーターやプロバイダが自動的に指定していることが多いですが、状況によっては不安定になることがあります。
変更の基本方針は次のとおりです。
まず端末側で変更：戻しやすく、影響範囲がその端末に限られます。
改善が明確ならルーター側も検討：家中の端末に効果を広げられますが、影響範囲が大きいので慎重に。
DNS変更後は、次の観点で確認します。
対象サイトが安定して開くようになったか
他のサイトやサービスが遅くなっていないか
会社・学校のルールに抵触しないか（社内端末は要注意）
また、DNS変更と合わせて「DNSフラッシュ」「ブラウザ再起動」を行うと、結果がはっきり出ます。
IPv6やMTUが疑わしいときの確認ポイント
頻度は高くありませんが、DNSやプロキシを見直しても改善しない場合、IPv6やMTUの相性・経路問題が関わることがあります。難しく感じるかもしれませんが、見分けのポイントを押さえると判断しやすくなります。
IPv6が疑わしいサイン
特定回線・特定ルーターでだけ発生しやすい
別回線（テザリング）だと安定
時間帯や混雑で揺れやすい
IPv6を一時的に無効化して比較すると、原因の当たりを付けられることがあります（ただし環境によっては推奨されない場合もあるため、社内端末では情シスに確認が安全です）。
MTUが疑わしいサイン
VPN接続時だけ発生する
一部の大きいデータ（画像が多いページ、管理画面）で顕在化する
“読み込み中”が長く続いてタイムアウトになる
MTUは通信の単位サイズに関わり、相性が悪いと再送が増え、タイムアウトに繋がります。VPNやルーター設定の見直しが必要になるため、無理に触らず、切り分け結果を持ってサポートに相談するのが安全な場合もあります。
ここまで試しても改善しない場合は、「相手サイト側の可能性」や「社内ネットワークの制限」も再確認し、次章の運営者向け観点・問い合わせの仕方へ進むと解決が早くなります。
サイト運営者がERR_CONNECTION_TIMED_OUTを防ぐチェック
サーバー負荷とタイムアウト設定を確認する
閲覧者の画面にERR_CONNECTION_TIMED_OUTが出るとき、運営者側では次のような問題が起きている可能性があります。
サーバー負荷（CPU/メモリ/ディスクI/O）が高い
高負荷時は、接続はできても応答が返せず、結果としてタイムアウトします。アクセス集中だけでなく、バッチ処理、バックアップ、ログ肥大化、DB負荷などでも発生します。アプリケーションの応答が遅い
WordPressならプラグイン、テーマ、DBクエリ、外部API呼び出しが遅いなど。
「ページ生成に時間がかかる」状態が続くと、ブラウザ側が待ちきれずタイムアウトになり得ます。リバースプロキシやWebサーバーのタイムアウト設定が短い
Nginx、Apache、ロードバランサ、アプリサーバーのタイムアウトが噛み合っていないと、途中で切れてタイムアウトに見えることがあります。
運営者側での初動としては、まず「監視の応答時間」「アクセスログ」「エラーログ」「スロークエリ」を見て、どこで遅れているかを掴むのが近道です。タイムアウト値を伸ばすだけで一時的に改善することもありますが、根本は“遅い原因”の除去です。
DNSの変更・伝播とキャッシュの影響を理解する
サイト移転やDNS変更直後に「一部の人だけ開けない」「特定地域だけ遅い」などが起きるのは珍しくありません。DNSは各所でキャッシュされるため、切り替えが一斉に起きないからです。
運営者として押さえたいポイントは次のとおりです。
TTL（キャッシュ期間）を事前に短くする運用
予定された切り替えなら、事前にTTLを短縮しておくと、切替後に古いIPを引く人が減ります。切替後のトラブル対応テンプレを用意する
閲覧者向けに「別回線で試す」「DNSフラッシュ」「時間を置く」などを案内できると、問い合わせが減り、復旧までの不安も軽減できます。キャッシュの影響を前提に告知する
“一部環境で反映に時間がかかる”を明記しておくと、クレーム化しにくくなります。
閲覧者側でできること（DNSフラッシュなど）と、運営者側でできること（TTL運用、旧サーバーの並行稼働など）をセットで考えると、トラブルが起きても収束が早くなります。
CDNやWAF利用時のタイムアウトも確認する
CDNやWAFを使っている場合、ユーザーからは「サイトに繋がらない」に見えても、実際には“CDNとオリジンサーバー間”で通信が詰まっていることがあります。典型的には、CDN側のエラーコード（例：522/524/504など）として表面化することがあります。
運営者が確認したい代表ポイントは次のとおりです。
オリジンのファイアウォールがCDNのIPを弾いていないか
WAFやFWのルール更新後に起きやすいです。ブロックログを確認し、必要な許可設定を行います。接続上限やKeep-Alive設定の不整合
同時接続数が多い状況で、オリジン側が捌けずにタイムアウトすることがあります。オリジン側の応答遅延（DBや外部API）
CDNのキャッシュが効かないページ（管理画面、動的ページ）で顕在化しやすいです。
CDN/WAFは便利な一方、問題が起きたときに「どこで詰まっているか」が見えづらくなります。監視を“外形（ユーザー目線）”と“オリジン内（サーバー目線）”の両方で持つことが重要です。
監視と一次切り分けのテンプレ
障害対応の速さは、平時にどこまで“確認の型”が整っているかで決まります。最低限、次のテンプレがあるだけで、タイムアウト系のトラブルが大幅に捌きやすくなります。
外形監視（複数リージョン）
「地域限定の問題」「特定ISPの問題」「全体障害」を切り分ける材料になります。サーバー監視
CPU/メモリ/ディスクI/O/帯域、プロセス数、接続数など。タイムアウトは負荷と相関しやすいです。アプリ監視
遅いリクエスト、エラー率、DB遅延、外部APIの応答時間。原因箇所の特定に直結します。一次回答テンプレ
例：現在把握している状況（影響範囲、再現条件）
回避策（別回線、時間を置く、キャッシュ等）
次報の予定
問い合わせ時に必要な情報（時刻、環境、URL、エラー表示）
運営者向けチェックリスト
直近でDNS変更、サーバー移転、証明書更新、WAFルール更新をしていないか
応答時間が悪化していないか（監視・ログ）
WAF/FWのブロックログに異常がないか
CDN利用時、オリジンへ直接到達できるか（内部確認）
重い処理や外部API待ちが発生していないか（スロークエリ等）
障害の一次回答テンプレで、ユーザーに回避策を提示できるか
運営者側の観点を押さえると、閲覧者として直らない場合でも「相手側かもしれない」と納得しやすくなり、不要な設定変更を避けられます。
ERR_CONNECTION_TIMED_OUTに関するよくある質問
特定のサイトだけ開けないのはなぜですか
特定サイトだけ開けない場合、原因は大きく次の3群に分かれます。
DNSやキャッシュが古い/壊れている
サイトが移転した、CDN構成が変わった、または端末側が古い情報を保持していると、間違った行き先へ行ってタイムアウトします。
→ DNSフラッシュ、当該サイトのデータ削除が有効です。そのサイト側が混雑・障害・メンテナンス
こちらが何をしても直らないことが多いです。
→ 別回線で確認、時間を置く、公式情報の確認が有効です。拡張機能やセキュリティがそのサイトだけブロック
広告ブロック、追跡防止、セキュリティ拡張、VPNのフィルタ機能などが関与します。
→ シークレット、拡張機能停止、セキュリティログ確認が有効です。
最短の切り分けは、スマホ（モバイル回線）で同じURLを開けるかです。ここで「相手側か自分側か」の方向性が一気に固まります。
スマホでは開けるのにPCだけ開けないのはなぜですか
このパターンは、PC側の要因が濃厚です。よくある順に並べると次のとおりです。
拡張機能のブロック（広告ブロック/セキュリティ/VPN系）
プロキシ設定や社内ネットワーク設定
DNSキャッシュの不整合
セキュリティソフトの誤判定
ブラウザのキャッシュ/Cookie不整合
最短ルートは次の順番です。
シークレットで開く
拡張機能を停止して開く
VPN/プロキシをOFF（または社内設定を確認）
DNSフラッシュ
可能なら別ブラウザでも検証
これで多くの場合、原因の当たりが付きます。直った操作が見つかったら、それを“恒久的に安全な形”へ落とし込みます（例：拡張は例外設定、VPNは出口変更など）。
DNS変更は安全ですか
一般的には安全に使えますが、環境によって注意点があります。特に「会社・学校の端末」「保護者制限」「フィルタリング」などがある場合は慎重に判断してください。
社内ポリシー違反になる可能性
指定DNS以外を禁止している環境もあります。勝手に変えると業務システムに入れなくなったり、監査上問題になったりすることがあります。フィルタリングの挙動が変わる可能性
DNSベースのフィルタを使っている場合、DNSを変えるとブロック/許可の挙動が変わります。家庭でも同様です。一部サービスで到達性が変わることがある
DNSの応答や経路の違いで、体感速度が変わることがあります。
不安な場合は、まず 端末側だけ一時的に変更し、元の設定をメモしておき、いつでも戻せる状態で比較してください。改善が明確なら、恒久設定として採用する価値があります。
復旧しない場合、どこへ連絡すべきですか
切り分け結果によって、相談先を間違えないことが重要です。次の基準で判断するとスムーズです。
自宅回線・ルーターが濃厚
回線事業者／プロバイダ
ルーターメーカー（頻繁な再起動が必要、特定機種で不安定など）
伝えるべき情報：発生時刻、再発頻度、別回線（テザリング）ではどうか、ルーター再起動で改善するか。
会社ネットワークが濃厚
情シス／ネットワーク管理者
伝えるべき情報：対象URL、発生時刻、社外回線では開けるか、プロキシ/VPNの有無、他社員でも再現するか。
相手サイト側が濃厚
サイト運営者（問い合わせフォーム、サポート）
伝えるべき情報：URL、発生時刻、利用環境（OS/ブラウザ/回線）、エラー表示、スクリーンショット（可能なら）。
問い合わせ時のテンプレとして、最低限これだけあると話が早いです。
発生日時（可能なら複数回）
端末（OS、ブラウザ名とバージョン）
回線（自宅Wi-Fi、会社、モバイル回線など）
別端末・別回線で再現するか
実施済みの対処（拡張OFF、VPN OFF、DNSフラッシュ、ルーター再起動など）
ERR_CONNECTION_TIMED_OUTの再発防止と次の行動
再発を減らす設定と習慣
直った後こそ、再発を減らすために“原因に近いところ”を整えておくと効果的です。
ルーターのファームウェアを更新する
ルーターの不具合や相性は、更新で改善することがあります。再起動でしのいでいるなら、更新は優先度が高いです。ブラウザ拡張を最小限にする
便利な拡張ほど、通信を加工・遮断します。数が増えるほど原因の切り分けが難しくなります。
「必要なときだけON」「信頼できるものだけ残す」という運用が安定します。VPNは用途を分ける
常時VPNはトラブルの引き金になりがちです。外出先の安全確保が目的なら“必要なときだけ”
仕事用途なら“指定された設定で”
と用途を分け、出口変更やDNS設定を見直せるようにしておくと再発が減ります。
DNSを安定したものに固定し、変更履歴を残す
DNS変更で直った場合、元に戻すと再発することがあります。設定したDNSをメモしておくと、将来のトラブル時にすぐ比較できます。“相手側っぽい”と判断できる材料を持つ
別回線（テザリング）で開けるか、別端末でどうか、という切り分けを習慣化すると、不要な設定変更を避けられます。
社内・家庭での共有用チェックリスト
最後に、同じ現象が起きたときに迷わないためのチェックリストをまとめます。家族や同僚にもそのまま共有できます。
別のサイトは開けるか（全体障害か、特定サイトか）
スマホのモバイル回線で同じURLを開けるか（相手側か自分側か）
別ブラウザ、シークレットで開けるか（拡張/キャッシュの影響）
VPN/プロキシを切って改善するか（経路の問題）
DNSフラッシュで改善するか（名前解決の不整合）
ルーター再起動、別回線で改善するか（回線側の問題）
ここまででダメなら相手側の可能性を見て、障害情報や問い合わせへ切り替える
この順番は、影響が小さく、切り分けに効き、復旧率が高い流れです。焦って設定を大きく変える前に、まずこの手順で「どこが原因か」を掴んでください。直らない場合でも、原因の当たりが付けば相談先が明確になり、解決までの時間が短くなります。