Що таке маскування домену та як приховати справжню URL-адресу сайту

Адреса в браузері не завжди може збігатися з фактичним розташуванням сайту. Наприклад, компанія може розмістити свій інтернет-магазин на сторонній платформі, але при цьому зберегти для покупців власний домен, до якого вони звикли. Або, наприклад, розробнику потрібно показати замовнику додаток, який працює на тимчасовому сервері з довгою технічною адресою.

Для таких випадків існує маскування домену (Domain Masking), яке дозволяє відображати вміст одного веб-ресурсу за адресою іншого, зберігаючи в адресному рядку браузера обраний домен.

На перший погляд усе може здатися простим, коли користувач відкриває mycompany.com і бачить додаток, який фактично працює на app.example.net.

Але ось реалізація може виявитися складнішою, ніж здається, оскільки деякі способи маскування можуть заважати авторизації, створювати проблеми з індексацією або порушувати роботу внутрішніх посилань. Ну а спроба приховати справжню IP-адресу сервера взагалі вимагає окремого підходу, про який ми поговоримо в окремій статті.

Тому давайте розберемося в цій статті, як працює маскування URL, які технології для цього підходять і який із способів обрати для виконання конкретного завдання.

 

 

 

 

Як працює маскування домену

Припустимо, у компанії є домен mycompany.com, а її додаток розміщений за адресою app.example.net. Якщо налаштувати звичайне HTTP-перенаправлення (редирект), то браузер перейде на вказаний там домен app.example.net, і відвідувач побачить нову адресу.

А ось при маскуванні домену адресний рядок залишається колишнім - mycompany.com, хоча вміст при цьому може надходити з іншого сервера.

Реалізувати таку схему можна кількома способами:

• HTML iframe - зовнішній сайт завантажується всередині сторінки, відкритої на основному домені;
• Reverse Proxy - сервер приймає запити відвідувачів і самостійно звертається до вихідного додатка;
• Custom Domain - зовнішня платформа обслуговує додаток безпосередньо під доменом клієнта.

Останній варіант технічно відрізняється від класичного маскування, але часто вирішує те саме завдання з меншими витратами.

 

Правда, варто пам’ятати, що збереження адреси в браузері ще не означає, що вихідний домен став недоступним для виявлення, якщо у вас саме таке завдання. Його можуть розкривати як вихідний код сторінки, так і мережеві запити, HTTP-заголовки або налаштування самого додатка.

 

Чи можна приховати URL за допомогою DNS?

Іноді власники сайтів намагаються вирішити завдання маскування домену одним DNS-записом. Для цього, наприклад, створюють CNAME-запис і розраховують на те, що браузер почне показувати вміст іншого сайту під їхнім доменом.

Але, на жаль чи на щастя, DNS так не працює, і його завдання - визначити, куди надіслати мережевий запит. Наприклад, A-запис пов’язує домен з IPv4-адресою:

mycompany.com.    IN    A    192.0.2.10

А CNAME створює псевдонім іншого доменного імені:

app.mycompany.com.    IN    CNAME    service.example.net.

У другому випадку DNS-клієнт використовує записи service.example.net, щоб визначити IP-адресу для підключення. Але браузер продовжує звертатися до app.mycompany.com.

 

Тепер запит має обробити веб-сервер. Якщо він налаштований виключно на service.example.net, то відвідувач може отримати помилку TLS-сертифіката, сторінку іншого віртуального хоста або навіть відмову в обслуговуванні.

Тому багато SaaS-платформ пропонують функцію Custom Domain, коли користувач додає DNS-запис, підтверджує володіння доменом, а платформа налаштовує обробку запитів і HTTPS.

Виходить, що DNS допомагає скерувати запит на потрібний сервер, але самостійно маскувати URL він не вміє.

 

 

 

 

Маскування URL через HTML-елемент iframe

Один із найпростіших способів зберегти адресу в браузері - це вбудувати зовнішній сайт через HTML-елемент iframe.

Припустимо, на mycompany.com розміщена сторінка з таким кодом:

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <title>My Company</title>
</head>
<body style="margin:0">    <iframe
        src="https://app.example.net"
        title="My Company Application"
        style="width:100%;height:100vh;border:0">
    </iframe>
</body>
</html>

У підсумку, коли відвідувач відкриває mycompany.com, браузер завантажує всередині сторінки вміст app.example.net.

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

 

Чому iframe може не працювати

