ブロックされたウェブサイトとアプリ

苦情から接続先のブロックに至る流れ

利用者がプロキシを使うと、接続先はプロキシの出口IPからの通信を受け取ります。その通信が問題を起こすと、サイト運営者は、そのネットワークを管理する組織へアドレスを通報できます。苦情はプロキシ事業者に直接届くことも、インフラを提供するホスティング会社、データセンター、ネットワーク運営者を経由して届くこともあります。

不正利用の報告は、サービスの不適切な使用が疑われるという通知です。無許可のログイン試行の繰り返し、スキャン、システムを過負荷にする通信などが対象です。インフラ提供元は、顧客であるプロキシ事業者に活動の停止を求める場合があります。提供元の規則と問題の内容によっては、未解決のままにするとサーバーやネットワークへのアクセスが危うくなります。

記録から関係するアカウントを特定できれば、事業者は調査し、そのアカウントを制限できます。また、サービスの一部または全体で、問題の接続先をブロックすることもできます。これらは対処する問題が異なります。アカウント制限は特定の利用者を対象とし、接続先のブロックは、対象サービスを使うほかの利用者から同じリソースへの通信も防ぎます。

ある政府ポータルが、プロキシサービスから望ましくない通信を繰り返し受けたとします。苦情と通信停止の要求を受け、事業者はそのポータルをブロックリストに追加します。後日、別の利用者が公開文書をダウンロードしようとすると、エラーになります。2人目の利用者に落ち度はなくても、共通の接続先規則はその接続にも適用されます。

問題が起きる前にリソースをブロックする理由

事業者は、すべてのサイトについて個別の苦情を待つ必要はありません。特定の種類のリソースで問題に対応した後、類似の接続先を事前に制限する場合があります。ブロックリストは、過去の問題の記録であると同時に、予防策にもなります。

考えられるコストは、1件の苦情への対応だけではありません。問題の繰り返しは担当者の時間を使い、インフラ提供元との関係を損ね、ほかの利用者のサービス可用性を脅かすこともあります。一部の利用者に正当なアクセス理由があっても、事業者は、機微な種類のリソースへの通信にはそのリスクに見合う価値がないと判断する場合があります。

これが、元の利用者を除外した後も広い制限が残る理由です。事業者は再発を防ごうとしています。新しい訪問者がページを読むのか、ログインするのか、望ましくない操作をするのかを個別に確かめず、カテゴリ全体を制限することがあります。

ブロックリストに登録されるリソース

政府関連や金融関連のリソースは、事業者が予防的に制限するカテゴリの例です。無許可のアクセスや妨害が、個人記録、公共サービス、アカウント、金銭に影響するシステムが含まれます。利用者ごとの目的を評価するより、接続先へのアクセスを拒否する方が容易なため、広い規則を選ぶ場合があります。

すべてのプロキシ事業者が使う共通のブロックリストはありません。個別のドメインを制限するサービスも、カテゴリ全体を閉じるサービスもあります。同じ会社内でも製品やネットワークごとに規則が異なる場合があります。ある事業者のリストに政府サイトが載っていても、すべての事業者がブロックするとは限りません。

カテゴリは技術的な規則に落とし込む必要もあります。政府関連のリソースにはさまざまなドメイン命名方式があるため、.govで終わるアドレスだけをブロックすることは、政府サイトをすべてブロックすることと同じではありません。事業者は独自のリストを維持したり、分類サービスで接続先を識別したりできます。

プロキシがブロックリストを適用する仕組み

プロキシがリソースへの接続を行うには、まず接続先を知る必要があります。HTTPプロキシでは、クライアントはCONNECT portal.example:443でHTTPSトンネルを要求できます。これにより、プロキシへ接続先のホスト名とポートが伝わります。SOCKS5も、ホスト名またはIPアドレスとして指定された接続先アドレスを運びます。

サービスは、その接続先をアクセス規則と照合します。該当する規則が禁止していれば、利用者のリクエストをサイトへ転送する前に接続を拒否できます。ドメイン規則は名前を、アドレス規則は接続先IPや範囲を調べます。カテゴリ規則は、そのカテゴリに分類されたドメインやアドレスの一覧を利用できます。

このために暗号化ページを読む必要はありません。通常のHTTPSトンネルでは、サイトとの保護された通信が始まる前に接続先が分かります。そのため、ページ内容、完全なURLパス、訪問者が入力する予定のパスワードを調べずにブロックできます。

規則の適用範囲が重要です。1つのホスト名をブロックしても、同じ組織の全サブドメインが自動的にブロックされるわけではありません。逆に、広いドメイン規則や共有サーバーを対象にしたIP規則は、苦情の発端となったリソース以外にも影響する場合があります。サイトのアドレスも変わるため、ブロックリストには保守が必要です。

アクセス可否が製品によって異なる理由

