← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

なぜパーサーがサイトの地域を正しく表示しないのか：Accept-Language、通貨、ジオクッキーの影響

なぜパーサーが実際のユーザーが見るページのバージョンをダウンロードしないのか、そしてそれをヘッダー、クッキー、適切なプロキシの選択を通じて修正する方法。

📅2026年10月22日

パーサーは起動し、コードは落ちず、データは受信されますが、ドルでの価格が表示され、英語のテキストが表示され、 そして商品はロシアの生ユーザーが見るものとは異なります。これはパーシングで最も一般的で悔しい問題の一つです： 技術的にはすべてが機能していますが、コンテンツが「異なる」のです。これがなぜ起こるのか、そして あなたが必要とするページのバージョンを取得するためのリクエストをどのように構築するかを説明します。

症状: パーサーが異なるバージョンを見ていることを理解する方法

問題を修正する前に、正しく診断することが重要です。パーサーが通常のブラウザユーザーが見るものとは異なるデータを取得する 典型的なシナリオは3つあります：

  • コンテンツの言語が一致しない — ロシア語のテキストを期待しているのに、英語や ウクライナ語のページが表示される。
  • 通貨と価格が異なる — サイトがUSDやEURで価格を表示しているが、ロシアのブラウザでは ルーブルが見えるか、単に数字が異なる（地域の価格設定）。
  • 商品/コンテンツのカタログが異なる — 商品の可用性、プロモーション、全体のショーケースは サイトがあなたの地域で「見た」ものに依存します。

原因はほぼ常に3つのうちの1つ（またはその組み合わせ）です：Accept-Languageヘッダー、 不足しているか不正確なクッキー、またはリクエストが行われるIPアドレスのジオロケーションです。それぞれを順に見ていきましょう。

Accept-Language: サーバーが応答の言語を選択する方法

ブラウザは各リクエストでAccept-Languageヘッダーを送信し、 その中にユーザーの好ましい言語が重み（q値）付きで列挙されています。ロシアのロケールを持つChromeが実際に送信する内容の例： 

Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

