Як переглянути свій сайт з іншої країни

Коротко: Сайт зазвичай визначає вашу країну за IP-адресою, а потім підлаштовує те, що показує, під мову браузера, часовий пояс, cookie і акаунт, у який виконано вхід. Щоб переглянути власний сайт з іншої країни, кожен із цих сигналів має відповідати ринку. Тобто потрібен проксі в цій країні для адреси і окремий профіль Chrome з мовою та часовим поясом ринку і без жодної вашої cookie.

Щоб переглянути свій сайт з іншої країни, запит має прийти так, як прийшов би запит відвідувача: з адреси в цій країні, з мовою браузера і часовим поясом цього ринку і без cookie, які лишили ваші власні візити. Адресу бере на себе проксі, а решта це налаштування браузера. Ця інструкція про перевірку власного сайту, тобто про задачу, яку описує наша сторінка регіонального тестування: як налаштувати все в Chrome, що записувати під час кожної перевірки і коли VPN впорається не гірше.

За чим сайт визначає вашу країну?

Зазвичай за IP-адресою, часто разом з іншими сигналами. Їх п’ять, і беруться вони з різних місць.

• IP-адреса. Сервер або CDN перед ним шукає адресу в базі геолокації. Cloudflare, наприклад, може передати серверу-джерелу країну відвідувача дволітерним кодом у заголовку CF-IPCountry (довідник заголовків Cloudflare).
• Мова браузера. Chrome надсилає заголовок Accept-Language, складений із бажаних мов у його налаштуваннях, а скрипти сторінки читають той самий список із navigator.languages (MDN).
• Часовий пояс. Скрипт може прочитати часовий пояс комп’ютера як назву на кшталт Europe/Berlin через API Intl.DateTimeFormat, у полі timeZone його resolvedOptions() (MDN).
• Точне місцезнаходження. Geolocation API повідомляє координати лише після дозволу відвідувача (MDN), тож більшість сайтів їх так і не отримує.
• Те, що сайт уже знає. Cookie з регіоном чи валютою, які ви вибрали минулого разу, або країна в акаунті, у який виконано вхід, можуть мати перевагу над адресою.

Таблиця «Звідки береться кожен сигнал і як налаштувати його для перевірки» ставить кожному сигналу у відповідність налаштування Chrome, яке ним керує.

Чому самого проксі недостатньо?

Сигнали можуть суперечити один одному, і те, як сайт розв’язує цю суперечність, теж входить до того, що ви перевіряєте. Пустіть Chrome через німецьку адресу, але лишіть у списку мов англійську (США), і сайт, який бере мову з Accept-Language, а ціну з адреси, покаже ціни в євро англійською. Жоден справжній відвідувач у Німеччині з німецьким браузером такої сторінки не бачить. Залиште свої звичні cookie, і сайт може пропустити свою логіку визначення країни й показати регіон, який ви вибрали минулого місяця.

Тож налаштуйте кожен сигнал під ринок до першої перевірки і не змінюйте його в наступних.

Як налаштувати окремий профіль Chrome для кожного ринку?

Створіть окремий профіль Chrome для кожного ринку і дайте йому власний проксі. Профіль зберігає власну історію, паролі й налаштування (довідка Chrome), а також власні cookie (нотатки Chromium про каталог даних користувача). Cookie німецького профілю ніколи не потраплять до французького, і жоден із них не торкнеться вашої звичайної роботи в браузері.

1. Створіть профіль. Натисніть на зображення профілю праворуч угорі, виберіть додавання профілю Chrome і назвіть його за ринком, наприклад «Тест DE». Не входьте в ньому в обліковий запис Google, щоб з основного профілю нічого не синхронізувалося.
2. Установіть у цей профіль розширення для проксі. Розширення задає проксі для профілю, у який його встановлено (chrome.proxy API). Додайте до нього проксі ринку. Наш безкоштовний ProxyJam Connector якраз таке розширення.
3. Пускайте через проксі лише домени, які перевіряєте. Додайте правило для домену вашого сайту і його піддоменів, а резервний варіант лишіть на Direct. Власний трафік Chrome і всі інші сайти йдуть через ваше підключення, а проксі несе лише перевірку. Як правила перетворюються на PAC-скрипт і чому для HTTPS вони порівнюють лише імена хостів і ніколи шляхи, розібрано в статті як увімкнути проксі лише для деяких сайтів у Chrome (англійською).
4. Додайте хости, до яких звертається сторінка. Відкрийте DevTools, перезавантажте сторінку і перегляньте стовпець Domain на панелі Network (якщо його не видно, увімкніть його правим кліком на заголовках стовпців). Ціни часто приходять з API на іншому хості, а банер згоди може питати в сервера свого постачальника, яку версію показати. Хост, який не потрапив до правила, бачить вашу власну адресу, і на сторінці змішуються два ринки. Додайте кожен із них.
5. Задайте мову. У розділі «Налаштування», «Мови» додайте мову ринку до «Бажаних мов» і перемістіть її нагору (довідка Chrome). Саме цей порядок надсилає Accept-Language.
6. Задайте часовий пояс. Chrome бере часовий пояс з операційної системи, власного налаштування для нього немає. Для перевірки його може підставити DevTools: у налаштуваннях DevTools, на вкладці Locations, додайте локацію з Timezone ID і Locale ринку, а потім виберіть її на панелі Sensors (документація DevTools). Підміна стосується вкладки, на якій відкрито DevTools, тож відкрийте DevTools до завантаження сторінки. Змінити часовий пояс у системі теж можна, але тоді він зміниться одразу для всіх програм на комп’ютері.
7. Перевірте профіль. Додайте proxyjam.com до правила на хвилину і відкрийте What Is My IP. Сторінка має показати адресу проксі, розташовану в країні ринку. Після цього приберіть сторінку перевірки з правила.