事業者は製品ごとに異なるアクセス規則を適用できます。あるサイトがデータセンタープロキシやISPプロキシではブロックされ、住宅用ネットワークでは利用できたり、マネージド型のデータ収集サービスでのみアクセスできたりする場合があります。

一部の事業者は、利用者の身元を確認するKYC（Know Your Customer）を経た場合に限り、特定のリソースへのアクセスを許可します。具体的な作業の承認が必要な場合もあります。確認後に与えられるアクセス権限も、特定の製品や接続先に限定されることがあり、アカウントの全制限がなくなるわけではありません。

リクエストの処理方法も重要です。通常のプロキシでは、どのリクエストを送るかを利用者のブラウザーやプログラムが決めます。スクレイピングAPIでは、利用者がページ取得や商品データ収集などの作業を提出し、事業者のシステムが実行します。結果はページのHTMLや、構造化形式で抽出されたデータの場合があります。

こうしたマネージドサービスでは、事業者がプロキシネットワークを選び、リクエストヘッダーやCookieを設定し、失敗したリクエストを再試行して、レスポンスを処理できます。具体的な管理範囲は製品次第で、一部の設定は自動、ほかは許可された範囲内で利用者が指定できます。事業者は、その作業における対象サイトとの通信を管理し、受け付けるリクエストパラメーターを制限できます。

これにより、広いアクセスは制限したまま、特定の操作だけを許可できます。たとえば、APIによる公開商品価格の収集は許可し、同じドメインへの通常のプロキシアクセスは拒否する場合があります。その権限にログイン、フォーム送信、アカウント管理が自動的に含まれるわけではありません。製品が特定ページの読み取りに対応していても、サイト上のすべての操作を行えるとは限りません。

製品、接続先、予定する操作の組み合わせでアクセス可否を確認してください。事業者のAPIでサイトが動いても、その事業者のプロキシパッケージで動くとは限りません。マネージドAPIにも独自の制限があります。購入前に、どの製品で作業が許可されるか、本人確認や個別の承認が必要かを尋ねてください。

利用者からどう見えるか

最も明確なのは、接続先が許可されていないという具体的なメッセージです。それ以外では、ソフトウェアが接続失敗やタイムアウトだけを表示する場合もあります。利用者がどこまで分かるかは、サービスが返す応答と、アプリケーションが表示する詳細の両方に左右されます。

ブロックされた接続先は、それ以外では正常な多くのプロキシIPからも利用できない場合があります。同じ規則がパッケージ全体に適用されるなら、アドレスを交換しても結果は変わりません。通信量の追加購入や同時接続数の引き上げでも、その接続先規則は残ります。

アプリケーションの一部だけが失敗することもあります。たとえば、メインページとログインサービスが別のドメインを使い、後者がブロックされていれば、ページは開いてもログインできません。別サーバーを使うファイルダウンロードなどの機能でも同様です。ブロックリストは、アプリ名だけではなく、実際に通信するネットワーク上の接続先に適用されます。

サイトがプロキシを拒否する場合との違い

事業者のブロックリストは、接続先に向かう途中で通信を止めます。一方、サイトは自社サーバーやセキュリティサービスに届いた通信を独自に拒否できます。出口IPを拒否したり、活動を不審と判断したりする場合です。この場合、拒否は接続先側から来ています。

通常のHTTP 403や接続失敗だけでは、どちらがアクセスを止めたかは特定できません。禁止された接続先を示す事業者のメッセージは、ステータス番号だけより役立ちます。原因が不明な場合、サポートが事業者の規則の関与を調べるには、正確なアドレス、使ったサービス、試行時刻、エラーの全文が必要です。

別の種類の制限として、接続先ポートのブロックもあります。ドメインのブロックはリソースへのアクセスを拒否し、ポート制限は多くのサーバーへの特定種類の接続を止める場合があります。したがって、サイトやアプリが使えないのは症状であり、接続先リストは原因の1つです。

リソースをブロックリストから外せるか

規則がある理由と、それを管理する主体によります。予防策として事業者が追加した場合は、具体的な用途の審査に応じる可能性があります。インフラ提供元や固定の製品規則がアクセスを除外している場合、通常のサポート依頼だけでは変えられないことがあります。

例外を認める場合、有用な依頼では正確なリソースと目的を説明します。必要なデータや機能、ログインの有無、予想する負荷などです。これにより、事業者は、カテゴリ全体を開放してほしいという曖昧な要求ではなく、具体的な用途を評価できます。

本人確認や承認を受けても、アカウントのすべての制限がなくなるとは限りません。例外は特定の接続先や製品だけに適用される場合があります。プロキシ事業者がアクセスを許可しても、サイト自身のアクセス制御は残ります。

新たな苦情やリスク評価の見直しにより、ブロックリストは変わることがあります。以前は使えたリソースも、規則の追加後に使えなくなる場合があります。特定サイトに依存する作業では、サービスを選ぶ前に、接続先と必要な操作に対応しているか確認してください。利用可能なIP数だけでは分かりません。