Каждый сайт имеет доменное имя в сети Интернет (URL). Это адрес, на котором располагается ваш сайт.
Если у вас еще нет доменного имени, его можно купить у любого регистратора доменного имени (например, NIC.RU).
Чтобы запустить сайт на платформе OKsoft, нужно направить А-записи вашего домена на наш IP-адрес.
Проверить IP вашего сайта можно
* Для перенаправления домена необходимо воспользоваться вашим личным кабинетом регистратора доменного имени (при покупке домена вам предоставляется доступ).
В настройках DNS серверов нужно изменить или добавить две записи:
А-запись для домена без www: @ A 95.213.177.34
А-запись для домена с www: www A 95.213.177.34
Также некоторые регистраторы позволяют установить настройки для протокола IP6:
ААAА-запись для домена без www: @ ААAA 2a00:ab00:4300:15c::
ААAА-запись для домена с www: www AААA 2a00:ab00:4300:15c::
Изменения вступают в силу в течение нескольких часов (от 4-х)
Проверить вступили ли изменения в силу:
Вызовите командную строку в вашем компьютере;
Наберите ping имя вашего домена с www и нажмите Enter
Наберите ping имя вашего домена без www и нажмите Enter
Обе строки должны давать ответ с нужным IP
Инструкция для NIC.RU
Для изменения списка DNS-серверов следует:
Зайти в раздел «Для клиентов» на http://www.nic.ru/ ;
Указать номер своего договора и пароль;
Выбрать меню "Услуги" - "DNS хостинг" - "Заказ новой услуги";
Выбрать минимальный тариф, нажать "продолжить":
Ввести идентификатор DNSOKSOFT, нажмите "продолжить", затем "заказать":
Пополнить счет на нужную сумму, дождаться делегирования;
Выбрать в меню пункт «Услуги. Просмотр и изменение данных»;
Найти нужную услугу (Регистрация домена);
В столбце «Параметры», в списке «DNS-серверы домена:» перейти по ссылке «Изменить»;
Справа в меню отметить пункт "DNS-master";
Добавить записи:
Выбрать в меню пункт «Услуги. Управление DNS зонами»;
Нажать "Управление DNS зонами";
Выбрать домен;
Нажать "+ Добавить новую запись" и добавить две записи:
Дождаться вступления изменений в силу (около 4 часов)
Пример списка записей:
* При возникновении вопросов необходимо обратиться в техническую поддержку регистратора доменного имени, попросив помочь ПЕРЕНАПРАВИТЬ ДОМЕН
- Перевод
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS - страшная и непонятная штука. Эта статья - попытка развеять такой страх. DNS - это просто , если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System . Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .
Базовые штуки
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, - прим. пер. ).
Давайте взглянем на маппинг между именем и адресом:
$ dig web01.bugsplat.info
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
;; QUESTION SECTION: ;web01.bugsplat.info. IN A
dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов - AAAA . Давайте взглянем на ответ:
;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244
Оставшаяся часть ответа описывает сам ответ:
;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз , когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig "у, если бы информация не был закэширована:
$ dig +trace web01.bugsplat.info ; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms
Информация выводится в иерархической последовательности. Помните как dig вставил точку. после хоста, web01.bugsplat.info ? Так вот, точка. это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
$ dig -x 192.5.5.241 ; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.
Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае - f.root-servers.net .
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» - прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
$ dig petekeen.net mx ; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
$ dig www.petekeen.net ; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86
Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
$ dig www.petekeen.net @8.8.8.8
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect . Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:
$ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118
Этот IP принадлежит Namecheap"у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/
CNAME для Heroku или Github
Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию .dns Добавить метки
Услуга «Перенаправление домена» позволяет настроить правила и перенаправлять посетителя, обратившегося к доменному имени, на указанный вами интернет-адрес. Услуга поддерживает работу с любыми доменами. .
В этой статье мы расскажем о настройках для работы с услугой.
Настройка домена
Услуга может работать только в том случае, если ваш домен делегирован. Для делегирования домена необходимы DNS-серверы, которые могли бы сообщить пользователям сети Интернет информацию о вашем домене (зоне). Таких серверов должно быть два или более.
В услугу «Перенаправление домена» уже включена поддержка DNS . Если услуга заказывается на тот же договор, что и домен, то при заказе настройки производятся автоматически.
Также вы можете самостоятельно указать DNS-серверы в зависимости от уровня домена, для которого заказана услуга перенаправления:
ns3-fwl2.сайт
ns4-fwl2.сайт
ns8-fwl2.сайт
ns3-fwl3.сайт
ns4-fwl3.сайт
ns8-fwl3.сайт
ns3-fwl4.сайт
ns4-fwl4.сайт
ns8-fwl4.сайт
ns3-fwl5.сайт
ns4-fwl5.сайт
ns8-fwl5.сайт
Записи в файл зоны
Если вы используете DNS-сервера, включенные в услугу «Перенаправление домена», то необходимые записи вносятся автоматически.
При использовании своих DNS-серверов нужно внести в файл зоны домена на первичном DNS-сервере (primary) записи A. В рамках одной услуги перенаправления для самого домена и любого из его поддоменов необходимо указывать один и тот же IP-адрес.
В зависимости от уровня домена, для которого заказана услуга перенаправления, записи A должны быть следующими:
- для домена второго уровня, вида web-forward.ru
:
web-forward.ru. A 109.70.27.4
- для домена третьего уровня, вида test.web-forward.ru
:
test.web-forward.ru. A 109.70.27.5
- для домена четвертого уровня, вида forum.eng.web-forward.ru
:
forum.eng.web-forward.ru. A 109.70.27.6
- для домена пятого уровня, вида www.forum.eng.web-forward.ru
:
www.forum.eng.web-forward.ru. A 109.70.27.7
Настройка услуги «Перенаправление домена»
Перенаправление можно включить для домена, всех его поддоменов, а также настроить до десяти индивидуальных правил перенаправления для конкретных поддоменов.
Внести изменения в настройки услуги вы можете в Разделе для клиентов → Услуги → Просмотр и изменение данных .
Для каждого правила перенаправления можно указать следующие параметры:
1. Имя поддомена, для которого настраивается правило
Необходимо указать поддомен , с которого будет осуществлено перенаправление. Можно указывать:
- имя поддомена, для которого требуется настроить перенаправление. Допускается неограниченное количество уровней вложенности, но при этом длина записи, включая точки, не должна превышать 63 символа;
- «*» (звездочку), если необходимо задать общее правило перенаправления. Такое правило будет действовать для любых поддоменов, для которых не настроены индивидуальные правила.
2. Адрес перенаправления
URL страницы, на которую автоматически будет перенаправлен посетитель.
3. Способ перенаправления
Вы можете выбрать один из следующих способов перенаправления:
- Временное или постоянное перенаправление
Временное перенаправление (код HTTP ответа «302 Moved Temporarily»). Код ответа HTTP 302 сообщает клиентским приложениям (в том числе поисковым системам), что сайт перемещен временно. Устанавливается по умолчанию.
Постоянное перенаправление (код HTTP ответа «301 Moved Permanently»). Код ответа HTTP 301 говорит клиентским приложениям (в том числе поисковым системам), что сайт перемещен навсегда.
В обоих случаях посетитель автоматически переходит на URL той страницы, на которую было осуществлено перенаправление. Выбор способа перенаправления (301, 302) на практике имеет значение только для поисковых систем.
- Маскировка адреса во фрейме
При таком способе перенаправления веб-страница будет находиться внутри фрейма. При всех переходах по ссылкам внутри фрейма в адресной строке браузера посетители будут видеть доменное имя, с которого была осуществлена переадресация. В качестве заголовка (title) страницы будет отображаться текст, указанный вами в настройках правила перенаправления.
Если вы выбрали маскировку адреса во фрейме, то следует учитывать, что:
- при установке ссылок внутри вашей веб-страницы на другие ресурсы, в теге ссылки необходимо указать target=_top . В противном случае чужая веб-страница также будет открыта внутри вашего фрейма, и посетитель будет видеть в окошке URL ваше доменное имя. Пример правильного написания ссылки для этого случая: RU-CENTER
- истинный адрес веб-страницы, на которую осуществляется перенаправление, хотя и не отображается в строке URL, может быть легко вычислен любым посетителем.
4. Опция «С сохранением пути» .
При попытке обратиться к странице, размещенной на домене, для которого составляется правило, перенаправление произойдет на адрес перенаправления, к которому будет добавлен путь до этой страницы..web-forward.ru, то при обращении к странице dns.web-forward..
Что такое DNS. Сроки обновления DNS-записей. Как побыстрее начать работу с новым доменом. Типы записей DNS. Как настроить автоматические субдомены. Правильная переадресация на адрес без www в начале.
Что такое DNS
Интернет – сеть, связывающая миллионы компьютеров по всему миру. Некоторые компьютеры в этой сети включены круглосуточно – это сервера с сайтами и электронной почтой. Каждому компьютеру при подключении к интернету назначается числовой идентификатор – ip-адрес. Но обращаться к серверам по числовому идентификатору людям не удобно, поэтому были введены буквенные домены.
DNS (Domain Name System) – это система, обеспечивающая соответствие доменов ip-адресам. За хранение DNS-записей в интернете отвечает отдельный класс серверов – ns-сервера. Часть из них поддерживается администраторами доменных зон, другая – хостерами и интернет-провайдерами. У этих серверов есть своя иерархия, и обновляются записи на серверах не сразу: на некоторых – очень быстро, на других – в течение пары суток. Наиболее популярное программное обеспечение для ns-серверов называется BIND.
Сроки обновления DNS-записей
Распространённый вопрос у начинающих – когда заработает новый домен. Попробуем ответить и заодно разберемся, можно ли как-то ускорить этот процесс.
Итак, вы хотите, чтобы новый домен начал работать. Для этого нужно добавить записи в DNS и ждать, пока они растекутся по интернету. Время обновления записей составляет от нескольких часов до трех суток. Ограничения вызваны принципами работы DNS, являющейся распределенной и высоконагруженной системой.
После регистрации домена, или смены записей DNS, ваш сайт будет доступен для различных пользователей через различное время, в зависимости от особенностей работы их интернет-провайдеров. То есть для вас сайт может быть еще недоступен, а для кого-то доступен. Или наоборот. Это связано с тем, что каждый интернет-провайдер сам определяет время обновления кэша DNS на своих серверах.
Что касается субдоменов, то зачастую, при их создании, они становятся доступны либо сразу, либо в течение 5-20 минут (должны обновиться записи на ns-серверах хостера).
Как побыстрее начать работу с новым доменом
Если вы зарегистрировали домен, либо изменили записи DNS, и вам срочно нужно начать работу с сайтом, вы можете добавить одну строчку в файл hosts вашей операционной системы (в Windows файл находится по адресу C:\WINDOWS\system32\drivers\etc , папка по умолчанию скрыта, и необходимо включить отображение скрытых папок в панели управления):
xxx.xxx.xxx.xxx site.ru
где xxx.xxx.xxx.xxx – ip-адрес сервера, site.ru – доменное имя вашего сайта.
Типы записей DNS
Чтобы домен начал работать, вам необходимо задать для него несколько DNS-записей.
Запись NS необходима для указания DNS-сервера, обслуживающего ваш домен. Услуги своего DNS-сервера может предложить регистратор домена или хостинг-провайдер. Другой вариант – настроить собственный NS-сервер, и использовать его.
Запись A необходима для указания IP-адреса вашего сайта. IP-адрес предоставляет ваш хостинг-провайдер.
Запись AAAA используется для указания IP-адреса версии 6 (IPv6). На данный момент эти адреса еще не получили повсеместной поддержки.
Запись MX указывает на IP-адрес вашего почтового сервера. Необходима для доставки почты на почтовые ящики вашего домена.
Запись CNAME служит для указания одного домена в качестве адреса другого домена, то есть задает вашему домену или субдомену такой же IP-адрес, как и у домена, ссылку на который вы укажете в записи.
Запись PTR – это обратная запись, которая позволит при запросе IP-адреса вашего сайта, получить полное доменное имя. Важно, если вы используете для домена почтовый сервер, поскольку правильность PTR-записи проверяется многими почтовыми серверами (чтобы определить, не является ли письмо спамом). Эту запись устанавливает хостинг-провайдер. Проверить правильность записи можно с помощью специального сервиса . Зачастую проблем не возникает, и запись изначально установлена правильно.
Как настроить автоматические субдомены для каждого пользователя. Создание wildcard DNS-записи
Wildcard запись – это DNS-запись отвечающая за все субдомены *.site.ru . Указание такой записи может понадобиться, к примеру, для CMS (WordpressMU, Drupal), используемой для управления субдоменами.
Для создания такой записи необходимо зайти в раздел управления DNS-записями домена и добавить запись типа A, в качестве субдомена указать символ *, а в качестве адреса – IP-адрес сервера, зачастую совпадающий с IP-адресом, указанным для основного домена. Если вам не удается это сделать, нужно обратиться в техническую поддержку.
Заодно рассмотрим, как сконфигурировать Apache для работы с wildcard субдоменами. Пусть в конфигурационном файле сервера есть секция, описывающая виртуальный хост:
DocumentRoot "/home/site.ru"
ServerName "site.ru"
ServerAlias "www.site.ru"
ErrorLog logs/site.ru-error.log
CustomLog logs/site.ru-access.log common
Вам необходимо лишь добавить псевдоним *.site.ru:
ServerAlias "www.site.ru" "*.site.ru"
Правильная переадресация с www.site.ru на site.ru . Редирект 301
Часть пользователей ссылается на ваш сайт, добавляя к адресу www. Другие www не добавляют. Это может негативно сказываться на продвижении в поисковых системах. Устраним проблему на примере сервера Apache:
1. Убедитесь, что на сервере включен модуль ModRewrite: в файле httpd.conf cтрока LoadModule rewrite_module modules/mod_rewrite.so должна быть раскомментирована. Если вы его включили, то перезапустите Apache.
2. Добавьте следующие строки в файл.htaccess , заменив site.ru адресом вашего сайта:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.site.ru$
3. Попробуйте зайти на сайт, используя адрес www.site.ru в адресной строке браузера. Адрес должен измениться на site.ru .
4. Можно внести в файл.htaccess строки:
RewriteCond %{HTTP_HOST} !^site\.ru$
RewriteRule ^(.*)$ http://site.ru/$1
Это позволит правильно обработать запросы к вашему сайту, когда в конце домена стоит точка: site.ru. вместо site.ru
Надеемся, статья помогла получить представление о работе с доменами. Вопросы и замечания просьба оставлять в комментариях.
