サイトは開くのに接続テストが失敗する原因：CORS・403・タイムアウト

ブラウザでウェブサイトを開けたのに、別の検出ツールでは赤信号が点灯している。このとき、最も起こりがちなのは二つの相反する判断です。自分のIPがブロックされたと考えるか、検出ツールはまったく役に立たないと断定するか。

結論を急ぐ前に。トップページを直接開くこと、ウェブスクリプトからインターフェースを読み取ること、リモートサーバーからリクエストを送ることは、三つの異なるテストです。ターゲット、リクエスト方法、アクセス出口、成功基準が十分に一致して初めて、結果を直接比較できます。

この種の問題を切り分ける目的は、カードを緑色に変えることではなく、失敗がどの段階で起きているのか、そしてそれが本当にやりたいことに影響するのかを確定することです。

まず検出ツールに問いましょう：どの区間を測っていますか？

「接続できる」はすべての機能をカバーする状態ではありません。一回のアクセスには、少なくともドメイン名解決、ネットワーク接続、安全な接続、アプリケーション処理といった段階があり、アカウント権限はさらに別の層の判断になります。

アイコンや静的リソース、ステータスAPIへの接続が成功しても、それはその検出対象がその時点で応答したことしか証明しません。ログイン、アップロード、決済などの業務機能の検証の代わりにはなりません。

同様に、Ping が応答しないことも、それだけではウェブサイトが利用できないことの証明にはなりません。ICMP はウェブアクセスで使われるプロトコルとは異なり、ネットワークが前者に応答しなくても、通常の HTTPS 接続は許可される場合があります。

第1類：ウェブページは開けるが、検出スクリプトが結果を読み取れない

この種の問題では、まずクロスオリジン制限を考慮する必要があります。

検出ページがサイト A で実行され、そのスクリプトがサイト B のレスポンスを読み取ろうとしていると仮定します。ブラウザは、サイト B がこのオリジンからのデータ読み取りを許可しているかどうかをチェックします。これは、ユーザーがアドレスバーにサイト B を直接開く場合とは権限の問題が異なります。

MDN の CORS ガイドでは、クロスオリジンリクエストはブラウザのセキュリティメカニズムによって制約されると説明されています。リクエストはターゲットに到達しているかもしれませんが、レスポンスはスクリプトに提供されません。また、プリフライト段階でリクエスト続行の許可が得られなかった可能性もあります。

さらに厄介なことに、スクリプトが受け取るエラーは具体的でないことがよくあります。クロスオリジン制限、接続問題、その他の失敗原因を区別できない場合があります。検出ツールがこれらすべてを「アクセス不可」と表示すると、「検証不能」を誤って「確定的に到達不能」と書き換えてしまいがちです。

一般ユーザーは、直接アクセスが安定しているか、ページが正常に動作しているかを確認し、検出時のエラー情報を保持すべきです。開発者はブラウザのコンソールとネットワーク記録を確認し、CORS またはプリフライトエラーが存在するかどうかを確認し、一般的な例外だけで IP について結論を下さないようにします。

接続を検証するためにブラウザのセキュリティ保護を無効にしないでください。そのような環境は通常のユーザー環境から逸脱しており、ターゲットサービスのクロスオリジンポリシーを修正することもできません。

第2類：リクエストメソッド、パス、またはログイン状態が異なる

一部の検出プログラムはトラフィックを減らすために HEAD リクエストを使用します。MDN の HEAD に関する説明によると、このメソッドは関連するレスポンスヘッダーを取得するために使用され、レスポンス本文は返しません。

しかし、特定のウェブサイトでは HEAD、GET、ビジネス API に対して異なるルールを適用する場合があります。例えば、あるパスでは HEAD が許可されていないのに、ユーザーがブラウザで発行する GET では正常にページを取得できることがあります。この場合、確認すべきはリクエストメソッドとターゲットパスであり、単一パスの失敗をウェブサイト全体の利用不可に拡大してはいけません。