Багато веб-сайтів забороняють вбудовування своїх сторінок на сторонніх доменах. Для цього використовуються HTTP-заголовок X-Frame-Options та директива frame-ancestors політики Content Security Policy (CSP).

Наприклад:

X-Frame-Options: DENY

Або:

Content-Security-Policy: frame-ancestors “none”;

Обидва варіанти забороняють відображати сторінку всередині iframe.

Якщо зовнішній сервер повертає такі заголовки, то змінити ситуацію налаштуваннями батьківської HTML-сторінки не вдасться. Обмеження встановлено на стороні джерела вмісту.

 

Проблеми з cookies та авторизацією

Припустимо, відвідувач відкриває mycompany.com і намагається авторизуватися в додатку, завантаженому з app.example.net. У такому випадку додаток встановлює сесійний cookie. Однак для браузера це сторонній ресурс, оскільки iframe знаходиться на іншому сайті.

А сучасні браузери обмежують роботу сторонніх cookies. У результаті авторизація може завершитися успішно, але під час наступного запиту додаток втратить сесію.

Іноді розробники намагаються виправити ситуацію за допомогою такого заголовка:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=None

де SameSite=Noneдозволяє передачу cookie в міжсайтовому контексті, а Secureвимагає захищеного з’єднання. Але обмеження браузера щодо сторонніх cookie продовжують діяти.

Існує ще Same-Origin Policy. JavaScript батьківської сторінки не отримує вільного доступу до вмісту iframe, завантаженого з іншого origin.

 

Для дозволеного обміну повідомленнями між сторінками використовується postMessage().

Нарешті, пошукові системи можуть індексувати вміст iframe окремо від батьківської сторінки, а для сайту, який розраховує на отримання пошукового трафіку, це є суттєвим недоліком.

А ось де використання iframe дійсно доречне, так це для вбудованих віджетів, демонстраційних сторінок, а також окремих інтерфейсних компонентів. Однак, як ми вже з’ясували вище, для повноцінного інтернет-магазину або додатка з особистим кабінетом краще пошукати інший спосіб.

 

 

 

 

Маскування домену через Reverse Proxy

Існує ще один інструмент, придатний для маскування домену - зворотний проксі-сервер (Reverse Proxy), який дозволяє обслуговувати додаток під власним доменом, не вдаючись до використання HTML-фреймів.

Принцип дії такий: браузер надсилає запит на mycompany.com, проксі звертається до app.example.net, отримує відповідь і повертає її відвідувачеві.

Спрощена схема роботи Reverse Proxy зображена на малюнку нижче.

 

 

Виходить, що браузер взаємодіє з публічним доменом, а запити до вихідного додатка виконує проксі-сервер, і за умови правильної конфігурації користувач працює з додатком через mycompany.com, а всі необхідні запити проходять через проксі, тож адреса вихідного сервера в браузері не з’являється.

Щоправда, проксі має бути правильно налаштований, адже він повинен коректно обробляти заголовки, файли cookie, перенаправлення та особливості самого додатка. Інакше головна сторінка відкриється, а авторизація або переходи за посиланнями почнуть працювати неправильно.

Цей підхід часто використовується для веб-додатків, корпоративних сервісів та проєктів, які працюють на кількох серверах.

 

 

Налаштування маскування домену через Nginx

Давайте на конкретному прикладі подивимося, як налаштовується простий проксі в одному з найпопулярніших веб-серверів Nginx.

Припустимо, що DNS-запис mycompany.com вказує на сервер із Nginx, а сам вихідний додаток доступний через HTTPS за адресою app.example.net. Тоді базова конфігурація віртуального хосту виглядатиме приблизно так:

