Почему не открывается сайт на хостинге

Запуск Web-cервера Nginx

Debian/Ubuntu/Centos:

/etc/init.d/nginx start

Сайт выдает «It works!»

Распространенные причины, почему появляется данное сообщение:

1. домен создан, но кэш DNS еще не обновился. Обновление занимает от 2 до 72 часов.

При смене IP-адреса сайта в ISPmanager — WWW домены нужно также менять IP и в пункте «Доменные имена». Затем необходимо обновить домен на внешних серверах имен кнопкой в виде аптечки «Обновить».

2. В пункте «WWW домены» в настройках домена в графе «Индексная страница» указано имя файла, отсутствующего на сервере (в таком случае по домену может также выводиться страница «Index of …». Данное поле можно оставлять пустым: в таком случае откроется страница index.html, если ее нет — index.php.

3

Важно, чтобы все файлы CMS и сайта были загружены в директорию вашего домена /www/имя_домена.. В остальных случаях необходимо подробно разбираться в конфигурационном файле.

В остальных случаях необходимо подробно разбираться в конфигурационном файле.

VMmanager/VEmanager:

«Управление»=>«Виртуальные машины»=>Выделить нужный сервер=>Кнопка «Перезапуск»

Проблемы запуска Web-сервера

Пример описания

Панель ISPmanager 5=>Система=>Службы=>В строках nginx и httpd должны быть включены лампочки, если лампочки не горят, то выделить нужное имя процесса=> Кнопка «Старт»

Пример описания

2. Установка SSL-сертификата

После того, как вы сделали все внутренние и внешние ссылки относительными, проверили доступность медиа-контента и скриптов по протоколу HTTPS, можно заняться установкой и настройкой SSL-сертификата.

— Выбор и приобретение подходящего SSL-сертификата

Существует несколько видов SSL-сертификатов. В зависимости от специфики вашего проекта, нужно выбрать наиболее подходящий сертификат.

1. Обычные сертификаты подходят физическим и юридическим лицам, выдаются на один домен и их выпуск занимает несколько минут. Здесь происходит лишь проверка принадлежности домена тому, кто запрашивает сертификат.

2. EV (Extended Validation). Сертификаты с расширенной проверкой компании. Помимо принадлежности домена тому, кто запрашивает сертификат, здесь также проверяются наличие организации, свидетельство о государственной регистрации, наличие названия компании в whois домена, проверочные звонки и многое другое. EV-сертификат дает возможность получить зеленую строку в адресной строке браузера с названием компании (как вы уже заметили это у Твиттера или на других сайтах).

3. Wildcard. Сертификаты, которые выдаются на все поддомены одного домена. Если у вас много региональных или других поддоменов, то обязательно нужно брать wildcard-сертификат.

4. С поддержкой IDN. Не все сертификаты поддерживаются для кириллических доменов. Если у вас кириллический домен, то нужно искать сертификаты с поддержкой IDN.

Подробнее о видах сертификатов можно ознакомиться в этой статье:http://habrahabr.ru/company/tuthost/blog/150433/

— Установка сертификата на сервере

Большинство хостеров предоставляют возможность через панель управления быстро установить выданный сертификат. Если у вас возникнут с этим проблемы, обратитесь в тех-поддержку хостинга или наймите на 1 час программиста. Установка обычно происходит пару минут, но при этом сам сервер должен поддерживать SSL протокол. Если у вас не популярный хостинг, то уточните у хостера, поддерживают ли они SSL и как вам можно установить сертификат.

Сертификат не привязывается к IP или хостингу, поэтому, его можно установить на любой выбранный вами хостинг, но конечно там, где вы размещаете свой сайт. Если текущий хостер не поддерживает SSL, то придется перейти к другому.

— Проверка доступности сайта через HTTPS-протокол

Установив ssl-сертификат, убедитесь, что теперь сайт доступен по двум адресам, с http:// и https://. Если по какому-то адресу он оказался недоступным, то нужно срочно искать причину и решать эту проблему.

1. Подготовка сайта

Исправить некоторые моменты в коде сайта лучше до перехода на HTTPS, чтобы избавиться от возможных технических проблем.

— Смена ссылок внутренней перелинковки с абсолютных на относительные.

Относительные ссылки бывают двух типов:

1. Относительные вне зависимости от домена

— абсолютная./about/ — относительная.

2. Относительные вне зависимости от протокола.

— абсолютная//devaka.ru/about/ — относительная

Необходимо использовать ссылки последнего вида, когда вы исключаете название протокола

Таким образом, не важно, на HTTP ваш сайт или на HTTPS, он будет всегда ссылаться на страницы с тем же протоколом

Обратите внимание, что мы говорим про внутренние ссылки, так как внешние сайты могут вовсе не поддерживать HTTPS, поэтому ссылки на них мы оставляем как и были

Если у вас несколько связанных проектов или поддоменов одного сайта, и все из них вы переводите на HTTPS, то относительная структура ссылок поможет правильной индексации поисковыми системами и верному перенаправлению пользователей.

— Исправление вложений медиа-контента

Проверьте, какой медиа-контент (изображения, видео, презентации, и др.) вы используете у себя на сайте и по какому протоколу его запрашиваете. Здесь необходимо тоже все перевести в относительные адреса, и тогда при переходе на HTTPS у вас медиа-контент также будет подгружаться с защищенных сайтов. Но стоит убедиться, что он действительно доступен по HTTPS.

Если используемые вами картинки хранятся на вашем сайте, то просто используйте относительные адреса //site.ru/img/mega-image.jpg. Если вы подгружаете картинки с внешних ресурсов (CDN или других сайтов), то они также должны поддерживать HTTPS, иначе стоит отказаться от этих вложений.

Популярные сервисы, которые позволяют внедрять свой контент, типа YouTube, SlideShare, виджеты VK или Facebook, и другие, уже давно поддерживают HTTPS, поэтому с ними проблем не возникнет. Но если вы используете медиа-контент с непопулярных сервисов, то уточните, будет ли этот контент работать/отображаться, если вы смените протокол.

— Исправление подключений внешних скриптов

Во внешних скриптах также нужно использовать относительные URL. Например, для библиотеки jQuery, вместо кода:

Нужно использовать:

Также и с другими скриптами: Яндекс.Метрика, LiveInternet, Google Analytics, Яндекс.Директ, различные javascript библиотеки и др. Здесь принцип тот же: популярные сервисы и библиотеки поддержкивают HTTPS, а вот с непопулярными могут возникнуть проблемы (как например, у ПриватБанка или Корреспондента с сетью MediaTraffic, которые до сих пор её использует по небезопасному соединению).

Подготовительная работа может занять много времени, поэтому все эти исправления лучше делать до полного переноса сайта с HTTP на HTTPS. Если для некоторых проектов стоимость переноса зависит в большей степени от стоимости SSL-сертификата и 1 часа программиста, то у других проектов стоимость переноса как раз заключается в подготовительных работах, так как не все партнеры, которые помогают этим проектам монетизироваться, могут поддерживать защищенный HTTPS протокол.

Ошибка 404 (http status 404) — что это значит?

В статье рассмотрим, что означает ошибка 404 на сайте. Ошибка 404 — это код ответа сервера, который сообщает пользователю, что сервер не может найти запрашиваемые данные. Почему такое может произойти? Есть несколько возможных причин:

Мы рассмотрим, что делать с ошибкой 404 и как исправить.

Как убрать ошибку 404 на сайте, созданном на CMS (WordPress, Joomla, 1С-Битрикс и т.д.)

На сайтах, созданных с использованием CMS, встречаются различные страницы с ошибкой 404 (http status 404). В зависимости от типа страницы с ошибкой различаются причины возникновения и пути решения проблемы:

Если вы видите на своём сайте стандартную ошибку 404 REG.RU:

Error 404 not found в REG.RU

В большинстве случаев проблема связана с отсутствием конфигурационного файла .htaccess. Как избавиться от ошибки 404? Создайте в корневой папке сайта пустой текстовый файл с расширением .htaccess и добавьте в него стандартные директивы для используемой CMS. Стандартные директивы приведены в статье: Файлы .htaccess для популярных CMS.

Важно: в панели управления cPanel файл .htaccess по умолчанию скрыт (т.е. он существует, но не виден)

Следуйте инструкции, чтобы включить отображение файла. Затем сверьте его содержимое со стандартным.

Если файл .htaccess существует и его содержимое корректно, а ошибка 404 not found сохраняется, обратитесь .

Если вы видите иную страницу ошибки, которую отдает CMS сайта. Например:

Ошибка на WordPress

Пользовательская ошибка 404 not found

Возможно, страница не создана или не опубликована на этапе размещения сайта в админке CMS. Также ошибка может быть связана с формированием «человекопонятных» ЧПУ-ссылок с помощью SEO-плагинов. Чтобы избавиться от проблемы, необходимо обратиться к веб-разработчикам сайта или на тематические форумы, на которых представлена необходимая техническая информация (ошибка http 404).

Как быстро устранить ошибку 404 на сайте, созданном без использования CMS

На сайтах, созданных без использования CMS, код ошибки 404 отображается следующим образом:

Что означает это сообщение?
Запрашиваемые страница/файл отсутствуют или размещены в неправильной папке (не в корневой папке сайта).

Что делать?
Откройте корневую папку сайта в панели управления хостингом и проверьте, находятся ли в ней файлы вашего сайта.

Как создать пользователя для базы данных

Вот и пригодились данные записанные вами ранее. Сейчас нужно будет создать пользователя и пароль для базы данных.

Шаг 1.

Нажмите на название базы данных – далее нажмите на закладку «Privileges» — Add a new User

Создание пользователя

Шаг 2.

Введите имя и пароль, выписанные из файла wp-config.php. В качестве хоста (Host) указываете localhost. Отмечаете все опции «Check All» и жмёте кнопку «Go».

Новый пользователь

На этом создание и настройка базы данных и сопутствующих элементов закончена. К этому моменту скорей всего, копирование файлов сайта завершилось.

Перезапускаем Денвер и пробуем запустить сайт на локальном сервере.

4. Сообщение поисковикам о переносе

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

— Добавление https-версии сайта в панель для вебмастеров

И в Google и в Яндексе необходимо добавить и подтвердить новый сайт, указав версию https. Теперь у вас в списке сайтов будет и та и другая версии. Для Google дополнительных настроек больше делать не надо, достаточно присутствия 301 редиректов.

— Изменение адреса в панели для Яндекса

Для Яндекса необходимо у HTTP-сайта указать главное зеркало HTTPS. Делается это в панели для вебмастеров в меню “Настройка индексирования” — “Главное зеркало” — “Установить протокол HTTPS”.

— Перенос дополнительных настроек в панели для вебмастеров со старого хоста на новый

Если для старой версии сайта в панели у вас присутствовали дополнительные настройки, то их нужно перенести на новую версию, чтобы она воспринималась аналогично. Например, одни из важных настроек, которые надо проверить и перенести, это:

– Настройки региона (геотаргетинг)
– Файлы Sitemap.xml
– Список ссылок в Disawov Tool для Google
– Исключенные параметры URL для Google

Рекомендации по переносу сайта

Этап №1. Общеподготовительные работы.

На данном этапе мы руководствуемся двумя основными правилами:

1. Никаких работ с контентом сайта во время переноса.
2. Перенос сайта в пятницу и на выходных – плохая примета.

Следуя этим прописным истинам, мы согласовываем время переноса сайта с владельцем и его контент-менеджерами. Все работы по добавлению товаров, статей, написанию комментариев и т.д. приостанавливаются.

Даже если клиент умоляет нас сделать перенос в пятницу во второй половине дня, наш ответ – нет. Почему? На выходных всегда может пойти что-то не так: техподдержка хостинга перестанет отвечать; клиент не сможет проверить работоспособность сайта, потому что уехал на дачу; у программиста куплены билеты «в театр»…

Этап №2. Подготовка нового сайта.

Основная задача этапа – синхронизировать информацию на текущем и новом сайтах.

Импортируем новые товары, заказы, статьи, комментарии, пользователей, остатки по товарам на новый сайт.
Со старого сайта переносим коды счетчиков и виджетов (GoogleAnalytics, ЯндексМетрика, LiveInternet, чат-онлайн, картпротектор, коллбекхантер и т.п.)

ВАЖНО не делать этого раньше времени, чтобы не нарушить показатели статистики. Не забываем о бэкапах.
На хостинге заказываем бекап файлов и БД нового сайта

После чего бекапы выкачиваем на жесткий диск.
Параллельно заказываем создание бекапа файлов и БД текущего сайта. Бекапы также сохраняем на жесткий диск.

Этап №3. Закачка нового сайта и подготовка к подмене.

1. Создаем на хостинге папку на уровень выше корня текущего сайта и закачиваем туда архив нового сайта. Получается примерно вот так:

В папке www находится текущий сайт, в папке new – новый.

2. Распаковываем архив с новым сайтом в папку new.

3. Создаем новую базу данных и импортируем в нее БД нового сайта (которую мы выкачали на предыдущем этапе).

4. Прописываем в новом сайте путь к созданной БД, а также имя пользователя (логин) и пароль.

5. Очищаем кеш CMS, если необходимо.

6. Проверяем, не поступили ли новые заказы на основной сайт. Если поступили, повторно синхронизируем базу данных на сайтах.

Этап №4. Подмена.

Тут все просто. Переименовываем папку www на old, а папку new на www. Как только мы это сделаем – начнет отображаться новый сайт.

Этап №5. Тестирование и настройки.

Первым делом проводим тестирование основного функционала сайта – пробуем оформить заказ. Если всё проходит нормально, приступаем к отладке внутренностей сайта:

1. Открываем сайт для индексации в robots.txt (на тестовом домене он был закрыт).
2. Если необходимо – прописываем новый путь к файлу, в котором хранятся пароли входа в админ. панель, пароли синхронизации с 1С.
3. Пробуем создать новый товар – проверяем, записывается ли новая информация в БД. Прикрепляем к товару изображения – проверяем, работает ли нарезка фото и накладывание водяного знака.
4. Подключаем и настраиваем прием платежей через электронные деньги (Приват24, LiqPay, Интеркасса).
5. Проводим более детальную проверку работоспособности сайта – регистрация/авторизация пользователей, добавление товаров в избранное/сравнение, добавление комментариев к товарам.

В самом конце тестируем отправку писем о заказе клиенту и администратору сайта.

Переадресация на странице входа в панель управления (консоль)

При попытке зайти на страницы /wp-login, /wp-admin происходит редирект на главную страницу сайта.Возможные причины

• Неправильные значения полей URL сайта и домашнего URL в таблице wp-config
• Ненастроенные постоянные ссылки
• Ошибки в .htaccess

Варианты решения

Очистите файлы cookie и кэш браузера и убедитесь, что в вашем браузере включен прием cookie.

Перезапустите браузер и попробуйте войти снова.

Деактивировать все плагины (см. предыдущие пункты).

Использовать тему по умолчанию (см. предыдущие пункты).

Удалите файл .htaccess из корневого каталога вашего сайта. (см. предыдущие пункты).

Добавьте в файл wp-config.php и добавьте эти строки (не забудьте заменить example.com собственным URL и добавить www. если вы используете этот префикс).

define(fWP_HOME*, fhttp://example.comf); define(1WP_SITEURL1, 1 http://example.com*);

После смены хостинга и DNS серверов сайт не открывается

Третий раз за день натыкаюсь на одну и ту же проблему: люди перенесли сайт с одного хостинга на другой и попутно поменяли DNS сервера, после чего у них открывается все нормально, но поступают жалобы от пользователей о том, что сайт недоступен или открывается старая версия с покинутого хостинга. Хотя у большинства все таки открывается нормальная версия.

Обычно время обновления серверов NS заявляется от 24 до 48 часов, хотя даже у таких тормозов как Ру-Центр или Рег.ру это занимает 5-6 часов; но в данном случае вероятнее всего возникли проблемы с кэшем зоны DNS на стороне клиентов, т.к криворукие админы (провайдерские или свои) могут выставить лимиты жизни кэша зоны до нескольких недель, т.ч не помогают даже никакие шаманства с зоной на своей стороне.

Поэтому в данном случае клиенту испытывающему проблемы с открытием сайта для начала надо попытаться обновить локальный кэш ДНС: две клавиши WIN + R -> cmd -> OK -> ipconfig /flushdns  а также перегрузить браузер, щелкнув в страницу правой клавишей мыши в сказать Обновить текущую страницу. Только в этом случае обновляется кэш, т.к когда нажимаешь F5, то страница вполне может использовать устаревший, имеющийся в системе кэш сайта.

Если это не помогает, то лучшим вариантом будет прописать руками кошерные гуглевские DNS сервера: Центр управления сетями и общим доступом -> выбираем активное соединение (например Беспроводное) -> Свойства -> Протокол Интернета версии 4 -> Свойства -> Использовать следующие DNS сервера -> вписываем 8.8.8.8 и 8.8.4.4 ->  ОК-ОК-ОК

Как частный случай данного, можно прописать новый IP адрес сайта, руками в файле C:\Windows\System32\drivers\etc\hosts в виде:
IP-addr www.site.ru

Теперь собственно о том, как этому безобразию противостоять или минимизировать время простоя.

В моем понимании – лучший вариант вообще использовать либо доменные сервера регистратора, либо облачный хостинг DNS вроде clouddns, где просто меняется ориджин зоны и субдомен www и все начинает крутиться на новых IP буквально через минуту. У CloudDNS анлим доменов стоит $22 в год, что, как мне кажется, при активном использовании доменов – мизер.

Если есть возможность редактирования зоны руками, то в ней желательно выставить, за неделю до переезда, минимальные значения TTL в SOA записи, для того чтобы кэш устаревал максимально быстро. Но, к сожалению, для опытных админов- это не проблема, т.к видимо в конфиге named.conf задается max-cache-ttl который по дефолту составляет 7 суток. Также при редактировании зоны руками, необходимо поменять серийные номера зоны, для того чтобы BIND понимал что зона изменилась.

VN:F

please wait…

Rating: 10.0/10 (4 votes cast)

VN:F

Rating: +2 (from 2 votes)

После смены хостинга и DNS серверов сайт не открывается, 10.0 out of 10 based on 4 ratings

Как создать копию базы данных (бэкап) на хостинге

Я буду показывать пример на своём хостинге от Спринтхоста. И если у вас другой хостинг, — это не страшно. Принцип у всех одинаков, отличается лишь интерфейс.

Шаг 1.

Для того чтобы узнать какую базу данных копировать, — нужно открыть на хостинге папку в которой размещён ваш сайт public_html/ИМЯ ДОМЕНА и найти файл wp-config.php. Для этого вы можете использовать файловый менеджер хостинга или ftp-соединение.

Файл конфигурации wp_conf

Открываем файл для просмотра и ищем имя базы данных DB_NAME.

Имя базы данных

Также запишите имя пользователя и пароль, они пригодятся дальше

И обратите внимание на кодировку базы, её нужно будет учитывать при создании базы данных на локальном сервере Денвер. У меня utf8

Шаг 2.

Теперь, когда известно какая база данных нужна, входим в административную панель хостинга и открываем раздел «База данных» > «Базы данных MySQL».

Управление базами данных

Перед вами откроется весь список баз данных. И вот тут нужно выбрать базу сайта, который вы собираетесь переносить на Денвер.

Выбор базы данных

Далее, откроется список таблиц в базе данных. И здесь же будет кнопка «Скачать резервную копию».

Резервное копирование

Жмём на неё и скачиваем базу данных к себе на компьютер.