Что такое маскировка домена и как скрыть настоящий 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 Domai, когда пользователь добавляет 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 требует защищённого соединения. Но ограничения браузера на сторонние cookies продолжают действовать.

Есть ещё Same-Origin Policy. JavaScript родительской страницы не получает свободного доступа к содержимому iframe, загруженного с другого origin. Для разрешённого обмена сообщениями между страницами используется postMessage().

Наконец, поисковые системы могут индексировать содержимое iframe отдельно от родительской страницы, а для сайта, который рассчитывает получать поисковый трафик, это является существенным недостатком.

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

 

 

 

 

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

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

Принцип действия следующий: браузер отправляет запрос на mycompany.com, прокси обращается к app.example.net, получает ответ и возвращает его посетителю.

Упрощенная схема работы Reverse Proxy изображена на схеме ниже.

 

 

Получается, что браузер взаимодействует с публичным доменом, а запросы к исходному приложению выполняет прокси-сервер и при правильной конфигурации пользователь работает с приложением через mycompany.com, а все необходимые запросы проходят через прокси, так что адрес исходного сервера в браузере не появляется.

Правда, прокси должен быть правильно настроен, ведь он должен корректно обрабатывать заголовки, cookies, перенаправления и особенности самого приложения. Иначе главная страница откроется, а авторизация или переходы по ссылкам начнут работать неправильно.

Этот подход часто используется для веб-приложений, корпоративных сервисов и проектов, которые работают на нескольких серверах.

 

 

Настройка маскировки домена через 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.

 

Похожая проблема возникает и с cookies. Так, если upstream отправляет строку:

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

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

 

Хорошая новость состоит в том, что Nginx позволяет переписывать доменный атрибут с помощью инструкции:

proxy_cookie_domain app.example.net mycompany.com;

Но перед применением нужно будет проверить, как приложение использует cookies и не зависят ли от исходного домена другие механизмы авторизации.

 

Отдельной настройки могут потребовать 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-статусы, перенаправления и cookies. Во вкладке 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. У регистраторов эти термины иногда пересекаются, поэтому лучше проверять фактическую работу услуги.