server {
    listen 443 ssl;
    server_name mycompany.com;
​
    ssl_certificate /etc/ssl/site.crt;
    ssl_certificate_key /etc/ssl/site.key;
​    location / {
        proxy_pass https://app.example.net;
​
        proxy_ssl_server_name on;
        proxy_ssl_verify on;
        proxy_ssl_trusted_certificate
            /etc/ssl/certs/ca-certificates.crt;
​        proxy_set_header Host app.example.net;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For
            $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Зверніть увагу, що в цій інструкції proxy_pass задає адресу вихідного додатка, тобто Nginx приймає запити відвідувачів і передає їх на цю адресу.

Директива proxy_ssl_server_name on вмикає SNI для HTTPS-з’єднання з upstream, proxy_ssl_verify on активує перевірку сертифіката, а proxy_ssl_trusted_certificate задає довірені центри сертифікації.

Також майте на увазі, що вказаний шлях до CA-сертифікатів характерний для Debian та Ubuntu, але в інших дистрибутивах він може відрізнятися.

Також зверніть увагу на рядок:

proxy_set_header Host app.example.net;

У цьому прикладі додаток отримує власне доменне ім’я, оскільки передбачається, що він налаштований обслуговувати саме app.example.net.

Ну а якщо додаток підтримує роботу під публічним доменом, то кінцева конфігурація може відрізнятися. Наприклад, йому може знадобитися вихідний Host та коректна обробка заголовків X-Forwarded-*.

Нагадаємо, що це базова конфігурація, яка передбачає наявність чинного TLS-сертифіката для mycompany.com та доступного upstream із коректним HTTPS.

 

Перевірка роботи Nginx

Після налаштування проксі необхідно перевірити його роботу. Для початку перевіряємо синтаксис конфігурації Nginx командою:

sudo nginx -t

Якщо помилок немає, тоді застосовуємо зміни конфігурації командою:

sudo systemctl reload nginx

 

А тепер перевіряємо відповідь сервера:

curl -I https://mycompany.com

 

Особливу увагу варто звернути на заголовок Location. Так, наприклад, додаток може повернути:

HTTP/1.1 302 Found
Location: https://app.example.net/login

У такому випадку браузер перейде на вихідний домен, і видима адреса зміниться.

 

Виправити це можна налаштуваннями самого додатка або директивою proxy_redirect у конфігурації Nginx. Перший варіант зазвичай надійніший, оскільки додаток має правильно формувати публічні URL-адреси.

 

Схожа проблема виникає й із файлами cookie. Так, якщо upstream надсилає рядок:

Set-Cookie: session=abc123; Domain=app.example.net; Path=/

, то браузер, який відкрив mycompany.com, не зможе прийняти такий файл cookie для іншого домену.

 

Хороша новина полягає в тому, що Nginx дозволяє перезаписувати доменний атрибут за допомогою інструкції:

proxy_cookie_domain app.example.net mycompany.com;

Але перед застосуванням потрібно буде перевірити, як додаток використовує файли cookie і чи не залежать інші механізми авторизації від вихідного домену.

 

Окремого налаштування можуть потребувати WebSocket-з’єднання, оскільки для них Nginx повинен правильно передавати HTTP Upgrade та відповідні заголовки.

 

І ще одна дрібниця, яка, тим не менш, може перерости у проблему - це абсолютні URL-адреси всередині HTML, CSS та JavaScript. Так, якщо додаток продовжує посилатися на app.example.net, то частина ресурсів може завантажуватися безпосередньо з вихідного домену.

Nginx вміє проксірувати запити, але не виправляє автоматично всю внутрішню логіку додатка, про що потрібно постійно пам’ятати.

 

 

 

 

Чим маскування домену відрізняється від редиректу

Маскування URL часто плутають зі звичайним перенаправленням (Domain Forwarding), адже на перший погляд механізми дійсно схожі, що може ввести в оману адміністраторів-початківців. Тому давайте приділимо трохи часу цьому аспекту й спробуємо розгледіти різницю між цими двома механізмами.

 

Отже, під час HTTP-перенаправлення сервер одразу повідомляє браузеру нову адресу ресурсу. Браузер одразу ж виконує перехід на новий ресурс і оновлює адресний рядок.

Наприклад:

HTTP/1.1 301 Moved Permanently
Location: https://newdomain.com/

Після такої відповіді користувач опиниться на newdomain.com.

 

При маскуванні ж вміст залишається доступним за початковою адресою, і досягається це, як ми вже згадували вище, через iframe, Reverse Proxy або пряму прив’язку домену до платформи.

Різниця стає добре помітною, якщо зібрати дані в порівняльну таблицю:

Технологія	URL зберігається	Особливості SEO	Складність
HTML iframe	Так	Обмежена індексація вмісту	Низька
Reverse Proxy	Так	Залежить від конфігурації	Середня
HTTP 301/302	Ні	Підходить для перенесення сторінок	Низька
Custom Domain	Так	Зазвичай кращий варіант	Низька або середня

 

 

 

 

 

Для чого використовують маскування URL

Тепер, коли ми розібралися з самим механізмом маскування домену, давайте розберемося з причинами таких дій, які зазвичай є цілком практичними. І тут усе просто: компанії хочуть показувати клієнтам зрозумілі адреси, а розробники - відокремити публічний інтерфейс від внутрішньої інфраструктури.

Наприклад, сервіс бронювання працює на сторонній SaaS-платформі, але компанія хоче, щоб клієнти відкривали його через власний домен.

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

Але є й цікавіший сценарій.

 

Один домен для кількох додатків

Припустимо, компанія використовує окремі сервери для CRM, білінгу та служби підтримки.

Початкові адреси:

crm.example.net
billing.example.net
support.example.net

За допомогою Reverse Proxy можна організувати доступ до всіх цих сервісів через єдиний домен:

mycompany.com/crm/
mycompany.com/billing/
mycompany.com/support/

У такому випадку відвідувач працює з однією системою, з одним доменом, хоча додатки можуть знаходитися на різних серверах.

 

Щоправда, розміщення в підкаталогах підтримують далеко не всі додатки, оскільки деякі з них використовують абсолютні шляхи від кореня сайту /, формують власні перенаправлення або очікують певного базового URL. У такому випадку все-таки буде зручніше використовувати піддомени.

 

 

 

 

Як маскування домену впливає на SEO

Не зайвим буде поговорити й про той вплив, який маскування домену чинить на SEO вашого проєкту, адже для пошукового просування спосіб реалізації має велике значення.

Найпроблемніший варіант - це, очевидно, iframe. Пошукові системи, звичайно, здатні виявляти вміст фреймів, однак немає жодної гарантії, що вони індексуватимуть цей текст як частину батьківської сторінки.

 

У випадку з Reverse Proxy ситуація дещо інша. Пошуковий робот отримує повноцінний HTML-документ під публічним доменом і може індексувати його звичайним способом, але тут виникає питання дублювання, оскільки якщо одна й та сама сторінка доступна за адресами:

https://mycompany.com/products/
https://app.example.net/products/

, то пошукова система може виявити дві версії одного вмісту.

У такому випадку для управління індексацією використовується канонічний URL (canonical).

 

Налаштування canonical при маскуванні

Якщо основною адресою обрано mycompany.com, то на сторінці можна вказати:

<link rel="canonical" href="https://mycompany.com/products/">

Цей тег повідомляє пошуковим системам бажану адресу сторінки.

Однак варто пам’ятати, що canonical - це лише рекомендація, тому Google може самостійно вибрати інший URL, якщо інші сигнали вказують на нього.

 

Тому, в контексті SEO, під час налаштування Reverse Proxy варто перевірити кілька моментів:

1. Внутрішні посилання. Навігація має вести на публічний домен і не повертати відвідувачів на технічну адресу додатка;
2. Наявність Sitemap.xml. Карта сайту має містити URL-адреси, призначені для індексації;
3. Наявність Robots.txt та meta robots. Переконайтеся, що потрібні сторінки доступні для сканування й випадково не закриті за допомогою noindex.
4. Дублювання сторінок. Якщо вихідний домен залишається публічним, то потрібно узгодити canonical, редиректи або інші способи управління індексованими версіями;
5. HTTP-статуси. Проксі повинен коректно передавати відповіді 404, 301, 503 та інші коди.

Останній пункт часто пропускають, і даремно, оскільки, наприклад, якщо неіснуюча сторінка через проксі повертає код 200 OK, то пошукова система може сприймати її як звичайний документ. У такому випадку з’являються помилки типу Soft 404.

 

Після налаштування корисно буде перевірити кілька сторінок вашого сайту через Google Search Console. Інструмент перевірки URL покаже, чи доступна сторінка для індексації та яку канонічну адресу обрав Google.

 

У підсумку можна сказати, що сама по собі маскування домену не покращує позиції сайту, оскільки для SEO важливіші зміст сторінок, їхня доступність та коректність технічних сигналів.

 

 

 

 

Чому маскування домену не працює. Усунення несправностей.

Буває, що головна сторінка відкривається нормально, але після авторизації користувач втрачає сесію. Або, наприклад, зображення завантажуються з помилками, хоча HTML-код відображається без проблем.

Нижче ми навели найпоширеніші причини таких проблем, зведені в таблицю для наочності.

Проблема	Можлива причина	Що перевірити
iframe не відображається	CSP або X-Frame-Options	HTTP-заголовки вихідного сервера
Після входу скидається сесія	Cookies, SameSite	Set-Cookie, налаштування авторизації
Перенаправлення на зовнішній домен	Абсолютні URL, заголовок Location	Перенаправлення застосунку
Не завантажуються CSS та JS	Шляхи, CSP, CORS	Вкладки Network і Console
WebSocket не підключається	Не налаштовано Upgrade	Конфігурацію Nginx
Помилка 502 Bad Gateway	Недоступний upstream-сервер	Мережу, TLS, журнали Nginx
Помилка HTTPS-сертифіката	Недійсний сертифікат або SNI	Конфігурацію TLS

 

Для діагностики всіх цих проблем зручно використовувати інструменти розробника браузера. Вкладка Network показує запити, HTTP-статуси, перенаправлення та файли cookie. У вкладці Console зазвичай видно помилки JavaScript, CSP та CORS.

 

Також можна відстежувати журнали самого веб-сервера Nginx за допомогою команди:

sudo tail -n 50 /var/log/nginx/error.log

 

А щоб перевірити ланцюжок перенаправлень, можна скористатися такою командою:

curl -IL https://mycompany.com

Тут параметр -L дозволяє слідувати за перенаправленнями, а -I запитує заголовки через HEAD. Однак деякі додатки обробляють HEAD і GET по-різному, тому у разі сумнівів варто перевірити звичайний GET-запит.

 

Якщо ж додаток постійно повертає відвідувача на вихідний домен, то проблема може бути в його налаштуваннях. А спроби виправити все виключно за допомогою Nginx іноді призводять до ще більш заплутаної конфігурації.

 

 

 

 

Коли маскування домену не потрібне

Маскування URL підходить далеко не для кожного завдання. Іноді власники сайтів намагаються зберегти адресу в браузері там, де достатньо звичайного перенаправлення або прив’язки власного домену.

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

 

З додатками на SaaS-платформах ситуація дещо інша. Багато сервісів уже підтримують функцію Custom Domain, яка дозволяє підключити власне доменне ім’я через DNS. У такому випадку не доведеться налаштовувати проміжний сервер або використовувати HTML-фрейми.

 

Якщо ж компанія використовує кілька додатків на різних серверах і хоче об’єднати їх під одним доменом, то стане в нагоді звичайний Reverse Proxy. Наприклад, Nginx може направляти запити до потрібного додатка залежно від піддомену або шляху в URL.

 

Для невеликих вбудованих компонентів іноді достатньо iframe. Але тільки якщо зовнішній сервіс дозволяє таке вбудовування і його функціональність нормально працює всередині фрейму.

 

Є ще один момент: не всі сторонні платформи дозволяють проксірування свого вмісту. Обмеження можуть бути прописані в умовах використання сервісу або реалізовані технічно.

Тому перед налаштуванням маскування варто перевірити, які можливості вже надає вихідна платформа. Можливо, потрібний результат можна отримати без додаткових серверів, складних конфігурацій і потенційних проблем із SEO.

 

 

Підсумовуючи, можна зазначити, що вибір методу залежить від конкретного завдання. Іноді потрібно просто прибрати довгий технічний URL з адресного рядка. В інших випадках потрібно закрити вихідний сервер від прямого доступу або об’єднати кілька додатків за однією публічною адресою.

І чим точніше визначено завдання, тим менше зайвих компонентів опиниться в інфраструктурі.

 

 

 

 

FAQ або Поширені запитання про маскування домену

 

Чи можна повністю приховати справжню URL-адресу сайту?

Гарантувати це неможливо. При використанні iframe вихідна адреса зазвичай видна в мережевих запитах браузера. Reverse Proxy дозволяє приховати безпосередні звернення браузера до upstream, але відомості про вихідний домен можуть зберігатися в інших місцях.

 

Чи шкодить маскування домену SEO?

Все залежить від обраної технології. iframe створює обмеження для індексації вмісту під батьківським доменом. Reverse Proxy дозволяє пошуковому роботу отримувати повноцінний HTML, але вимагає коректного налаштування canonical, посилань та управління дублюючими сторінками.

 

Чи можна використовувати CNAME для маскування URL?

Одного запису CNAME для цього недостатньо. Він допомагає визначити адресу сервера, але не змінює URL у браузері й не налаштовує веб-сервер на обслуговування нового домену. Для цього потрібна підтримка Custom Domain або відповідна конфігурація сервера.

 

Чим Domain Masking відрізняється від Domain Forwarding?

Domain Masking зазвичай означає збереження видимої адреси під час завантаження вмісту з іншого джерела. Domain Forwarding частіше використовується для перенаправлення відвідувачів на інший URL. У реєстраторів ці терміни іноді перетинаються, тому краще перевіряти фактичну роботу послуги.