ウェブサイトが利用者の位置を判断する方法

ドイツのIPなのにインド向け店舗が開く理由

インドの顧客が、ドイツと表示されたプロキシでオンラインストアを開くとします。この例では、ストアもIPをドイツと判定しています。それでも、ページ上部の国選択はインドのままで、カタログもインドの顧客向けです。

この顧客は以前、そのメニューでインドを選びました。ストアは選択を保存し、再訪時にも使っています。現在のリクエストがドイツに関連するIPから来たことと、以前インド向けの買い物を希望したことの両方を把握しています。選んだ市場を維持するのは、このストアの意図した挙動です。

IPの国と選択されたストア版は、異なる問いに答えます。前者はリクエストの送信元アドレス、後者は買い物体験を決める設定です。天気サイトで選んだ都市や、ホテル検索の目的地も同様です。サイトは、利用者が実際にそこにいると判断しなくても、その場所の情報を表示できます。

サイトに届く情報

ページリクエストを処理するサーバーは、接続のIPアドレスを確認できます。プロキシ経由なら、プロキシがそのサービスへの接続に使うアドレスです。IP位置データは、そのアドレスを国や地域に関連付けます。サイト自身、または代わりにリクエストを処理するサービスが検索できます。

リクエストには、言語設定と、そのサイトが以前保存したCookieも含まれる場合があります。読み込み後のページのJavaScriptは、さらにブラウザー設定を読み、権限の仕組みを通じて端末位置を要求できます。ログインすると、サイトがアカウントに保存された情報を取得できるようになり、別の関連付けが生まれます。

サイトは、機能に必要な情報を使います。単純なページならIPだけに頼る場合もありますが、アカウント、地域カタログ、配送設定のある店舗には、複数の情報源を使う理由があります。すべてのサイトが表の全項目を集める必要はありません。

選んだ国をサイトが記憶する仕組み

Cookieは、ブラウザーが保存し、そのサイトへの後のリクエストで送る小さなデータです。国の設定を直接含める場合も、サーバーが保存済みのセッションと設定を探すための識別子を含める場合もあります。localStorageなどの保存領域にも、サイトのスクリプトが読む設定を保存できます。

プロキシを変えると、その後のリクエストの接続は変わりますが、保存された値は消えません。買い物の例では、ドイツのIPからのリクエストに以前のセッションCookieが入り、ストアがインドの選択を読み出せます。

アカウント設定は、ブラウザーや端末が変わっても残る場合があります。自宅や配送先の住所、優先地域などは、サイトのサーバーに保存されている可能性があります。ログインすれば、再び利用できます。ローカルのサイトデータを消しても、アカウント側の記録は削除されません。

開くリンクで地域が決まる場合もあります。ストアは市場ごとに異なるドメインやURLパスを持つことがあり、インド向けのリンクを開けば、直接その版が表示されます。この場合、選んだURLが、要求した版をサイトに伝えています。

過去の操作も影響することがあります。例えばGoogleは、検索に適した場所の推定に、IP情報、端末位置、保存した自宅・職場住所、過去のアクティビティを使うと説明しています。これはGoogleのサービスの説明であり、任意のサイトがブラウザーの全履歴を読めるという意味ではありません。

ブラウザーによる端末位置の共有

Geolocation APIは、ページが端末の地理的位置の推定を要求できるブラウザー機能です。通常の公開サイトでは、一般にHTTPSの安全なコンテキストと位置情報の許可が必要です。結果には緯度、経度、精度の推定、取得時刻が含まれます。ページが認めていれば、許可済みの要求でキャッシュした位置を使う場合もあるため、地図を開くたびに新しく測定するとは限りません。

推定方法は、ブラウザーと端末の位置情報サービスが決めます。GPS、周辺のWi-Fi、モバイルネットワーク、IP情報などが候補です。そのため、GPSのないノートパソコンも位置を返せます。APIは特定の情報源を必須とせず、ページに取得元を知らせるものでもありません。返された座標を、常にGPS座標や正確な実所在地と呼ぶべきではありません。

インドの顧客が位置の取得を許可し、ブラウザーがインドの座標を返したとします。ページはその座標を、ドイツのプロキシ経由でストアへ送れます。リクエストには、ドイツのIPから届いたことと、内容にインドの位置があることの2つの事実が含まれます。プロキシは情報を運ぶだけで、入力された座標をドイツの座標に変えません。

訪問のたびに、新しい許可の画面が出るとは限りません。以前与えた有効な許可が残っている場合があります。サイトの位置情報権限はブラウザー設定で確認できます。OSがブラウザーへ与えた権限も関係する場合があります。

許可を拒否している間は、そのAPIで新しい位置を取得することを防げます。ただし、IPによる推定やサイトが以前保存した情報は別です。端末位置の取得を認めなくてもサイトが位置を表示できるのは、このためです。

言語とタイムゾーンから分かること

ブラウザーは、Accept-Languageリクエストヘッダーで優先言語を送れます。ページのスクリプトも言語設定を読めます。サイトが利用者の理解できる言語を選ぶ助けになり、端末位置の取得に必要な許可は不要です。