Якщо проксі вимагає логін і пароль, а Chrome весь час їх питає, причини й рішення описано в статті про запит пароля проксі.

Що записувати під час регіональної перевірки?

Ті самі поля під час кожної перевірки, щоб дві перевірки можна було порівняти рядок за рядком. Список «Записуйте ті самі поля під час кожної перевірки» це базовий набір: ланцюжок редиректів, ціна й валюта, наявність, банер згоди і мова, а також адреса, яку використовував профіль.

Для ланцюжка редиректів увімкніть Preserve log на панелі Network: тоді запити, зроблені до редиректу, лишаються в списку (довідник DevTools щодо Network). У терміналі curl з -I і -L виводить заголовки кожного переходу, з -x надсилає запит через проксі, а з -H додає заголовок мови (посібник curl). Адресу проксі взято з діапазону, зарезервованого для документації (RFC 5737); підставте свою.

curl -sIL -x http://203.0.113.10:8080 -H "Accept-Language: de-DE,de;q=0.9" https://example.com/

Кожен рядок статусу, за яким іде заголовок location:, це один перехід. Простий запит, як цей, бачить редиректи, заголовки і ціни, записані в HTML. Оскільки -I надсилає запит HEAD, сервер, який відповідає на HEAD інакше, ніж на GET, може показати інший ланцюжок; приберіть -I і додайте -o /dev/null -D -, щоб вивести заголовки звичайного запиту. Скриптів curl не виконує, тож для банера згоди чи ціни, яку підставляють після завантаження сторінки, потрібен профіль браузера.

Ведіть один рядок на перевірку і одну таблицю на ринок. Різниця між двома перевірками варта розслідування лише тоді, коли адреса, мова і часовий пояс обидва рази були однакові; якщо щось із цього змінилося, ви порівнюєте два різні налаштування.

Ланцюжок редиректів важливий не лише для QA. Google пише, що адреси його краулера за замовчуванням, схоже, розташовані в США і що він не надсилає заголовка Accept-Language (Google Search Central), тож Google може не просканувати й не проіндексувати версію для ринку, до якої можна дістатися лише через автовизначення. Версія з власною URL-адресою цієї проблеми не має.

Чому для повторних перевірок статична адреса краща за ротаційну?

Для порівняння потрібно, щоб за раз змінювалося щось одне. Ротаційний пул видає іншу адресу на кожен запит або на кожну сесію, і в кожної адреси свій запис геолокації і своя мережа. Коли ціна змінюється між понеділком і четвергом, ви не можете сказати, чи змінився сайт, чи адреса. Статична адреса тримає точку огляду незмінною, тож випадає з порівняння. Роботу з однією адресою і вибір адрес із пулу докладніше порівнює стаття ISP чи резидентні проксі.

Статична адреса теж може зсунутися: бази геолокації оновлюються, і адресу можуть записати за іншою країною. Тому перевірка через What Is My IP іде перед кожною перевіркою, зокрема перед першою. Ротаційний пул кращий інструмент, коли вам потрібно багато різних адрес на одному ринку одночасно.

Коли досить VPN, а коли ні?

VPN досить для одноразового погляду: чи завантажується німецька головна сторінка, чи з’являється банер. Це швидко, і в багатьох VPN уже встановлено.

Коли перевірку треба повторювати, VPN поступається у трьох речах:

• Застосунок VPN зазвичай пропускає весь трафік пристрою, тож усі програми й вкладки разом опиняються в країні перевірки, і два ринки не можна тримати поруч.
• Його вихідні адреси ділять багато користувачів, і в даних про IP вони утворюють відому категорію: комерційні бази мають поле для адрес, зареєстрованих на постачальників анонімних VPN (документація MaxMind). Сайт, який його читає, може поводитися з відвідувачем через VPN інакше, і тоді перевірка записує саме таке поводження.
• Вихідна адреса може змінюватися від одного підключення до іншого, а це повертає проблему ротаційного пулу.

Де тут ProxyJam?

ProxyJam продає статичні резидентні (ISP) проксі: адресу в країні, яку ви вибираєте, зареєстровану на інтернет-провайдера, що лишається вашою на оплачений період. Для цієї задачі це означає одну адресу на ринок. Країни перелічено на сторінці локацій проксі, сьогодні їх 77, а ціни за IP за період на сторінці цін. Якщо адреса почне геолокуватися поза країною, яку ви купили, це підстава для безкоштовної заміни в межах місячного ліміту, встановленого розділом 2.5 Умов надання послуг.

Продукт продається за країною, тож різницю між двома містами він показати не може. До того ж він призначений для перевірки власного сайту: використовувати адресу, щоб дістатися до вмісту, який сайт приховує від вашої країни, забороняє розділ 5 нашої Політики прийнятного використання. Каталог є на сторінці ISP-проксі, а що таке ISP-проксі взагалі, пояснює стаття що таке ISP-проксі.