ログイン状態も違いを生みます。直接サイトを開くとき、ブラウザは有効なセッションを保存しているかもしれませんが、検出スクリプトが同じ Cookie、アクセストークン、その他のコンテキストを持っているとは限りません。逆に、ホームページが正常に返っても、ログイン後の特定の業務がテストに合格したとは限りません。

この種の問題では、まず明確な成功基準を書き出すことをお勧めします：ホームページを開けること、自分のアカウントにログインできること、それとも一度の正常な操作を完了できること？ 基準が明確になったら、対応する検証方法を選択します。

第3類：レスポンスは受信したが、期待したレスポンスではない

403：リクエストが拒否されたからといって、IP が永久にブロックされたことが証明されたわけではありません

Cloudflare の 403 に関する説明では、権限やセキュリティルールなどの関連原因が列挙されています。ウェブサイトのオリジン、CDN、またはセキュリティポリシーがリクエスト処理に関与する可能性があります。

場合によっては、エラーページにリクエスト識別子、ルールのヒント、または連絡可能なサポートチャネルが提供されます。これらの情報を保持しておけば、カスタマーサポートに「私の IP がダメです」とだけ伝えるよりも問題の特定に役立ちます。

ただし、エラーページにある特定のブランドロゴを直接すべての責任の所在とみなしてはいけません。最終的には、そのリクエストが通過したサービスとウェブサイトの設定を組み合わせて、誰が処理すべきかを判断する必要があります。

429：まずリクエストを減らし、リフレッシュをトラブルシューティングとして使わない

429 は通常、リクエスト頻度が制限されていることを示します。制限の対象は IP の場合もあれば、アカウント、資格情報、Cookie、特定のリソースの場合もあり、すべてのサービスが同じ方法でカウントするわけではありません。

RFC 6585は、サーバーがリクエスト元をどのように識別しなければならないかを規定していません。MDN の 429 ドキュメントも、さまざまなレート制限方法と、返される可能性のある Retry-After 待機ヒントについて説明しています。

レート制限を確認したら、連続したリフレッシュや一括再試行を停止し、サービスが要求する待機時間を守るべきです。より多くのリクエストでレート制限の結果を検証しようとすると、かえって調査が制限の影響を受け続ける可能性があります。

タイムアウト：まずテストのしきい値と失敗段階を確認する

タイムアウトは、検出が設定時間内に完了しなかったことだけを示します。失敗は解決、接続、セキュリティネゴシエーション、レスポンス待機の段階で発生する可能性があり、ブラウザのキューイング、デバイスの負荷、または並行検出に関連する場合もあります。

「検出所要時間」も必ずしもネットワークの往復遅延と等しくありません。HTTP 検出の結果にはサービスの処理時間とリソース転送時間が含まれる可能性があり、Ping の数値と直接比較することはできません。

短時間のタイムアウトは通常の間隔後に再テストする価値があります。継続的なタイムアウトは失敗段階を記録する必要があります。一度しきい値を超えただけで、そのアドレスが長期的に利用できないと断定してはいけません。

第4類：2つのテストが同じ出口から送信されていない

ブラウザプロキシ、システムプロキシ、VPN は異なるアプリケーションとプロトコルをカバーする場合があります。デバイスが IPv4 と IPv6 の両方を持っている場合、2種類のリクエストが異なる経路を通ることもあります。

見落としがちなケースとして、検出ツールがリモートサーバーを使用してターゲットにリクエストを送る場合があります。それはそのテスト場所からの到達可能性を反映しており、あなたが使用しているパブリック IP のアクセス能力ではありません。

あなたの問題が「私の IP はこのアプリケーションにアクセスできるか」であるなら、中核的な証拠は現在のデバイスと現在のネットワークからの実際のアクセスから得られるべきです。リモートチェックはサーバー側が広範囲に異常であるかどうかの確認には役立ちますが、ローカル出口の検証を代替することはできません。

したがって、結果を比較する際には、少なくともテストのソース、アドレスファミリー、プロキシ状態、および対象アドレスを確認する必要があります。「同じウェブサイトをテストしている」とだけ書くのは、テスト条件が一致していることを示すのに十分ではありません。

一度に一つの条件だけを変更すると、問題の特定がずっと速くなります。