英語のブラウザーは、利用者が国を移動したりドイツのプロキシを使ったりしても、英語のままで使えます。ドイツ向けストアが英語に対応していれば、接続をドイツと扱いながら英語を表示できます。en-USのような設定も言語の地域的な種類を表すもので、米国内の位置が確認されたわけではありません。

JavaScriptは、例えばIntl.DateTimeFormat().resolvedOptions().timeZoneで、ブラウザーが示すタイムゾーンも取得できます。サイトは、予約を利用者の現地時刻で表示するために使うかもしれません。通常はブラウザーの環境を反映し、タイムゾーンは自動設定または手動設定の場合があります。

タイムゾーン名とUTCオフセットは異なります。オフセットは、ある時点でのUTCとの差で、複数国で共通する場合があります。どちらも単独では端末の実所在地を示しません。サイトが言語や時刻帯をほかの情報と比較することはありますが、プロキシの国と違うだけでは、別のIPが漏れた証拠になりません。

サイトが別のIPを知ることはあるか

プロキシ設定が適用されるのは、ブラウザーがそのプロキシへ送る通信です。ブラウザーや端末の全接続が同じ経路を通る証拠ではありません。リアルタイムの音声・映像・データ交換を行うWebRTCは、接続の準備中にアドレスを調べられます。ブラウザーの規則とネットワーク構成が直接の確認を認める場合、顧客の回線など、別のパブリックIPを示す可能性があります。

結果は、ブラウザーのプライバシー規則とネットワーク構成によります。WebRTCは、すべてのサイトが顧客のパブリックIPを取得できる万能な方法ではありません。192.168.1.10のようなプライベートなローカルアドレスも別の情報です。多数の無関係なローカルネットワークで同じ値を使えるため、それだけでは国を特定できません。

DNSはドメイン名をネットワークアドレスに変換します。専用のDNSテストでは、検索を処理するリゾルバーを特定できます。その国はリゾルバーの所在地を示し、顧客とプロキシの両方から遠い場合があります。一部のリゾルバーは、任意機能のEDNS Client Subnetで、DNS要求元クライアントのIPの一部も送ります。したがって、別の国のリゾルバーが見えることと、クライアントのネットワーク情報が漏れることは異なる結果です。

これらは、通常のページリクエスト以外で取得できるネットワーク情報の仕組みです。予想外のパブリックアドレスなどがテストで示された場合に調べます。ページの言語が違うだけでは、そのような接続があったとは判断できません。

サイトはどの情報を優先するか

行う判断によります。地図の「近くを探す」機能は、許可された端末位置を使えます。ストアは再訪者が選んだ国を維持でき、配送料計算には荷物の目的地が必要です。同じ訪問中にも、機能ごとに異なる情報を使えます。

GPSが常にIPより優先される、アカウントの国が常に両方より優先される、といった共通の規則はありません。各機能で利用でき、関連する情報をサイトが判断します。1つを使う、使えなければ別のものに切り替える、複数を比較するといった方法があります。

購入手続きでは、違いが特に明確です。顧客はドイツの商品カタログを見てから、インドの配送先住所を入力できます。ストアは配送料、購入できる商品、配送先の規則を適用し直す場合があります。例えばShopifyは、購入手続きで配送先住所が最終的な市場体験を決めると説明しています。これは販売システムの規則であり、プロキシIPの再測定ではありません。

アクセスも別の判断です。国を正しく認識しても、アカウント、ネットワーク、提供状況の規則で操作を拒否する場合があります。一般的な拒否だけでは、原因となった情報は分かりません。拒否された事実ではなく、サービスが示す具体的な説明が証拠になります。

結果に影響した情報の見分け方

まず、接続の国、地域カタログ、近隣の検索結果、言語、配送可否のどれを確認するかを明確にします。それぞれ異なる情報に依存する可能性があります。比較する際は、プロキシIPとページURLを固定し、関係する条件を1つだけ変えます。設定が変わっていないことだけに頼らず、各テストのIPを記録してください。ローテーションで、調べたい設定と同時にIPまで変わる場合があります。

1. サイト自身の設定を調べます。国の選択、検索範囲、配送先、URLの地域版を確認します。画面上の選択で結果を説明できるかもしれません。
2. 再訪時と、新しい未ログインのセッションを比べます。サイトの保存データがない別のテスト用プロファイルで、保存状態の影響を調べられます。まず、同じプロキシIPを使うことを確認します。新しいプライベートセッションではサイトデータが通常の閲覧と分かれますが、接続やすべてのブラウザー設定が自動で変わるわけではありません。
3. ログイン後の変化を確認します。アカウントとともに以前の地域が戻るなら、地域・住所設定を調べます。これはアカウント情報の影響を示す手掛かりですが、サイトの判断過程全体が分かるわけではありません。
4. 現在位置が必要な機能では、端末位置を確認します。サイトの位置情報権限と、推定元についての説明を確認します。近隣の検索結果と保存された配送国には、別の確認が必要です。

買い物の例では、国メニューでドイツを選ぶと、保存されたストア版の設定に対処できます。インドへの配送が目的なら、インドの配送先は引き続き重要です。サイトが明示的にプロキシIPを誤った国へ分類するなら、問題はそのアドレスの位置データです。必要な結果を特定することで、次の対応が具体的になります。