Example com — это домен example.com, который стандарт RFC 2606 зарезервировал специально для примеров в документации. Он принадлежит IANA, его нельзя купить или зарегистрировать на себя, а почтовых ящиков на нём не бывает. Поэтому адрес user@example.com в форме или инструкции — всего лишь образец формата, а не настоящая почта.
Что за сайт example.com и кому он принадлежит
Если набрать в браузере example.com, откроется страница с заголовком Example Domain и парой строк текста: домен предназначен для иллюстраций в документах и может использоваться без согласования. Больше на сайте ничего нет — ни регистрации, ни личного кабинета, ни почты.
Домен администрирует IANA — служба, которая ведёт корневую зону DNS, реестры номеров протоколов и распределение IP-адресов. Если выполнить whois example.com, в поле регистратора будет указано RESERVED-Internet Assigned Numbers Authority: имя не продаётся, не освобождается и не может быть перехвачено после окончания срока. Так же устроены его «братья» example.net и example.org. Подробно о том, что показывает WHOIS и как его читать, — в статье WHOIS: как узнать информацию о домене.
Почему example.com во всех примерах: RFC 2606 и RFC 6761
В 1999 году вышел RFC 2606 «Reserved Top Level DNS Names». Он решал практическую проблему: авторы книг и спецификаций придумывали адреса для примеров, а придуманные адреса рано или поздно кто-то регистрировал. Читатель копировал конфигурацию из учебника — и отправлял запросы на чужой сервер. RFC зарезервировал четыре домена верхнего уровня (.test, .example, .invalid, .localhost) и три домена второго уровня: example.com, example.net и example.org.
В 2013 году появился RFC 6761 «Special-Use Domain Names». Он завёл официальный реестр доменов особого назначения и расписал, как с каждым из них должны обращаться приложения, резолверы и DNS-серверы. Например, для .invalid любой запрос должен заканчиваться ответом «такого имени нет», а имена в .localhost приложения вправе сразу направлять на петлевой адрес, не спрашивая DNS. Актуальный список ведёт IANA в реестре Special-Use Domain Names.
Какие домены зарезервированы и чем они отличаются
У каждого зарезервированного имени своё назначение, и путать их не стоит: одно резолвится в реальный сайт, другое гарантированно не резолвится, третье всегда указывает на ваш же компьютер.
| Имя | Документ | Как ведёт себя | Для чего |
|---|---|---|---|
| example.com, example.net, example.org | RFC 2606 | Резолвится, отдаёт страницу Example Domain | Адреса и ссылки в документации, книгах, статьях |
| .example | RFC 2606 | Не делегирован в корневой зоне, ответ NXDOMAIN | Примеры, где нужна целая зона: shop.example, mail.example |
| .test | RFC 2606, RFC 6761 | В публичном DNS не существует | Тестовые стенды и внутренние DNS-серверы для проверок |
| .invalid | RFC 2606, RFC 6761 | Любое имя гарантированно не существует | Проверка обработки ошибок, заведомо нерабочие адреса |
| .localhost | RFC 2606, RFC 6761 | Указывает на петлевой адрес 127.0.0.1 / ::1 | Локальная разработка на своей машине |
| home.arpa | RFC 8375 | Для домашних сетей, в интернете не резолвится | Имена устройств в домашней сети |
| .local | RFC 6762 | Обрабатывается multicast DNS (Bonjour, Avahi) | Автообнаружение устройств, не для своих зон |
Отдельно стоит зона .internal: ICANN зарезервировала её для частных сетей, и она никогда не будет выставлена на продажу. Это удобная альтернатива самодельным .corp, .lan и .home, у которых такой гарантии нет.
Что откроется по адресу https example com, http и www
Варианты с http://, https:// и www ведут на одну и ту же страницу. Домен резолвится, веб-сервер отвечает, а для HTTPS выпущен настоящий сертификат, так что браузер не покажет предупреждения. Это сделано намеренно: примеры кода с curl https://example.com или fetch('https://example.com') должны выполняться без ошибок, иначе новичок будет искать проблему у себя.
Убедиться можно одной командой:
curl -I https://example.comВ ответе будет строка HTTP/2 200 (или HTTP/1.1 200 OK, в зависимости от версии curl) и заголовки сервера. Если вместо ответа ошибка — проблема в вашей сети, прокси или DNS, а не в example.com.
Зато поддомены вроде api.example.com, app.example.com, test.example.com или proxy.example.com — это условность из документации. Работающего API, приложения или прокси по этим адресам нет, а подставлять их в реальные настройки бессмысленно.
Почта example.com: можно ли создать адрес user@example.com
Нет. Путаница возникает потому, что сайты показывают в поле ввода подсказку вида name@example.com. Это плейсхолдер: он показывает формат адреса, а не предлагает завести ящик на этом домене. Почтового сервиса там нет, и письмо на любой адрес в этом домене не будет доставлено.
Более того, домен явно сообщает, что почту не принимает. На момент написания он публикует так называемый null MX из RFC 7505 — MX-запись с приоритетом 0 и пустым именем сервера. Почтовый сервер отправителя, увидев её, сразу возвращает письмо с ошибкой, а не пытается доставить его несколько дней. Проверить можно так:
# Linux, macOS
dig example.com MX +short
# Windows (cmd)
nslookup -type=mx example.com
# Windows (PowerShell)
Resolve-DnsName example.com -Type MXЧтобы завести почту, нужен настоящий почтовый сервис — Яндекс Почта, Mail.ru, Gmail — или собственный домен с подключённой почтой. О втором варианте — в статье почта на своём домене: Яндекс 360, VK WorkSpace или свой сервер.
Что такое домен в электронной почте
Адрес состоит из двух частей, разделённых знаком @. Слева — имя ящика (логин), справа — домен, то есть сервер, который принимает почту для этого адреса. В ivan@yandex.ru домен — yandex.ru, в user@example.com — example.com. Чтобы узнать, какой сервер обслуживает почту домена, смотрят его MX-записи: как это работает, разобрано в материале MX-записи для почты.
Если сайт не принимает ваш адрес
Бывает, что форма пишет «введите адрес в формате name@example.com». Это значит, что в поле не хватает @ или домена, либо есть лишние пробелы. Вводить нужно свой реальный адрес, а не example.com. Если сомневаетесь, существует ли адрес, помогут способы из статьи как проверить, существует ли адрес электронной почты.
example.com в прокси, API и настройках сервера — это шаблон
Адрес прокси или сервера на example.com чаще всего ищут те, кто скопировал инструкцию буквально. В документации пишут server=proxy.example.com, host: api.example.com или smtp.example.com на месте, куда нужно подставить свой адрес. Если вставить шаблон как есть, программа честно попробует подключиться к example.com и получит отказ или чужую страницу-заглушку.
Порядок действий всегда одинаковый: найти в инструкции все вхождения example.com, выяснить настоящие значения у своего провайдера, администратора или в панели сервиса и заменить их. Это касается и ссылок формата t.me/proxy?server=...: адрес сервера в них должен быть реальным, example.com там — только образец в справке.
com.example в названии приложения: откуда берётся «com example game»
Названия пакетов Android и идентификаторы приложений строятся по правилу «домен наоборот»: компания с сайтом company.ru называет пакет ru.company.app. Android Studio при создании проекта подставляет по умолчанию com.example.myapplication, отсюда в логах и списках процессов встречаются com.example.game и похожие имена.
Такой пакет — признак учебного или незавершённого проекта. Google Play не принимает приложения с именем пакета, начинающимся на com.example, поэтому перед публикацией его меняют на свой домен.
Какой домен использовать в тестах и документации
Правило простое: в примерах, тестах и шаблонах не должно быть ни одного адреса, который может принадлежать реальному человеку или компании. Ниже — шпаргалка «задача → что использовать».
| Задача | Что использовать | Почему |
|---|---|---|
| Ссылка или адрес в статье, README, книге | example.com, example.org, example.net | Зарезервированы, открываются, ни на кого не указывают |
| Подсказка в поле email | name@example.com | Почта туда не уходит, null MX |
| Тест, где адрес не должен резолвиться | user@host.invalid, api.invalid | NXDOMAIN гарантирован стандартом |
| Локальная разработка | app.localhost, api.localhost | Всегда ваша машина, не нужен файл hosts |
| Тестовый стенд со своим DNS | shop.test, mail.test | Не пересекается с публичными зонами |
| Домашняя сеть | nas.home.arpa | Стандарт RFC 8375 для домашних сетей |
| Внутренние сервисы компании | поддомен своего домена (corp.company.ru) или .internal | Вы владеете именем, коллизий нет |
| IP-адреса в документации | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32 | Диапазоны для документации по RFC 5737 и RFC 3849 |
| Имя пакета приложения | ru.вашдомен.app | com.example отклоняется магазином приложений |
Две зоны лучше не использовать для своих нужд. Первая — .local: её обрабатывает multicast DNS, и на macOS и Linux с Avahi имена в ней могут резолвиться с задержкой или не резолвиться вовсе. Вторая — .dev: это настоящая доменная зона Google, и вся она внесена в список HSTS preload, поэтому браузер открывает такие адреса только по HTTPS. Локальный стенд на myproject.dev без сертификата просто не откроется.
Чем опасно выдумывать «реальные» домены в примерах
Придуманный адрес вроде test.com, mysite.ru или mail.test.ru почти всегда кому-то принадлежит или может быть зарегистрирован завтра. Например, test.com — обычный зарегистрированный домен со своим владельцем.
- Утечка данных. Тестовый скрипт отправляет письма на test@mail.ru или admin@site.ru — и они приходят реальному человеку вместе с содержимым тестовой базы.
- Запросы на чужой сервер. Читатели копируют конфигурацию из вашей инструкции, и их приложения обращаются к домену, который может перехватить кто угодно, зарегистрировав его.
- Фишинг по вашей документации. Если в справке упомянут свободный домен, злоумышленник может купить его и отвечать на запросы доверчивых пользователей.
- Коллизии имён. Внутренние зоны .corp, .lan, .home не зарезервированы стандартом так, как .test или .internal, и запросы к ним могут утекать в публичный DNS.
Если пример должен выглядеть правдоподобно, используйте поддомены зарезервированных имён: shop.example.com, mail.example.org, api.example.net. Для вымышленной компании подойдёт зона .example: company.example, billing.company.example.
Как проверить домен самому
Любые утверждения о домене — своём, чужом или example.com — проверяются за пару минут.
- Кому принадлежит имя и когда истекает регистрация — через WHOIS-проверку. У example.com вы увидите регистратора IANA; у выдуманного «тестового» домена — реального владельца или статус «свободен». Как проверить, свободно ли имя, которое вы хотите использовать, описано в статье как проверить, свободен ли домен.
- Какие DNS-записи опубликованы — через DNS Lookup: A и AAAA для сайта, MX для почты (у example.com это null MX), TXT для SPF.
- Отвечает ли сайт и что возвращает сервер — через проверку HTTP-заголовков: код ответа, редиректы, заголовки безопасности.
Частые вопросы
Можно ли купить или зарегистрировать example.com?
Нет. Домен зарезервирован стандартом RFC 2606 и закреплён за IANA. Он не продаётся, не освобождается и не участвует в аукционах. То же касается example.net и example.org.
Можно ли зарегистрироваться на сайте с адресом user@example.com?
Технически форма может его принять, но письмо с подтверждением не придёт: домен не принимает почту. Восстановить доступ к такому аккаунту будет невозможно. Используйте свой настоящий адрес.
Безопасно ли открывать example.com?
Да. Это статичная страница IANA без скриптов, рекламы и форм. Если по этому адресу у вас открывается что-то другое — реклама, редирект или предупреждение, — проверьте файл hosts, настройки DNS и расширения браузера.
Чем example.com отличается от .example и .test?
example.com — конкретный домен, который резолвится и открывается. Зона .example вообще не делегирована: любое имя в ней, например site.example, не существует. Зона .test предназначена для тестовых стендов со своим DNS-сервером.
Почему example.com открывается, а example.test — нет?
Для example.com в DNS опубликованы адреса веб-сервера, а зона .test в публичном DNS отсутствует — резолвер отвечает NXDOMAIN. Так и задумано: .test существует только в тех сетях, где вы сами настроили для неё DNS.