パーシング用のライブラリ（requests、httpx、scrapy）は、デフォルトではこのヘッダーを送信しないか、 */*のようなものを送信します。 この場合、サーバーはデフォルトの言語（通常は英語）を返すか、IPによって言語を特定します — ここでジオ部分が関与します。

重要なポイント：多くのサイトは「Accept-Language + IPジオロケーション」の組み合わせを使用しており、 どちらか一方ではありません。つまり、正しい言語ヘッダーを送信しても、リクエストが他の国のIPから行われると、 サイトは依然として英語またはその地域のローカルバージョンに切り替える可能性があります。

通貨とロケール: サイトが価格をどこから取得するか

通貨はほとんどの場合、Accept-Languageヘッダーによって直接決定されません。通常は次の3つのメカニズムのいずれか（またはその組み合わせ）が使用されます：

  1. GeoIPデータベース — サーバーはIPがどの国から来たかを確認し、最初の訪問時に 自動的に対応する通貨とロケールを設定します。
  2. 以前に選択された地域のクッキー — ユーザーが以前に手動で国と通貨を選択した場合、 サイトはこれをクッキーに保存し、IPを再確認しません。
  3. URLのパラメータまたはサブドメイン — 一部のサイトは?country=ruや ru.example.comのような明示的なマーカーを使用します。

実際には、インターネットショップをパースしていて、ドルでの価格が表示される場合、80%のケースでは 問題はヘッダーではなく、リクエストのIPアドレスにあります。サイトは単に「ロシアのIPではない」と見なし、 デフォルトの国際的なショーケースを表示します。

サイトが一度あなたの地域を特定した後（IPまたは「あなたの都市を選択」バナーでの手動選択によって）、 その決定をクッキーに保存します — 通常はregion, geo_city, currencyまたは localeのような名前で。 その後、このクッキーを持つすべてのリクエストは保存された地域に基づいて処理されます — IPが突然変更されても。

これはパーサーにとって罠を作ります：一度「異なる」バージョンを取得し、セッションのクッキーを保存すると、 その後のすべてのリクエストは同じエラーを再現します。たとえヘッダーやプロキシを修正してもです。したがって、 診断時には常にクリーンなセッションでパーシングを確認してください — 過去の実行から保存されたクッキーなしで。

同じメカニズムの逆の側面は便利です：必要なクッキーの名前とその地域の正しい値を知っている場合（たとえば、 必要なロケーションでブラウザのDevToolsで確認した場合）、IPを変更せずにその値をリクエストに強制的に設定できます。 これは、地域がクッキーのフラグのみで特定されるサイトに対して機能しますが、サーバーが各リクエストで GeoIPデータベースとIPを再確認する場合には機能しません。

地域の特定におけるIPアドレスとプロキシの役割

GeoIPによる特定は、リクエストが実際にどこから来たかを理解するための最も信頼性の高い方法です。 なぜなら、ヘッダーやクッキーは偽造できるが、IPアドレスは偽造できないからです（別の実際のものに置き換えることはできます）。 そのため、ページの「正しい」地域バージョンを安定して取得するには、HTTPヘッダーだけでは不十分で、 実際に必要な国に属するIPが必要です。

ここで、IPアドレスの種類には重要な違いがあります：

  • データセンターのIP — GeoIPデータベースはしばしば国によって正しく特定しますが、多くの大規模な サイト（特にマーケットプレイスやボット対策サービス）はデータセンターの範囲を疑わしいとマークし、 ジオロケーションに関係なく制限されたまたはデフォルトのコンテンツバージョンを表示することがあります。
  • レジデンシャルIP — 実際のプロバイダーと物理的な住所に属し、GeoIPは地域をより正確に特定し、 サイトはその国/都市の通常のユーザーとしてリクエストを受け取ります。
  • モバイルIP — 特定の国のモバイルオペレーターに結びついており、これは特に モバイルトラフィックとデスクトップトラフィックで異なる動作をするサイトやアプリにとって重要です。

Wildberries、Ozon、またはAvitoの特定の都市からの価格監視のようなタスクには、 レジデンシャルプロキシが最適です — これにより、実際の地域に結びついたIPが提供され、サイトのGeoIPデータベースは国と都市を正確に特定し、 デフォルトの国際的なショーケースに置き換えることなく表示します。

実践: Pythonで正しいリクエストを構築する

すべての3つの問題を同時に解決するリクエストを構築します：正しいAccept-Languageを送信し、 必要なクッキーを持つクリーンなセッションを使用し、必要な地域のIPを通じてリクエストを行います。 

import requests

proxies = {
    "http": "http://user:[email protected]:8080",
    "https": "http://user:[email protected]:8080",
}

headers = {
    "Accept-Language": "ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/124.0.0.0 Safari/537.36",
}

cookies = {
    "region": "ru",
    "currency": "RUB",
}

session = requests.Session()
response = session.get(
    "https://example.com/catalog",
    headers=headers,
    cookies=cookies,
    proxies=proxies,
    timeout=15,
)

print(response.status_code)
print(response.text[:500])

このコードのいくつかの重要なポイント：

  • requests.Session()を使用し、 単一のrequests.get()ではなく、 サーバーが必要に応じて追加のクッキーを設定できるようにし、それらが同じパーシングセッションのリクエスト間で保存されるようにします。
  • クッキーの値region とcurrencyは条件付きであり、 実際の名前と値は、必要なロケーションのターゲットサイトでブラウザのDevTools（Application → Cookiesタブ）で確認する必要があります。
  • プロキシは実際に必要な国にある必要があります — そうでないと、正しいヘッダーとクッキーであっても、 サーバーがジオロケーションを再確認する際に上書きされる可能性があります。

JSサイト: Playwrightとヘッダー/クッキーの管理

サイトがJavaScriptを介してコンテンツをレンダリングする場合（価格がページの読み込み後に別のリクエストでロードされる）、 単純なrequestsリクエストでは不十分で、ヘッドレスブラウザが必要です。Playwrightでは、ロケール、言語、プロキシは ブラウザのコンテキストレベルで設定されます： 

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    context = browser.new_context(
        locale="ru-RU",
        timezone_id="Europe/Moscow",
        proxy={
            "server": "http://gate.proxycove.com:8080",
            "username": "user",
            "password": "pass",
        },
    )
    context.add_cookies([
        {"name": "region", "value": "ru", "domain": "example.com", "path": "/"},
        {"name": "currency", "value": "RUB", "domain": "example.com", "path": "/"},
    ])

    page = context.new_page()
    page.goto("https://example.com/catalog")
    page.wait_for_selector(".price")
    print(page.content()[:500])

    browser.close()

timezone_idパラメータに注意してください — 多くのサイトはブラウザのタイムゾーンを地域に期待されるものと照合し、（たとえば、IPがロシアからで、 ブラウザのタイムゾーンがアメリカの場合）その不一致自体がリクエストが疑わしいことを示す信号になる可能性があります。

典型的なエラーと起動前のチェックリスト

パーサーを本番環境で実行する前に、短いチェックリストを確認してください — これによりデバッグの時間を節約できます：

  • ✅ Accept-Languageヘッダーが設定され、期待される地域に一致している。
  • ✅ セッションがクリーンである — クッキーが以前の失敗したリクエストから継承されていない。
  • ✅ プロキシのIPが物理的に必要な国にある（パーシングの前に任意のgeo-IPチェッカーで確認してください）。
  • ✅ User-Agentが実際のブラウザに一致し、ヘッドレスモードの兆候を含まない。
  • ✅ ブラウザのタイムゾーンとロケール（Playwright/Selenium用）がIPの国と一致している。
  • ✅ サイトがバナーで地域を手動で選択する場合 — この選択のクッキーが手動で渡される。

プロキシのローテーションについても言及する価値があります：リクエストごとにIPを変更し、セッションのクッキーが 同じままの場合、サイトは「地域Aのクッキーだが、地域BのIP」を見てセッションをリセットする可能性があります。 価格監視のタスクには、特定の地域のパーシングセッション全体で1つのIPを固定する方が良いでしょう。

タスクに適したプロキシの種類

プロキシの種類の選択は、サイトがあなたの地域をどれだけ正確に特定し、自動化を疑わないかに直接影響します。 ここでは、地域バージョンのサイトをパースするための典型的なタスクに対する比較を示します：

プロキシの種類 ジオロケーションの精度 使用するタイミング
データセンターのプロキシ 平均、国は正しいが、IPは「非居住」としてマークされる可能性がある 厳しいボット対策がないサイトのパース、高速かつ大量のリクエスト
レジデンシャルプロキシ 高精度、都市レベルまで マーケットプレイスでの価格監視、地域コンテンツ、GeoIPチェックの回避
モバイルプロキシ 高精度、さらにモバイルオペレーターのマーク 特定の国のモバイルトラフィックで異なる動作をするサイトやアプリ

もしタスクが異なる都市からのマーケットプレイスでのカタログと価格の監視であるなら、レジデンシャルプロキシが 通常最も予測可能な結果を提供します：GeoIPデータベースは実際の居住住所を見ており、データセンターの範囲を 別のロジックで処理するサイトもあります。

結論

「パーサーが異なるページバージョンを見ている」という問題は、ほぼ常に3つの要因から成り立っています： 好ましい応答言語を決定するAccept-Languageヘッダー、以前に選択された地域と通貨を記憶するクッキー、 そしてサーバーが最初の訪問時にリクエストの国を特定するためのIPアドレスのジオロケーションです。 生のユーザーが見るのと同じバージョンのサイトを取得するには、これらの3つのパラメータを同時に同期させる必要があり、 別々に修正することはできません。

地域版のサイトを定期的にパースしたり、マーケットプレイスでの競合の価格を監視したり、異なる国からデータを収集したりする場合は、 適切なIPの選択から始める価値があります — 他の設定（ヘッダー、クッキー、タイムゾーン）はそれを中心に構築されます。 必要な地域に正確に到達するためには、レジデンシャルプロキシを試すことをお勧めします。 これにより予測可能なジオロケーションが得られ、ローカル版の代わりにデフォルトの国際版のサイトを取得するリスクが最小限に抑えられます。

関連記事