Windows 10/11で特定サイトだけ開けず、「Access Denied」「Reference #18」「Secure Connection Failed」が出る場合、表示を分けて調べます。Akamaiなどによるアクセス拒否と、ブラウザーが安全な接続を確立できない状態は同じ原因とは限りません。別回線なら開けても、ルーター故障が確定するわけではありません。
Reference #18が出た場合は番号全体と発生日時を保存し、別回線での比較結果を添えて対象サイトの運営者へ問い合わせます。
Reference #18・Access Denied・接続エラーの違い
| 表示例 | まず確認すること | 最初の対応 |
|---|---|---|
| Access Denied + Reference #18.xxxx | 拒否画面のURL、参照番号全体、日時 | 同じURLを別ブラウザー/許可された別回線で比較し、サイトへ情報を送る |
| Secure Connection Failed | Firefoxの詳細エラーコード | 日時・ブラウザー更新・プロキシ等を確認し、警告を回避しない |
| ERR_NAME_NOT_RESOLVED | URLの入力、名前解決 | ホスト名とDNSの結果を確認 |
| ERR_CONNECTION_TIMED_OUT/RESET | そのサイトだけか、複数サイトか | 端末・回線・サイト側を比較 |
| NET::ERR_CERT_DATE_INVALID | PCの日時と証明書期限 | 日時が正しければサイト運営者へ確認 |
「Access Denied」の文章だけでは、拒否したサービスや理由までは分かりません。Reference #18やerrors.edgesuite.netを含む画面も、番号の先頭だけでIP評判・Bot判定・ルーター故障のどれかに決めつけないでください。対象URLと画面の全情報が必要です。
Reference #18とerrors.edgesuite.netは何を調べる手掛かりか
Akamaiの公式エラー参照コード診断は、ブロックされた要求について参照コードから対応するセキュリティイベントを調べる仕様を公開しています。例には18から始まる参照コードがあり、診断の分類にはWAF、Bot対策、カスタムルール、IPの評判・ネットワークリストなど複数の種類があります。先頭の「18」だけは、どの設定が拒否したかを示す十分な情報になりません。
これは対象サービスを管理できる側が認証と権限を使って調査するための情報です。閲覧者が番号を入力すれば解除できるパスワードではありません。errors.edgesuite.netという表示だけを見て、PCから何かをアンインストールしたり証明書を削除したりせず、拒否された本来のサイトの窓口へ連絡します。
公式診断には調査できる期間の制限があるため、問い合わせは早めに行います。再読み込みを繰り返すより、発生日時、タイムゾーン、番号全体、対象URLをまとめた方が調査材料になります。アクセス制限を回避するためにIPを次々に変える操作は行いません。
最初に行う比較：ブラウザー・端末・回線
- 対象URLの入力ミスとサイトのメンテナンス案内を確認し、エラー画面を保存します。
- 同じPC・同じ回線で別ブラウザーを使います。1つだけ失敗するなら、そのブラウザーの設定や保存データを確認します。
- 同じ回線の別端末でも、同じURLとエラーが再現するか確認します。
- 利用が許可されたモバイル回線などで、同じPC・同じURLを一度比較します。通信量と業務ネットワークのルールに注意します。
- 表のように結果を整理し、拒否画面ならサイトへ、接続自体の問題が広い場合はISPや管理者へ伝えます。
| 比較結果 | 次に調べる範囲 | ここでは確定できないこと |
|---|---|---|
| 1ブラウザーだけ失敗 | 拡張機能、Cookie、プロキシ、接続設定 | PCやルーターの故障 |
| 同じ回線の複数端末で拒否、別回線では正常 | その接続元や回線条件に対するサイト側判断、VPN/プロキシ、経路 | ルーター交換が必要か、IPが原因か |
| 同じPCがどの回線でも失敗 | PC/ブラウザー設定とサイト側のアカウント条件 | ネットワーク原因をすべて除外できたか |
| 別端末・別回線でも同じサイトだけ失敗 | サイトの状態、アクセス対象や利用条件 | 端末側の初期化が必要か |
回線を変えると、接続元IPやDNS、経路、VPNなどの条件も変わります。「別回線で開けた」は切り分け材料ですが、「宅内ルーターが原因と確定」ではありません。複数サイトが同時に失敗する場合も、エラーの種類をそれぞれ記録します。
1つのブラウザーだけ失敗する場合
Googleの公式読み込み手順に沿い、ブラウザーを更新・再起動し、シークレットウィンドウなどで比較します。そこで正常なら、拡張機能や保存データを1つずつ調べます。比較ではログイン状態やCookieも変わるため、改善しても拡張機能だけが原因とは限りません。
対象サイトのCookieやキャッシュを削除する前に、ログアウトやサイト内設定の消失を確認します。「すべての項目」にチェックして全サイトの保存データを一括削除する手順から始める必要はありません。拡張機能を一時的に外して改善した場合は、必要なものを1つずつ戻して原因を確認します。
Secure Connection Failedなら詳細コードを確認する
Mozillaの公式説明では、Secure Connection Failedは安全な暗号化接続を確立できない状態で、警告を回避する例外が出ない場合があります。証明書を確認できない警告ページとも区別し、「詳細」のコードを記録します。古いTLSしか対応しないサイトの場合は、ブラウザー側で安全性を下げずサイト側の対応を依頼します。
- PCの日時とタイムゾーンが正しいか確認します。
- ブラウザーを更新し、問題が始まった時期を記録します。
- 独自のVPNやプロキシ、HTTPS検査ソフトの使用有無を確認します。業務環境は管理者へコードを渡します。
- DNS over HTTPSやプロキシの設定を変更している場合は、公式手順と管理ルールに沿って設定を確認します。
- 古いTLSや不明な証明書が原因と表示された場合は、サイト運営者へ伝えます。
保護ソフトやファイアウォールを丸ごと停止したり、TLSの最低版を下げたり、不明なルート証明書を追加したりする方法は解決策にしません。ソフトの更新・対象設定の確認を先に行い、必要な診断はメーカーまたは管理者の案内で進めます。Chromeの公式エラー案内も、システム日時やサイト側のTLS問題を区別しています。
回線に共通する場合もルーター初期化・交換を急がない
複数端末で同じ回線だけ失敗する場合は、ISPの障害情報、VPN/プロキシの使用、ルーターの型番・ファームウェアを確認します。メーカーの手順に沿った再起動は比較の1つですが、初期化とは異なります。工場出荷状態への初期化は接続設定を失うため、契約回線の再設定条件が分からないまま行いません。
拒否画面が表示されている場合は、対象サイトが接続元をどう判定したかの確認も必要です。まず参照番号と比較結果をサイト運営者へ渡します。DNSを公共DNSへ変更すれば必ず拒否が解除される、ルーターを買い替えれば確実に直るという説明はできません。
IPv6・MTU/MSS・QoS・NAT等の高度な設定は、契約方式や機器によって適切な値が異なります。根拠なく1452や1492へ固定したり、IPv6と保護機能をすべて無効にしたりせず、ISPが対象経路の調査から必要と判断した項目だけを、元の値を記録して確認します。固定IP契約や機器購入も、原因を調べてから検討します。
管理者向け：DNSとTCP接続だけを調べる例
以下は設定をリセットせず診断するPowerShellの例です。example.comを、開けないサイトのホスト名に置き換えます。https://やパスは付けません。Resolve-DnsNameはA/AAAAレコード、Test-NetConnectionは指定ポートへのTCP接続を調べます。
Resolve-DnsName -Name example.com -Type A
Resolve-DnsName -Name example.com -Type AAAA
Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel Detailed| 結果 | 分かること | 分からないこと |
|---|---|---|
| A/AAAAの応答が出る | そのDNS問い合わせで返ったアドレス | ブラウザーのDoHでも同じ結果か、拒否理由は何か |
| AAAAがない | その問い合わせでIPv6アドレスが得られない | それだけで異常やIPv6経路故障とは言えない |
| TcpTestSucceeded=True | 表示されたRemoteAddressのTCP443へ接続できた | TLS・ログイン・WAF判定・ページ読み込みの成功 |
| TcpTestSucceeded=False | その条件でTCPテストに成功しなかった | サイト、経路、機器のどこが原因か |
この結果だけで、CDNの地域誤判定やMTU問題を断定しません。tracertの途中が応答しないことも、そこでWeb通信が止まっている証明にはなりません。ブラウザーの詳細エラーと合わせて管理者へ渡します。特定サイトの拒否画面だけが問題なら、Winsock/IPリセットやOS修復をまとめて実行する必要はありません。
サイト運営者・ISPへ問い合わせるためのテンプレート
Access Denied/Reference #18なら本来のサイトの公式窓口、回線全体の接続問題ならISP、職場・学校の接続なら管理者へ送ります。実施していない対処は確認済みにせず、必要な範囲の情報だけを記入します。IPアドレスなどは公開掲示板へ掲載せず、相手が必要とする場合に公式窓口で共有します。
【対象URL】
【発生日時・タイムゾーン】
【表示されたメッセージと詳細コード】
【Reference番号全体】
【同じPC・別ブラウザーでの結果】
【同じ回線・別端末での結果】
【許可された別回線での結果】
【VPN/プロキシの使用有無】
【OS・ブラウザーの版】
【回線機器の型番・ファームウェア（ISPへの相談時）】
【実際に確認/変更した内容】
【依頼】対象要求の拒否理由、または接続が失敗する条件を確認してください。画面のスクリーンショットを添える場合は、ログイン情報や個人情報が写っていないか確認します。サイト管理者から特定の診断情報を求められたら、その指定に沿って収集します。Akamaiを利用するサイトであっても、一般閲覧者が別サイトの管理画面やAPIを操作して解除することはできません。
よくある質問
errors.edgesuite.netが出るとウイルスですか？
その文字列だけでは感染の証拠になりません。アクセス拒否画面の内容と、開こうとした本来のURLを確認します。不明な「解除ツール」を入れず、正規サイトの窓口へ参照番号を伝えて調査を依頼してください。
Reference #18を消すために再読み込みを続けてよいですか？
表示番号と日時を保存し、少数の比較結果をまとめます。短い間隔で繰り返しアクセスしても、拒否理由の確認にはなりません。サイトの案内や窓口の対応を確認します。
別回線で正常ならルーター交換すべきですか？
接続元IP・経路・VPNなどの条件も変わるため、交換の根拠としては不十分です。拒否画面はサイト側、接続に失敗する条件はISPや管理者へ共有し、必要な対応を絞ってから機器交換を検討します。
まとめ
特定サイトのAccess Denied/Reference #18は、番号全体と日時を保存してサイト側の拒否理由を確認します。Secure Connection Failedは詳細コードを基に、安全な接続・証明書・設定を調べます。同じPC・別ブラウザー、同じ回線・別端末、別回線を比較し、ルーター故障やIP評判を断定せず、適切な窓口へ再現条件を渡してください。
コメント