まずIPアドレス検索で現在のパブリックアドレスを記録し、次にサービス接続テストを使用して通常のアクセスと比較します。その後、実際の症状に基づいて項目ごとに確認します。

1. 同一ネットワーク、同一ブラウザーで、対象ページまたは機能が安定して利用可能かを確認します。

2. 検出対象と返された理由を確認し、クロスオリジン制限、ステータスコード、解決失敗、タイムアウトを区別します。

3. 一時的なクリーンブラウザープロファイルを使用して比較し、拡張機能、セッション、権限の違いを記録します。元の環境を急いで消去する必要はありません。

4. IPv4、IPv6、プロキシパスを確認します。別のネットワークに切り替える場合は、それを対照証拠としてのみ使用し、元の IP がブロックされたと即座に推測しないでください。

5. 必要に応じてDNSレコード検索またはHTTP・TLSチェックを補足し、これらのツールが使用するテスト場所を同時に記録して、観測ソースの混同を避けます。

ネットワークを変更すると、アドレス、解決パス、一部のネットワークポリシーが同時に変わります。「変更したら良くなった」というのは問題の範囲を狭めることができますが、どの項目が作用したのかを単独で示すことはできません。

証明書エラーが関係する場合も、証明書の警告を無視して問題が解決したと宣言しないでください。システム時刻、証明書チェーン、対象ドメイン名、および許可されたネットワーク構成を確認する必要があります。企業デバイスの場合は、管理者が関連ポリシーを確認します。

サポート担当者に何を提供すれば、効果的な回答を得られやすいでしょうか？

問題を再現可能な記録として説明できます。いつ、どのネットワークとブラウザーで、どの公開パスにアクセスし、どのような正常な操作を実行し、どのような結果を得たか、検出ツールの対象、方法、エラーは何かを記述します。

リクエスト識別子やレスポンスステータスコードがあれば、併せて提供します。パブリック IP は、トラブルシューティングに本当に必要な場合にのみ、信頼できるサポートチャネルを通じて提供します。アカウントのパスワード、Cookie、Authorization リクエストヘッダー、アクセストークンを含む完全な URL は、公開チケットやスクリーンショットに貼り付けないでください。

有用な結論は十分に具体的であるべきです。例えば、「ホームページは開けるが、クロスオリジンスクリプトが結果を読み取れない」や「現在のエグレスの特定のリクエストがレート制限されている」などです。これは「ネットワークが悪い」よりも解決策に近く、すべて緑色の検出ページよりも実際の可用性をよく示します。

階層化障害の2つの対照事例：DNS から TLS までの異なる失敗位置

同じドメイン名がある環境では DNS 解決が成功したが、TCP 接続が失敗したと仮定します。解決で A レコードまたは AAAA レコードが得られたのは、その時点でレコードが返されたことを示すだけで、対応するアドレスが到達可能であることを意味しません。失敗はローカルファイアウォール、キャリアポリシー、ターゲットポートの閉鎖、または経路上のデバイスで発生する可能性があります。このとき、IP がブロックされたと直接断言すると、中間の証拠を飛ばしてしまいます。より正確な表現は「現在のネットワークから対象アドレスへの TCP ポート接続が確立されていない」です。

もう一つの例は、TLS ハンドシェイク完了後に HTTP が 403 を返すケースです。これは接続がアプリケーション層の処理に入ったことを示しますが、クライアントが証明書検証を有効にしているかも確認する必要があります。検証が有効で成功した場合にのみ、証明書の信頼とホスト名チェックが通過したと言えます。検証をスキップしたテストにはこの証明がありません。403 は通常、そのリクエストが拒否されたことを示し、パス、身元、権限、またはセキュリティポリシーが関係する可能性があります。これだけでアカウントが凍結されたと証明することはできません。

これら2つのケースの違いは、失敗の階層が異なることです。TCP 失敗はトランスポート接続段階で発生し、TLS は通過したが HTTP が失敗するのはアプリケーション処理段階で発生します。階層を明確に書くことで、「接続不可」と「リクエスト拒否」を混同することを避けられます。例えば、リモート検出ノードが TCP 失敗を示した場合、それはそのノードのエグレスが接続を確立できないことを示すだけで、あなたのローカルマシンも失敗するとは直接推測できません。逆も同様です。

