Webサイトを開こうとした瞬間、画面に表示される「ERR_CONNECTION_REFUSED」。
昨日まで普通に見られていたページが突然開けなくなり、「回線の問題なのか」「自分のPCが壊れたのか」「相手のサイトが落ちているのか」と不安になった経験はございませんでしょうか。
ERR_CONNECTION_REFUSEDは、原因が一つに限られないため、検索しても「キャッシュを消す」「DNSを変える」「セキュリティを切る」といった対処法が羅列されるだけで、結局どれを試せばよいのか分からないという状態に陥りがちです。誤った順番で設定を変更すると、直らないどころか、業務に支障が出たり、セキュリティ上のリスクを高めてしまうこともあります。
本記事では、ERR_CONNECTION_REFUSEDを「相手側の問題」「回線の問題」「端末設定の問題」「DNSの問題」「サーバーやポートの問題」という5つの観点で整理し、影響の小さい確認から順に切り分ける最短手順を丁寧に解説いたします。一般的な利用者の方はもちろん、Windows環境の方、社内ネットワーク利用者、localhostで発生している方まで、状況別に迷わず進められる構成としています。
「今すぐ原因を知りたい」「余計な設定変更はしたくない」「直らなかった場合に何を伝えればよいか知りたい」という方は、ぜひ上から順に読み進めてください。本記事を最後までお読みいただくことで、ERR_CONNECTION_REFUSEDに対して冷静に、再現性のある対処ができる状態になることを目的としています。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
ERR_CONNECTION_REFUSEDとは何か
表示されるタイミングと意味
ERR_CONNECTION_REFUSEDは、ブラウザが指定したサーバー（IPアドレス）とポート（例：80/443など）に接続しようとした際に、相手側から接続を受け付けない応答が返る、もしくは接続が成立しない状態を指すエラーです。Chromeでは「このサイトにアクセスできません」と併記され、「ERR_CONNECTION_REFUSED」と表示されます。
重要な点は、ERR_CONNECTION_REFUSEDが示しているのは「接続できない」という“現象”であり、原因そのものではないということです。たとえば、同じ「開けない」でも以下は別問題です。
相手のサーバーが停止している（そのポートで待ち受けていない）
ファイアウォールが接続を遮断している
プロキシやVPNが通信経路を変えて拒否されている
DNSが古いIPを参照し、存在しない先に接続している
ローカル開発で、アプリが起動していない/ポートが違う
このため、手当たり次第に設定を触るよりも、まず「どこで拒否されているか」を切り分ける方が最短で復旧できます。また、切り分けは「影響が小さい操作から順に行う」ことが安全面でも合理的です。
なお「拒否」と表示されると、つい「自分がブロックされた」「アクセス権がない」と考えがちですが、実際には単純な設定ミスや一時障害のことも少なくありません。焦らず、再現条件と範囲（全サイトか、特定サイトか、特定端末だけか）を押さえることが第一歩です。
よくある発生パターン
ERR_CONNECTION_REFUSEDは、体感としては突然起きることが多い一方、原因はある程度パターン化できます。ここでは、実務上よく遭遇する典型を整理します。
特定サイトだけ開けない
例：A社サイトだけ拒否、他のサイトは問題なし
可能性：プロキシ/VPN/セキュリティソフトの遮断、DNSの不整合、相手側の障害や制限
すべてのサイトが開けない
可能性：回線断、ルーター不調、ネットワーク設定破損、端末のプロキシ設定不整合
スマホでは開けるがPCでは開けない
可能性：PCの拡張機能、プロキシ、VPN、セキュリティソフト、DNSキャッシュ
社内ネットワークのみで発生する
可能性：社内プロキシやフィルタ、ファイアウォール、ゼロトラスト製品、社内DNS
localhost（開発環境）で発生する
可能性：アプリ未起動、待ち受けポート違い、Docker/WSL/仮想化のポート公開不一致、hosts誤設定
これらを踏まえると、最初にやるべきことは「自分だけの問題か」「回線の問題か」「相手側の問題か」を早く確定させることです。次章では、そのための最短手順を示します。
ERR_CONNECTION_REFUSEDを最短で切り分ける手順
本章は、原因を推測で決め打ちせず、短時間で大分類を確定させるための手順です。ポイントは次の3つです。
影響が小さい操作から順に実施する
“別条件で再現するか”を確認し、原因範囲を絞る
直らない場合に備えて「何を試したか」を残す
他端末と他回線で相手側かを判定
最初の切り分けは、相手側の問題（サイトやサーバー）か、自分側の問題（端末/回線）かを判定することです。これが確定すると、以降の作業が無駄になりにくくなります。
以下を上から順に確認してください。
スマホで同じURLを開く（同じWi-Fiのままでよい）
スマホでも開けない → 相手側障害の可能性が上がります
スマホでは開ける → PC側の要因が濃厚です
PCを別回線につなぐ（可能ならテザリング）
別回線で開ける → 自宅ルーターや社内ネットワーク側の可能性が上がります
別回線でも開けない → PC端末側（設定/ソフト/OS）の可能性が上がります
同一回線で別のPC（またはタブレット）を試す
別端末も開けない → 回線/ルーター/ネットワーク側
別端末は開ける → 元のPC固有の問題
この3点だけで、「相手側」「回線側」「端末側」がほぼ決まります。特に業務で急ぐ場面では、先にここをやっておくと、キャッシュ削除や設定変更を延々と繰り返す事態を避けやすくなります。
加えて、以下の観測点も有効です。
同じドメインの別ページは開けるか（トップは不可だが下層は可、等）
https:// と http:// を取り違えていないか（ブックマークやコピペの癖で起きます）
時間帯で変動するか（夜だけ不可などは回線混雑・社内制限の可能性）
別ブラウザとシークレットで拡張機能を疑う
PC側要因が濃厚になったら、次はブラウザ要因を短時間で潰します。ここでの狙いは「Chrome本体の設定や拡張機能が原因か」を切り分けることです。
実施順は次のとおりです。
別ブラウザで同じURLを開く（例：Edge / Firefox）
別ブラウザで開ける → Chrome側の要因（拡張機能、キャッシュ、プロファイル）が疑わしいです
別ブラウザでも不可 → OS/ネットワーク/セキュリティ側が疑わしいです
Chromeのシークレットウィンドウで開く
シークレットで開ける → Cookieや拡張機能の影響が疑わしいです
シークレットでも不可 → 端末全体のプロキシ/VPN/DNS/セキュリティの可能性が上がります
拡張機能を一時停止して再確認
特に、広告ブロック、セキュリティ、VPN、プロキシ関連の拡張は通信に干渉することがあります。
一つずつ無効化して原因を特定できると、再発防止につながります。
ここで注意点があります。拡張機能の停止は比較的安全ですが、業務端末の場合、会社指定の拡張を無効化するとポリシー違反になることがあります。社内ルールがある場合は、無理に変更せず管理者へ相談してください。
DNSと名前解決を疑う基準
「PCだけだめ」「特定サイトだけだめ」という症状は、DNSの不整合でも起きます。DNSは、ドメイン名（例：example.com）をIPアドレスに変換する仕組みです。DNSが古いIPを握ったままだと、すでに廃止されたサーバーに接続しにいき、結果として接続拒否になることがあります。
DNSを疑うべき基準は、次に当てはまる場合です。
以前は開けていたのに、急に開けなくなった
VPNやプロキシを切り替えた直後からおかしい
回線を変えると直る（自宅だめ、テザリングOKなど）
同じドメイン配下のサイトがまとめてだめ（例：api.example.com も www.example.com も不可）
この場合、後述の「DNSキャッシュをフラッシュする」は優先度が高い対処です。影響も小さく、失敗しても戻しやすいため、切り分けとして非常に有効です。
端末側でERR_CONNECTION_REFUSEDを直す方法
本章では、端末側（特にブラウザ・設定・セキュリティ）に起因する場合の対処を、安全な順にまとめます。ポイントは「直ったら、どこが原因だったか」を可能な範囲で特定し、同じ操作を繰り返さないことです。
キャッシュとCookieのクリア
影響度：低〜中（ログイン状態が消える場合があります）
キャッシュやCookieが原因の場合、症状は「特定サイトだけおかしい」「突然ログイン周りでおかしくなった」などになりがちです。まずはキャッシュの削除を試し、必要に応じてCookieにも範囲を広げます。
推奨手順は次のとおりです。
Chromeの設定を開きます
「プライバシーとセキュリティ」→「閲覧履歴データの削除」を開きます
まずはキャッシュを削除します
改善しない場合は、対象サイトのCookieを削除します（可能ならサイト単位）
Chromeを再起動し、再度アクセスします
チェックリスト（安全に進めるための要点）：
業務サイトの場合、削除後に多要素認証が必要になる可能性を把握している
保存しているパスワードや認証アプリ等、再ログイン手段がある
まずはキャッシュのみ、必要ならCookieへ段階的に実施する
プロキシとVPNの確認
影響度：中（社内端末では要注意）
プロキシやVPNは通信経路そのものを変えるため、ERR_CONNECTION_REFUSEDに直結しやすい要因です。特に、次のような状況では優先的に確認すべきです。
会社のVPNを切った/入れた直後から起きた
在宅と出社で症状が変わる
特定の国/地域のサービスだけ開けない
会社が指定するプロキシ設定がある
確認手順（安全な範囲）：
VPNを利用している場合：一時的に切断し、対象URLを確認します
プロキシ設定がある場合：自動構成スクリプトや手動設定が正しいか確認します
変更を加えたら、元に戻せるように現状設定を控えておきます
注意点として、社内ネットワークでは「プロキシ必須」「VPN必須」の環境があり、勝手に外すと業務システムに接続できなくなるだけでなく、規程上問題となる場合があります。社内ルールがある場合は、切り分けの結果（社外回線なら開ける等）を添えて管理者へ相談するのが安全です。
セキュリティソフトとファイアウォールの確認
影響度：中〜高（安易な無効化は避け、例外確認を優先します）
セキュリティソフト（エンドポイント保護、URLフィルタ、Web保護）やファイアウォールは、接続をブロックすることで「拒否」に見える状態を作ります。とくに、以下は典型です。
URLフィルタが誤判定してブロック
証明書検査（SSLインスペクション）で接続が崩れる
社内EDRが特定の通信先を遮断
Windows Defender Firewall やサードパーティFWのルールが変わった
推奨する進め方は、無効化より先にログやブロック履歴、例外設定の有無を確認することです。
安全な確認チェックリスト：
ブロック履歴（ログ）に対象ドメインが記録されていないか
最近のアップデート後に発生していないか
同僚端末では開けるか（社内端末の場合）
例外設定（許可リスト）で回避できるか
どうしても切り分けのために一時無効化する場合は、次を守ってください。
無効化の時間を最短にする
対象サイトが信頼できることを確認する（不審なURLでは実施しない）
無効化したら必ず戻す
業務端末は原則、管理者へ相談して実施する
WindowsでERR_CONNECTION_REFUSEDを直す方法
Windows環境では、DNSキャッシュやネットワーク構成の再取得が効く場面が多くあります。本章は、Windowsユーザーが迷わず実行できるよう、影響の小さい順に手順化します。コマンド操作に不安がある場合でも、上から順に実施すれば切り分けとして成立します。
DNSキャッシュをフラッシュする
影響度：低（推奨）
DNSキャッシュのフラッシュは、問題切り分けとして非常に優秀です。効果がある場面は「特定サイトだけ」「回線を変えると直る」「以前は開けた」のようなケースです。
手順：
「スタート」を右クリックし、「ターミナル（管理者）」または「コマンドプロンプト（管理者）」を開きます
次を実行します
ipconfig /flushdns
Chromeをいったん終了し、再起動します
対象URLへアクセスします
補足：
実行後に「DNS リゾルバー キャッシュは正常にフラッシュされました」と表示されれば成功です。
一時的に最初のアクセスが遅くなることがありますが、通常は問題ありません。
ネットワーク設定の再取得
影響度：中（ネットワークが一時切断されます）
DNSフラッシュで改善しない場合、IP構成の再取得が有効なことがあります。特に、Wi-Fiの切り替え、スリープ復帰後、VPNの切替後に発生した場合は候補に入ります。
手順（コマンドで実施する場合）：
管理者のコマンドプロンプトを開きます
次を順に実行します
ipconfig /releaseipconfig /renew
Wi-Fiを一度オフ→オンします（有線なら抜き差しでも可）
ルーターを再起動できる環境なら再起動します
再度アクセスします
補足：
社内環境では
release/renewの挙動が制限されることがあります。うまくいかない場合は、実行結果（エラー文）を控えて管理者へ共有してください。
社内ネットワークでの注意点
社内ネットワークでは、個人環境よりも要因が増えます。プロキシ、フィルタ、ゼロトラスト、DNS、端末管理ポリシーなどが重なり、個々の操作で直らないこともあります。この場合、管理者へ渡す情報の質が復旧速度を大きく左右します。
社内向けに整理しておくべき情報は次のとおりです。
発生日時（できれば複数回）
対象URL（ドメイン単位も）
社内回線（Wi-Fi/有線）で差があるか
社外回線（テザリング等）だとどうなるか
端末情報（端末名、Windowsバージョン、ブラウザ）
VPN接続の有無、プロキシ設定の有無
セキュリティソフト名（分かる範囲）
試した手順（DNSフラッシュ、別ブラウザ、シークレット等）
この「整理された情報」があるだけで、管理者側はネットワークログやポリシー変更履歴と突き合わせやすくなります。
サーバー側でERR_CONNECTION_REFUSEDが起きる原因と対策
本章は、運用担当者や開発者、あるいは「自社のサイトが開けない」と報告を受けた方を想定しています。ユーザー側対処が一巡しても改善しない場合、サーバー側（待ち受け・FW・構成）に原因があることは珍しくありません。
また、ユーザー側の報告を受けた際は、「どの端末・どの回線・どの地域から」「いつから」「再現性はあるか」を確認するだけでも、障害範囲の推定がしやすくなります。
待受プロセスとポートの不一致
接続拒否の最頻出は、そのIP/ポートでアプリが待ち受けていないケースです。たとえば、Webサーバーが落ちた、アプリがクラッシュした、サービスが別ポートで起動している、などです。
確認観点（例）：
アプリケーションプロセスが起動しているか
リバースプロキシ（Nginx/Apache等）が起動しているか
待ち受けポートが設計どおりか（80/443/任意ポート）
ロードバランサ配下なら、ターゲットが正常か（ヘルスチェック）
コンテナ運用なら、コンテナの公開ポートとアプリの待ち受けが一致しているか
ローカル開発なら、起動コマンドや環境変数でポートが変わっていないか
運用上のコツとしては、「ユーザーがアクセスしているURL（スキーム/ドメイン/ポート）」と「実際の待ち受け（IP/ポート）」を紙に書いて突合することです。思い込みで確認すると、HTTPS/HTTPやポート違いを見落としやすいためです。
ファイアウォールとアクセス制御
次に多いのが、ファイアウォールやアクセス制御で拒否されるケースです。例としては以下があります。
OSレベルのファイアウォール（iptables、Windows FWなど）
クラウドのセキュリティグループ/ネットワークACL
WAFやCDNの制限
社内ネットワークからのみ許可する制御
監査対応で一時的にポートを閉じた
確認観点：
最近、FWルールやセキュリティグループを変更していないか
許可元IPが想定どおりか（オフィスのグローバルIP変更など）
監視やアラート（拒否ログ、WAF検知）に変化がないか
ロードバランサの背後（バックエンド）まで疎通できているか
ユーザーから「昨日まで開けた」という情報がある場合は、直近の変更（デプロイ、FW変更、証明書更新、DNS切替）を時系列で追うと、原因に最短で到達できます。
HTTPSとHTTPの取り違え
意外に多いのが、スキームやポートの取り違えです。たとえば、以下のような事故が起きます。
HTTPS（443）でアクセスされる想定なのに、実体はHTTP（80）しか開いていない
HTTP→HTTPSリダイレクトの設定変更で到達できなくなった
検証環境でHTTPSを用意しておらず、HTTPSアクセスが拒否される
CDNやLB側で終端している前提が崩れ、バックエンドへ不正な経路で接続している
対処の要点は、「アクセスされる入口」と「終端（TLS終端、プロキシ、バックエンド）」を図にして、どこで拒否が起きているかを明確にすることです。とくにLB/CDNが絡む構成では、バックエンドが直接アクセスされてしまい拒否されている、というケースもあります。
ERR_CONNECTION_REFUSEDが直らないときの対処
最後に、ユーザー側でも運用側でも「これ以上は自分だけでは難しい」という局面に備え、エスカレーション（相談・依頼）を最短化するための型をまとめます。直らないこと自体よりも、「情報不足で調査が止まる」ことが復旧を遅らせるためです。
管理者やISPに渡す情報テンプレ
以下を埋めて渡すと、調査側はログや構成変更履歴と突合しやすくなります。可能ならスクリーンショットも添付してください。
発生日時：
対象URL：
端末：Windows/macOS、端末名（社内端末なら）
ブラウザ：Chrome/Edge等、バージョン（分かる範囲）
回線：自宅Wi-Fi/社内/モバイル/テザリング
VPN：使用有無、切替有無
プロキシ：使用有無（自動/手動）
再現性：毎回/時々/特定時間帯
他端末：スマホでは開けるか、別PCではどうか
試したこと：別ブラウザ、シークレット、キャッシュ削除、DNSフラッシュ、回線切替
画面表示：エラーメッセージ全文、エラーコード
このテンプレを使うだけで、相談先は「まず何を聞くべきか」を省略できます。結果として、復旧までの往復回数が減ります。
再発防止の設定見直し
復旧したあとに再発を防ぐには、「原因の可能性が高かった箇所」を軽くでも見直すことが有効です。すべてを完璧にする必要はありませんが、次の観点を押さえると、同種の障害に強くなります。
プロキシ/VPNの運用ルール
いつオンにするか、切替時に何が変わるか（DNSも変わる等）を把握します。
DNSの手動設定の有無
手動設定している場合、環境変更（在宅/出社）と相性問題が出ることがあります。
セキュリティソフトの例外運用
例外は属人化しやすいため、業務で必要なら管理者と合意し、記録を残します。
ブックマークのURL整備
http/https混在やポート指定ミスがあると、再発に見えます。必要なら整理します。
運用監視（運用側）
疎通監視だけでなく、ポート待ち受け・FW変更・証明書期限なども合わせて監視します。
再発防止は“特別な対策”ではなく、「次に同じことが起きたときの確認手順が短くなる状態」を作ることが目的です。
よくある質問
特定サイトだけERR_CONNECTION_REFUSEDになるのはなぜですか
特定サイトだけの場合は、相手側の障害のほか、端末側ではプロキシ/VPN/セキュリティソフトによる遮断、DNSキャッシュの不整合が代表的です。まず「スマホで同じWi-Fiのまま開けるか」「PCをテザリングにすると開けるか」を確認し、相手側か回線側かを切り分けると最短です。
スマホでは開けるのにPCだけだめな理由は何ですか
PC固有の要因（Chrome拡張機能、プロキシ設定、VPN、セキュリティソフト、DNSキャッシュ）が疑わしいです。手順としては、別ブラウザ→シークレット→拡張機能停止→DNSフラッシュの順で進めると、影響を抑えつつ原因を絞れます。
localhostでERR_CONNECTION_REFUSEDが出るのはなぜですか
localhostの場合は、基本的に「受け手がいない」ことが原因です。具体的には、アプリが起動していない、待ち受けポートが違う、Docker等のポート公開が一致していない、hosts設定が誤っている、などです。URL（ポート番号を含む）と、アプリの待ち受け設定を突合するのが最短です。
DNSフラッシュは安全ですか
一般に安全な操作で、DNSキャッシュをクリアして名前解決をやり直すだけです。実行後に最初のアクセスがわずかに遅く感じる場合はありますが、通常は一時的です。変更が不安な場合でも、まず試しやすい対処です。
プロキシやVPNを切って良いですか
個人環境では切り分けとして有効ですが、社内端末ではルールに従ってください。切ることで業務システムに接続できなくなったり、セキュリティ要件に抵触する場合があります。社内環境であれば、社外回線（テザリング）での挙動を確認し、その結果を添えて管理者へ相談するのが安全です。
まとめ
ERR_CONNECTION_REFUSEDは、ブラウザが接続を確立できない状態を示すエラーであり、原因は相手側・回線側・端末側・DNS・サーバー/ポートなど複数に分かれます。最短で復旧するには、まず「スマホ・別回線・別端末」で相手側か自分側かを切り分け、次に「別ブラウザ・シークレット」でChrome要因を確認し、そのうえでDNSフラッシュやプロキシ/VPN、セキュリティの順に確認する流れが有効です。
また、直らない場合でも、管理者やISPへ渡す情報をテンプレ化しておくことで、調査の往復を減らし、復旧を早められます。環境によって原因が異なるため、復旧後は「どこまでが原因の可能性が高かったか」を軽く振り返り、再発時の確認手順を短縮できる状態にしておくことを推奨いたします。