まず元のエラーを保持します。タイムアウトは規定時間内に対応する段階が完了しなかったことを意味し、接続リセットは接続が能動的に終了されたことを意味しますが、どちらもターゲット側、経路上のデバイス、またはクライアント環境に起因する可能性があり、エラー文言だけでファイアウォールに特定することはできません。すでに HTTP 403 を受信した場合は、リクエストメソッド、パス、時刻、リクエスト識別子を保持し、サービス側にルールを確認してもらいます。失敗段階を明確にして初めて、その後の比較が的を射たものになります。

階層化判断は後続のアクションにも影響します。TCP 失敗の場合は、ネットワークの変更、アドレスファミリーの変更、またはプロキシの確認が意味を持つかもしれません。TLS 成功後の 403 では、無効な再試行を減らし、リクエストメソッドとパスを確認するか、セキュリティポリシーがトリガーされたかを確認する方向に進みます。単一の結果でサイト全体やアカウント全体の状態を概括すると、証拠の範囲を過大評価することになります。

再現可能なチケット記録の作成：時刻、対象、観測点、段階

効果的なチケットは、赤いエラーのスクリーンショットではなく、観測点から再現できる記録です。発生時刻とタイムゾーン、アクセス対象の URL、使用したブラウザーまたはクライアント、デバイスのネットワークタイプ、検出ツールが実行された場所を含めることをお勧めします。観測点は特に重要です。ブラウザーのローカルマシンか、リモート検出ノードか、サーバーからの能動的リクエストか？異なる観測点での失敗の意味は異なります。

失敗段階も明記する必要があります。可能であれば、DNS、TCP、TLS、HTTP、ログイン後の機能を区別します。元のエラーはテキストまたはステータスコードを保持する必要があります。例えば、接続タイムアウト、403 ページ内のリクエスト ID、証明書エラーコードなどです。機密情報は必ずマスキングしてください。パスワード、Cookie、Authorization ヘッダー、アクセストークンを含む完全な URL をチケットに貼り付けないでください。パブリック IP は、本当に必要な場合にのみ信頼できるチャネルを通じて提供します。

「すべての地域でタイムアウト」や「全国でアクセス不能」と主張しないでください。あなたが知っているのは、自分がテストした観測点だけです。「現在のネットワークから、ある時刻から連続3回 TCP タイムアウトが発生した」と書くことができます。これは「ネットワーク全体が不通」よりも信頼性があります。リモート検出の結果は傍証として使用できますが、実際のテスト場所とテスト時刻を必ず明記する必要があります。

RDAP、ASN、BGP などのネットワーク証拠を引用する場合は、RDAP・ASN・BGP・RPKIで分かること：IP検索データの読み方の考え方を参照できます。まず RDAP でアドレスの帰属を確認し、次に BGP やルーティングデータで経路の変化を説明します。ただし、帰属は悪意を意味せず、ASN の変化も障害を意味しません。証拠は結論を支持するためのものであり、恐怖をあおるためのものではありません。

IP ブラックリストや CAPTCHA 現象に関わる調査については、IPのブロックリスト登録と繰り返すCAPTCHAの対処法がより具体的な方向性を提供します。チケットには CAPTCHA に遭遇したのか明確な拒否なのか、ログイン状態と関連しているかを記載する必要があります。CAPTCHA は単なる頻度制御やリスク管理の警告である可能性があり、アカウント凍結と同義ではありません。

最後に、あるツールの一度のタイムアウト閾値を全プラットフォーム共通の標準として扱わないでください。異なる検出製品はタイムアウト、再試行、並行処理の戦略が異なるため、閾値はそのツールのその時のテストにのみ適用されます。したがって、チケットには使用したツールと設定を明確に書く必要があります。再現可能な記録があって初めて、サポート担当者は段階を特定する機会を得られます。結論から逆算して問題を推測するのではありません。