Разное

Проверка хостинга: 2ip.ru | DDoS protection

16.01.2023

Содержание

Тестирование хостинга rusonyx.ru / likes / блог студии Клондайк!

Почему выбрали для полномасштабного анализа именно Русоникс? Потому что компания активно развивается, участвует во всех профильных мероприятиях — одним словом на виду, а у нашей студии давние проблемы с выбором партнёра. Подробней о наших мучениях в статье «Особенности национального хостинга».

Виктор ТаранТех. Директор студии Клондайк


Исходные данные:

  • Хостинг: rusonyx.ru
  • Тариф: Сервер без забот — VPS
  • Вид анализа: соответствие требованиям CMS 1С-Битрикс
  • Анализ проводил: Таран Виктор, технический директор студии «Клондайк».
  • Дата тестирования — июнь 2013г.

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

Постараюсь провести непредвзятый обзор хостинга и найти его узкие места (на «правильных» вещах мы не будем заострять внимание, подразумеваем, что услуга должна иметь максимально возможное качество).

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

Далее по тексту авторский текст помечен курсивом, а ответ администрации хостинга синим.

1. Тестируем административную панель

Сразу видим влияние Parallels на сервер, а следовательно технологии виртуализации становятся понятны в явном виде — можно в лес не ходить virtuozzo и, как ни печально, PleskPanel.

В свое время я начинал именно с этой панели и считал ее достаточно удобной, но развиваясь, мои потребности росли, а плеска все так и оставалась совершенно не удобная и нефункциональная панель, помноженная на самую дорогую панель в мире, она явно этого не стоила. PleskPanel хорошо подходит для легких проектов, но если говорить о полнофункциональной панели, она конечно «отдыхает», хотя проект активно развивается. Вот некоторые хостеры, установив даже ISPmanager, умудряются и без того кривую панель довести до абсурда, так что «хрен редьки слаще». Но это дело предпочтения, и явно не этого обзора. Мое же сердце отдано ispconfig3.

ДНС/SOA записи

Как у большинства хостингов ДНС/SOA записи заводятся достаточно криво. Заводим новый домен.

Теперь редактируем ДНС/SOA записи:

Пока с виду все хорошо и логично. Но что будет после применения? Я поставил галочку «управлять ДНС».

В зоне никакого управления не появилось. Видны только NS сервера — и как я должен ей управлять?! На самом деле такая проблема встречается достаточно часто, и редактор зоны расположен в другом месте. Вначале вы заводите ДНС, а потом ее ищите в PleskPanel и редактируете. Было бы логичнее сделать это в одном месте. В данном же случае есть некие ограничения PleskPanel, посему думаю лучший вариант — это дать ссылку на редактор зоны. Так при заведении ДНС у вас не возникнет вопросов, где искать редактор зоны.

В свою очередь в момент подготовки статьи к публикации, разработчики хостинга активно обсуждали с нами эти вопросы и пообещали добавить текстовое сообщение, куда идти дальше для редактирования зоны. А вот прямую ссылку добавить там будет трудно ;(. Это частично спасет положение.

Так же нет возможности принудительно скинуть кэш для данной зоны, придется тупо ждать до 2-х суток (по факту через 20 минут уже бы все работало) — хотя на своих серверах ДНС, я скидываю сразу.

Больше ничего страшного не нашлось.

А вот большой мануал «начать» порадовал — действительно 4 страницы текста по сути, ничего сверхъестественного, но большинству клиентов будет полезно. Единственное, нет ссылок на почту, phpmyadmin, avstats в едином файле — их бы я тоже собрал бы в одну кучу.

2. ТЕСТИРУЕМ 1С-БИТРИКС

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

Если ты «зареган» — у тебя есть пароль. Если нет, то собственно и IP, и технического домена у тебя тоже нет — куда лезть то?

Данный вопрос так же обсуждался с представителями компании, и они смогли достаточно внятно мотивировать присутствие данного пароля. При существующей конфигурации сервера он действительно нужен. Хотя я на их месте попробовал бы решить этот вопрос другими способами. Но не суть важно.

В ходе тестирования выяснился действительно важный момент.

При установке 1С-Битрикс база данных создается сама! Не спрашивая меня, они подправили скрипт bitrixsetup.php и будут поддерживать эти исправления в будущих релизах скрипта. Во истину спорный момент. Но вроде как для удобства, однако пропустили в этом удобстве два очень важных на мой взгляд момента.

  1. Битрикс по умолчанию предлагает UTF-8 и CP-1251, в данном случае база создается по умолчанию в UTF-8 и вам ручками придется, править кодировку через phpmyadmin если ваш сайт под CP-1251. Вопреки мнению админов хостинга такие сайты есть и не редкость.
  2. Как и нормальный адекватный человек я не начинал инсталляцию, не создав базу данных. А следовательно, мне их база уже ни к чему, поскольку пирожок хорош к обеду, и о том, что база будет создана за меня, никто не уведомил (кстати я не против, если пароль в ней будет отвечать безопасности мониторинга качества 1С-Битрикс). А следовательно меня нужно об этом информировать заранее или не информировать, а сразу после оплаты давать мне возможность сразу перейти к заливке сайта, говоря о создании всего окружения, ДНС и базы — в общем «расслабьтесь и откиньтесь на спинку кресла», давайте свой бэкап и мы все сделаем. Возможно предложить два варианта Advanced и Fastsetup.

Ну, а если мне как порядочному некомпетентному сотруднику веб студии (а это для справки по моим прикидкам 80% сотрудников всех веб студий) вообще нужно после оплаты показывать кнопку «выбор редакции». Ни про какие домены названия и т.д. знать не хочу, на техническом домене разворачивайте дайте ссылку, дальше разберусь.

Потом уже админку для правок того, что необходимо. Кстати технический домен ОДНОЗНАЧНО должен быть закрыт от индексации поисковыми роботами.

ПРОДОЛЖАЕМ УСТАНОВКУ 1С-БИТРИКС, ПОКА БЕЗ СЮРПРИЗОВ.

Тестируем производительность.

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

Проверка php тоже не выявляет особо критичных заметок.

Пока не плохо, идем дальше. Акселератор стоит memcashed и php акселератор apc-php

Последний на мой взгляд самый перспективный из возможных.

Настройки вроде оптимальные, но 50% использованной памяти на чистом шаблоне без нагрузки на мой взгляд явно перебор. Да и 4 метра не всегда хватит как раз при тяжелых запросах. Но если говорить о параметре цена/качество, то в принципе терпимо.

ТЕСТИРУЕМ НАГРУЗКУ

Звезд с неба не хватает, но на средний проект вполне пойдет.

Я в свое время на отдельных проектах поднимал показатель страниц в секунду с 150 до 3500, но это требует грамотной отстройки location под каждый проект, да и ест куда больше памяти.

Как мы видим все требования 1С-Битрикс выполнены, для средне нагруженных сайтов этого вполне хватит.

3. А ХВАТИТ ЛИ НАМ ФУНКЦИОНАЛА САМОГО СЕРВЕРА?

Давайте зайдем в панель управления Plesk и посмотрим, что нам она дает и что дает сам хостер.

Тыкаю на первую кнопку в панели —Web Presence Builder, ну и ладно нам не особо и хотелось(видать опера по его мнению не заслуживает внимания).

А вот Файловый менеджер отличный. Мне понравился.

Хоть и не пользуюсь, но приятно.

Записи SPF/PTR присутствуют и даже в принципе настроены нормально, так же присутствуют все записи для IPV6.

А вот записи www почему то нет!? По всей видимости хостер считает это не важно, а я вот боюсь SEO-шник когда увидит, расстроится.

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

Так же нет возможности подключиться к БД на прямую из внешки с указанного IP.

НЕМНОГОЕ, ЧТО МОЖНО ДОСТАТЬ О СЕРВЕРЕ

Тут все без чудес, естественно centos 1Гб памяти.

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

НАСТРОЙКИ PHP

upload_max_filesize = 128Mб, не хватит на средний магазин, который имеет большую базу данных, а следовательно, phpmyadmin его не скушает. Ах пардон phpmyadmin висит вообще на другом конфиге и выдает свои гениальные и избитые донельзя (максимальный размер: 2,048МБ) А вот это уже реально критическое замечание!

Кстати во время написания статьи мы жарко обсуждали этот вопрос. Админы все в курсе, но не знают, как это убрать ссылаясь на невозможность это исправить. На что я в свою очередь могу заметить — все можно убрать, на крайняк он наверняка работает не под fastcgi а под mod-php,следовательно, банальный .htaccess может исправить это положение, поскольку php флаги можно будет выставить даже в нем, я уже не говорю о самом php.ini . Но для совести ребята, признав важность данного замечания сказали, что постараются исправить. Надеюсь у меня будет еще повод написать второю статью по этому хостингу уже с учетом этих исправлений.

post_max_size =8Mб, да ребята вообще в анабиозе плавают. В купе с upload_max_filesize это всего 8 метров. Обычные экселевские прайсы могут быть такого размера.

max_execution_time = 60, смешно, в реалиях жизни слишком мало.

memory_limit = 128Мб, да — это документированный размер, но фактически 1С-Битрикс работает минимум на 256 рекомендованных, бывает и того больше. 128Мб даже под средний каталог не хватает, а memory_limit исчезают из логов в нормальных магазинах от 512 метров! Если говорить о минимальных, то я бы рекомендовал 256Мб.

Однако мне удалось узнать, что парсер по отслеживанию warning в Apache и кнопочка поднять тарифный план в разработке в текущем тарифном плане.

Уже во время написания статьи появилось отличное меню, которое, на мой взгляд, позволяет 100% реализовать задачи по правке php.ini, на скриншоте не видно, там достаточно много параметров для редактирования. Снизу находится свободное текстовое поле для добавления любого другого значения php. ini и, если оно дописывается в конец файла, то этого хватит за глаза. Правда нет возможности его проверить. Такое решение частично снимает вопрос в пределах общей выделенной оперативной памяти.

И тут же есть переключатель представления apache CGI apache FastCGI. Кстати порадовал факт по умолчанию стоит FastCGI. Отличное решение!

SuPHP нет, да оно под 1С-Битрикс и не нужно.

Но не стоит забывать, что виртуальные машины на OpenVZ (он же Virtuozzo) реально из 1024MB даст вам в доступ до 70-80% ресурсов, остальное пространство будет, якобы, свободным, однако это не так. Большинство хостеров решают этот вопрос добавлением избыточного пространства, на всякий случай. При существующих же настройках все будет работать корректно, но, подняв лимит до 512 MB, вы явно рискуете переполнить память, и тогда сервер встанет колом. Так что, в некоторых случаях все-же придется повышать тарифный план, и если последнее будет реализовано будет здорово.

На данный же момент всю эту информацию можно легко выпытать со службы поддержки.

ПОЧТОВЫЙ КЛИЕНТ

Почтовый клиент atmail, хотя по мне так roundcube куда удачней, учитывая, что он еще и бесплатный так в 2 раза круче. Но тут дело админа. Почта же встала без проблем.

phpMyAdmin

Достаточно долго искал phpmyadmin, хотя знал где искать, и как оказалось он там, где искал, и находится. Заблудился так сказать в лесу из трех деревьев, но доблестная служба тех. поддержки подсказала (которую в свою очередь тоже, нужно было протестировать).

Хотя конечно надпись «вебадмин» у меня не совсем ассоциируется с phpmyadmin, да еще и логотип предательски другой. Думаю было бы разумно вставить на это место лого самого phpmyadmin, более чем уверен, что служба тех. поддержки уже устала показывать эту кнопку. Хотя наверно, те кто постоянно сидят в плеске уже привыкли 😉

3.1. Теперь о главном, SSH

Для обзора мне нужно посмотреть, как реально собран сервер, да и работать без этого попросту не возможно, так что ищем заветный root-ssh и первое что я вижу

Root-доступ к Серверу без забот™ — не предоставляется.

SSH убог, как и положено хостеру. Chroot в админке плески есть, но он попросту не отстроен и не работает. Учитывая, что есть jailkit который работает с коробки и требует отстройки 20 минут, конечно это печалит.

Для обзора нам предоставили именно сервер, который не требует настроек и администрирования, хотя у них есть и обычные серверы с root-доступом. Но нам как раз и надо найти оптимальны вариант для тех, кто сам не хочет заморачиваться с настройками.

Фактически на этом можно было бы и закончить обзор, поскольку данный сервер смело можно списать в утиль, для меня он не представляет интереса, поскольку представить работу без SSH мне достаточно трудно. Нет SSH — говорить о качестве просто глупо. Притом SSH без chroot окружения в ту же степь. В замен видим приятные обещания обновлять самостоятельно ядро системы и модули, что немного пугает.

Конфигов apache и nginx, ни их настроек нам никто не покажет а следовательно, что и как внутри — это догадки. Учитывая, что проксирующий сервер требует детальных изменений и уж точно знания того, что там есть.

Это печально. Так же огорчает отсутствие виртуальных хостов apache, поскольку в нем тоже есть много чего интересного и зачастую некоторые вещи отлично вписываются именно туда. А главное без этих файлов мы не сможем проверить стабильность и правильность их конфигурирования, особенно для SEO, поскольку даже отличный администратор может ничего не смыслить в SEO, и что на его взгляд вполне нормально, может оказаться совершенно не приемлемо для коммерческого сайта. Или же как в случае с NIC.ru, у которого есть проксирующий nginx, но нет локейшенов под статический контент (исправляюсь, сегодня посмотрел и нашел их в инклудах, но у nic.ru и без него хватает косяков) -но ник это отдельная история.

ПОСЛЕ ЗАПРОСА К РУКОВОДСТВУ rusonyx.ru — доступ SHH нам предоставили для данного обзора.

3.2. Продолжение тестирования (компания РУСОНИКС предоставила root-доступы)

Продолжение тестирования хостинга меня уже порадовало — доступы хоть и не полного рута, но для работы этого хватило.

По прежнему трудно что-то сказать о структуре дисковой системы — доступ до рейд массивов и так далее по прежнему отсутствует. Но мы получили большое количество дополнительной информации.

Однако нам удалось выяснить в последствие — дисковые массивы представлены в виден RAID10, 6 высокоскоростных жестких дисков. Проверить возможности нет, поверим на слово.

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

По количеству конфигов видно, что люди старались и видимо не зря. Проверив конфиги и их структуру, замечаний фактических нет, кроме перечисленных ранее. На их месте, я бы сократил количество конфигов. Фактически та же проблема у битрикса в их виртуальной машине, приходится очень долго и тщательно лазить по всем инклудам дабы не пропустить нужные опции, в свое время пришлось достаточно хорошо попатеть изучив их все. Раздельные конфиги — это здорово, но не до фанатизма пожалуйста, если вы их конечно планируете давать в доступ посмотреть.

Да есть пара моментов с локейшенами, try_file от которого я отказался вовсе, оставив только error_page 404 = @fallback; . Но в моем случае все заскриптовано и задается регулярными выражениями, в тогда все конфиги генерируются и не требуют столь детальной проработки всех кодов ответа сервера комбинаций с документ-рутом и так далее.

Отсутствует локейшен для статических файлов html:htm что в моем случае присутствует, но в них есть пара скрытых камней, которые мне в свое время пришлось повстречать.

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

Нет доступов до конфига nginx.conf */site-enable/*его конфиг

У клиента, нет возможности даже просто его посмотреть! Не говоря уже о изменение, даже у позорного nic.ru до них есть доступ. Кстати в которых локейшена под статику у них просто нет!

Фактически мне для полного счастья нужны следующие конфиги:

  • Nginx.access — не требуется дублируется в апач
  • nginx .error
  • Apache. access
  • Apache.error
  • Php.ini ( весь)
  • My.conf (весь) — для чтения
  • Httpd.conf (весь по моему сайту)— за минусом /stats /phpmyadmin и тд
  • Nginx.conf(весь по моему сайту) — за минусом /stats /phpmyadmin и тд
  • Kernel лог по возможности конечно
  • Ну и все что можно по почте.
  • Просмотр хотя бы только для чтения СОА запись моих доменов.

И команды:

  • /etc/init.d/nginx configtest
  • /etc/init.d/nginx reload
  • /etc/init.d/apache reload
  • crontab —e
  • rm -rf / — 😉 …шутка

Из дополнительных утилит и доступных команд я бы поставил и разрешил пользователю следующие:

  • htop;
  • atop — кстати, непонятно почему его нет, так же multitail — мне нравится но не обязательно, однако не думаю, что он повредит безопасность;
  • links — а вот его нужно обязательно тестировать сайт локально очень даже не плохо;
  • iotop — тут будет бесполезен инфы он много не получит;
  • wget — без него никуда 😉
  • chown — ОБЯЗАТЕЛЬНО не забывайте, что все сессии индивидуальные, и при подключение по ssh юзер будет root:root, ну или решить проблему с юзером 😉
  • chmod -ОБЯЗАТЕЛЬНО;
  • mysql;
  • mysqldump;
  • unrar — такое тоже бывает!

Естественно не хватает yum, думаю это даже не требуется обсуждать. Однако тут уже коммерческий интерес хостера может иметь свой довод.

Мы не может сохранить свой конфиг не хватает прав. Вот это можно было бы и поменять, в то уж совсем все закрыто.

А вот если бы мне уже был предустановлен zabbix или naigos с минимальной предустановкой, и отдельным входом, я бы полюбил этот хостинг больше всех в мире, но это мечты ;).

Начинается «вкусняшка», как заверили меня представители компании по телефону, мысль с zabbix им понравилась и она будет скорее всего реализована в ближайшее время с предустановленными минимальными настройками, нужными для полного счастья. Так же будет присутствовать полноценная система оповещения по алертам. Хочется поскорей посмотреть. Если же в конце концов там останется еще и возможность создавать свои мониторы, то это будет просто сказка. Для большинства — это даже слава не понятные, но для нормального проекта это не просто слово zabbix, оно равно слову золото!

4. Заключение

Из реальных вещей, не хватающих:

  1. Phpmyadmin всего 2 мегабайта файл аплоада, это смешно.
  2. Очень обрезанный chrootssh прям разочаровывает.
  3. Нет возможности изменить базовые настройки, такие как open_bade_dir и т.д.
  4. Нет возможности даже посмотреть свои конфиги, не говоря уже о их изменение.

Если же говорить о работе с ним в коммерческих целях, вполне можно, если вы не умеете работать с SSH. Если же SSH ваш хлеб и соль, то тут конечно все становится сложно, тут остается ждать.

Большинство хостеров куда слабее. Видно, что люди провели определенную работу и не плохую, единственное что не учли, реалии использования коммерческих сайтов. Но это и не мудрено, ведь это действительно мелочи на взгляд программиста администратора или менеджера. А вот разработчику или SEOшнику эти мелочи могут быт настолько критичны что проще сменить хостера и переехать на другой.

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

Сайты с большим каталогом имеют большую БД и многие страницы (технические, а не пользовательские) могут генерироваться более 30 секунд и иметь размер куда больше 8 мегабайт. К примеру выгрузка продаж за период и т.д. То же самое с размером файла. Учитывая ориентированность хостинга под 1С-Битрикс данные параметры безопасности излишни поскольку защита 1С-Битрикс хоть и взламываема но у меня есть достаточно обширная статистика по этому поводу и могу с полной ответственностью заявить что все это лишнее, файлы гигантского размера никто не заливает.

Очень странно показалось отсутствие chroot учитывая полную изоляцию контейнера от других пользователей. Мелочи с /tmp на самом деле всеми хостерами игнорируются. Соответственно вытекающие из этого мелочи с отсутствием yum итд. Но опять же нужно понимать, что все это предположение на косвенных фактах. Root доступа у меня нет и я не могу на 100% это утверждать.

Однако чуть отладив chroot окружение было бы куда приятней работать. Для меня так это единственное замечание. Все недостающее я бы доделал сам. Так же можно было бы создавать отдельные конфиги nginxapache .vhost для каждого пользователя и кидать их в ~etc/nginx/conf на подобие nic.ru дешево сердито а главное это 99% нужных вещей. Трудно говорить о архитектуре но в админке есть рестарт сервера, хотелось бы иметь возможность релоадапач и nginx непосредственно с консоли. А так же nginx configtest да и думаю curlftpfs тоже бы не помешал. В таком случае это был бы действительно мощный инструмент работы с хостенгом.

Отсутствие переключения php5.2 5.3 не порадовало, отнюдь не все запустится под 5.3 но если разбирать именно bitrix то это не принципиально. ( однако разработчики говорят что переключатель php скоро будет)

К стандартному набору добавил бы vim htop.

Немного не оптимизирован php-apc но опять же я не вижу всей машины, однако я бы дал в 2 раза больше памяти. 50% занятого пространства на холостом ходу это конечно многовато.

Ну и на последок убрал бы с админки все лишнее, куча ненужного функционала никогда никем не использованного только засоряет взгляд. Ну а две админки это уже эпичное мероприятие всех хостеров, порой их количество доходит до 4 как на majordomo и вводят в тупик даже опытных пользователей, поскольку требует изучение всех 4 админок с их особенностями. Ведь реально от админки нужно всего 5 вещи. Доступы Базы ДНС сайты, почта.

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

Также icpconfig3 имея интерфейс в 10 раз меньше , дает в 10 раз больше возможностей.

Сервер оптимизирован под 1С-Битрикс однако стоит обратить внимание на mbstring.func_overload =2 с ним могут быть проблемы и с дополнительно поставленными пакетами в частности phpmyadmin ( если ложить в сайт, roundcube, mpdf — генератор пдф и так далее, но тут уже ничего не поделаешь все же это хостер хотя можно и это решить,

5. МНЕНИЕ АВТОРА

В принципе все понравилось, все лаконично. Не скажу, что я бы сделал именно так, но это уже индивидуальные видения.

Сервер вполне пристойный, жаль что не удалось протестировать его должным образом. Серьезных замечаний нет, кроме катастрофически детской ошибки в phpmyadmin стоит 2 мегабайта размер файла! А в самом сайте всего 8, реально же требуется около 200.

Сайты на битриксе размещать на данном хостинге рекомендую. Установлены все необходимые акселераторы. До тех поддержки дозвон идет быстро, отвечают вежливо по сути. Есть ряд мелких недочетов присущих всем хостерам. Немного занижены размеры оперативной памяти в некоторых директивах. Но общее количество вполне достаточное для среднего сайта. И при небольших изменениях руками все исправляется. Оптимизирован my.conf, но в доступе его опять же нет ;(.

Из реальных недостатков отсутствие chroot притом сама плеска этот функционал позволяет сделать. ;(.

В дальнейшем постараюсь достать недостающие конфиги и сделать более грамотное заключение. И тут уже можно было бы говорить о высоконагруженных проектах. Графиках и сравнениях.

Однако для коммерческих проектов с посещаемостью от 2000 человек рекомендовал бы уже полноценный dedicatedserver. Но такие проекты будут корректно работать и на данном сервере.

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

  • Отделить БД от файловой системы, фактически при нагрузке на статическую часть генерация php не должна от этого страдать.

Как показала практика вынос базы на отдельный массив в моем случае даже SSD дал гигантский прирост стабильности скорости генерации контентной части даже при 100% загрузки I-O файлового массива скорость генерации страниц падала не значительно, при расположение базы на том же носителе в этом случае сайт уже ложился. Но тут уже нужно смотреть экономическое обоснование и структуру серверов. Однако я бы вынес на отдельные сервера базы данных.

  • Есть пара идей по кэшированию, но тут опять же, я не вижу всей схемы.

Что касается производительности она сопоставима с моими первыми сервером, что вполне не плохой показатель. Из дополнительных рекомендаций могу дать следующие.

  • Обратить особое внимание на alias к серверу поскольку их по умолчанию 3 и отнюдь не каждый человек знает о их существование, и если на них не обратить внимание, возможна индексация каждого из зеркал (что негативно может сказаться на SEO). Но сколько мне помнится есть кнопочка в админке выключающая эти зеркала — не проверял но если оно так, я бы ее сделал по ярче и поближе к глазам. В моей практике достаточно большие проекты проседали из за такой невинной вещи.

P.S. Утопичный в будущее или идеальный хостинг (людям со слабой психикой читать не рекомендуется).

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

  1. Webdav — шагает по планете, по умолчанию пихать его! Мне очень не понравился один из буржуйских хостеров, опробованный на днях, но мне очень понравилось что там в make wizard на 2 этапе мне предлагают создать вебдав доступ, притом FTP в выборе нет! Выбрать я могу ОС, даже линукс и мой навигатор в системе или прямая ссылка. Они же в свою очередь мне скидывают ярлык для рабочего стола, по которому я всегда смогу зайти в свою папку. Для большинства людей это вообще идеальное решение. Подключить файловую систему к разделу на мой взгляд куда лучше, чем FTP, не говоря уже о безопасности. Так что webDAV маст хев!
  2. Мы же говорим о профессионалах и virtuozzo, так что хочу иметь возможность слить свой контейнер в свою виртуальную машину! Кому не нужно, те не будут юзать, кто в теме оценят.
  3. И тут у меня особая вкусняшка.

Размышляя об оптимизации БД, мы пришли к выводу что было бы не плохо сделать кнопочку «ускорить базу данных», тем самым перекинуть в ее на отдельные SSD накопители, за денежку разумеется. Реализация этого весьма проста и коммерчески обоснована, да и плюсов дает реально много.

Опять меня осенило. У Вас же Nginx и virtuozzo! Почему же только ускорить базу данных? Предлагаю такой вариант: ускорить базу данных выносом на отдельный ssd. Вам мало? вы хотите еще ускорить, апгрейд еще раз стоит столько — готовы? Да.

У вас имеется 2 mysql сервера в состояние репликации. Ускорить еще? — Да!

У вас 3 сервера mysql с репликацией и т.д.! Это так легко реализовать и это нереально круто. Я могу разместить на таком сервере любой проект.

Но и это еще не все!

У НАС ВЕДЬ virtuozo и nginx, а nginx отлично умеет становится балансировщиком!

Ускорить файловую систему? — Да!

Создан 2 бэкэнд сервер. Еще?! Создан 3 бэкэнд сервер!

1 строчка в nginx! +ClusterFS или любой другой способ репликации файловых серверов и вуаля!

У МЕНЯ ПОЛНОЦЕННЫЙ МАШТАБИРУЕМЫЙ КЛАСТЕР с коробки в 1 клик! Да мне собственный дидиекейт вообще не нужен. Зачем, я нажму плюсик добавится еще машина! Какие админы, какие сервера в германии, я сам нажимаю кнопочку. Масштабируемость колоссальная. Аналогов просто нет. Самое легкое близкое приближение 1С-Битрикс веб кластер, но его цена, и кто и как его будет реализовывать? А тут просто +5 тысяч за 1 нажатие кнопочки и чудо сайт полетел, еще — не вопрос — еще 5 тысяч, сайт опять полетел! Да, для рабочего проекта это не деньги. Зато вкупе с zabbix и кластером — это полноценный инструмент.

Притом, если я смогу отдельно добавлять сервера для mysql отдельно, для файлов я смогу точно найти баланс между тем, что под мой проект реально нужно — и не платить за лишние ресурсы. Генерирую большие запросы — больше добавил mysql серверов. Отдаю много статики не вопрос — вот тебе больше бэкэндов и 1 mysql. Это ведь так легко, да я бы сам покупал такую услугу.

А такой ведь хостинг можно будет без зазрения совести позиционировать и под 100 000 человек нагрузки.

Ведь вы получаете, за какие-то копейки, полноценный кластер с распределенными базами каждая в своем контейнере, отдельное управление каждым контейнером. Файловый кластер, работающий с коробки. Как вариант, отдельно вынести проксирующий nginx! Да я получаю реально крутой масштабируемый проект на обычном хостинге!

Всё.

Как проверить и выбрать подходящий хостинг

Как выбрать хостинг и не прогадать? Ключ к правильному выбору — тестирование, проверка хостинга перед переездом. Практически каждый хостинг-провайдер предлагает своим новым пользователям тестовый период, в течение которого можно определить насколько хостинг отвечает вашим требованиям. Этот промежуток времени незаменим для проведения всевозможных проверок и тестов. Однако не все используют эту возможность по максимуму, так как далеко не каждый знаком с тем, как именно проверить хостинг перед переносом сайта. В статье мы поговорим о методах тестирования хостинга по нескольким ключевым параметрам, а также рассмотрим некоторые инструменты, которые могут помочь в этом процессе.

 

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

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

 

  • Самый оптимальный — восстановленным из бэкапа клоном своего сайта. Во многих CMS, например, в Битриксе, бэкап можно получить прямо из админки.  

  • Также во многих CMS есть встроенная возможность тестирования — в обход бэкапа можно воспользоваться ими.

  • В остальных случаях можно прибегнуть ко внешним сервисам — о них речь пойдёт ниже. 
     

Если вам нужно проверить виртуальную машину или облачный сервер, то к перечисленным выше вариантам следует добавить нагрузочное тестирование через SSH — например, Sysbench или UnixBench.

Теперь о целях. Вам потребуется проверить следующие параметры:

 

  • Время загрузки страницы или время отклика
    Как быстро сервер отзывается на запросы? Тут нужно представлять себе, с какими проблемами можно столкнуться, если не учитывать расположение сервера и основной аудитории посетителей сайта. Не имеет смысла хоститься за океаном — это приведёт к ужасному увеличению времени отклика. И даже расположение в соседней стране при совпадении нескольких неудачных условий может привести к огромным проблемам с сайтом!

  • Специализация хостинга
    Как правило, этот пункт актуален для виртуального хостинга, но и в случае преднастроенных VPS его тоже необходимо учитывать. Существуют готовые шаблоны настроек для разных проектов, а также существует комплектация серверов специально под CMS (например, под Битрикс или WordPress).

  • Производительность основных рабочих компонентов (PHP и MySQL)
    Здесь учитывается скорость выполнения PHP-скриптов и скорость обработки запросов к базе данных.
     

Это не всё, что заслуживает внимания, но эти пункты — ключевые. 

Разверните тестовую версию своего проекта или бэкап своего сайта на хостинге, куда хотите переехать. Это будет наша тестовая структура, она не обязана 100% повторять ваш проект, но в ней должны быть все те же компоненты и модули, которые предполагается использовать в работе.

Для получения реальных показателей мы рекомендуем проводить тестирование в разные дни и часы, так как нагрузка на сервера может варьироваться в зависимости от времени суток, как в будни так и в выходные. Наиболее показательными будут тесты, проводимые в пиковые часы. Условно самым загруженным считается промежуток между 18:00 и 21:30 в будние дни (в выходные время может варьироваться). 

А как непосредственно проверить хостинг сайта? Несколькими способами:

 

  • С помощью командной строки
  • С помощью специальных скриптов
  • С помощью онлайн-сервисов
     

Мы опишем использование всех видов инструментов тестирования, пока остановимся на тестировании с помощью командной строки, для чего потребуется использовать SSH — протокол удаленного администрирования, который предоставляют некоторые хостинги.

 

Тестирование с помощью командной строки SSH

Чтобы проверить такой параметр работы, как пропускная способность соединения, можно воспользоваться инструментом командной строки speedtest-cli. Для этого необходимо воспользоваться командной строкой SSH, зайдя с ее помощью на хостинг, загрузить speedtest-cli удобным способом, и запустить тест скорости. Инструмент выдаст три параметра:

 

  • Ping — промежуток времени, за которое отправленные пакеты информации доходят до адресата
  • Download — скорость с которой данные загружаются на сервер
  • Upload — скорость с которой данные отправляются с сервера
     

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

Далее рекомендуется с помощью все того же протокола SSH произвести тестирование скорости работы диска хостинг-сервера, на котором будет содержаться ваш онлайн-проект. Базовый способ осуществляется с помощью команды dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync. Она отображает как быстро диск выполняет команды, а также показывает скорость, с которой происходит запись данных на диск. Хотя эти сведения не являются исчерпывающими, представление о работе диска, предоставляемого хостинг-провайдером, они дадут.

 

Тестируем производительность PHP и MySQL

Для тестирования производительности хостинга в выполнении PHP-скриптов и скорости обработки баз данных MySQL существует удобный скрипт PHP Benchmark. Чтобы провести тест достаточно скачать архив со скриптом и установить его в корневой каталог вашего хостинга, предварительно открыв его у себя на компьютере (например, через “Блокнот”) и проставив значения, соответствующие загруженной на хостинг базе данных. После того, как вы откроете адрес расположения скрипта в браузер, он выведет вам результат тестирования. Скорость выполнения PHP-скриптов отображены в разделе Benchmark, а время выполнения запросов к MySQL — в одноименном разделе.

 

Онлайн-сервисы проверки скорости

Как проверить хостинг на скорость? Проще всего — с  помощью специального сервиса. Их довольно много, мы выделили несколько наиболее информативных и широко используемых на сегодняшний день:

Яндекс предлагает множество полезных инструментов для веб-аналитики, для проверки конкретно скорости отклика сайта существует раздел “Мониторинг” в графе “Отчеты”. В нем можно получить подробный анализ в графиках таких параметров как время до отрисовки сайта, ответ сервера, DNS, и других полезных категорий.

Инструмент по оценке работоспособности сайта от Google, дает оценку по 100-балльной шкале, также дает рекомендации по ускорению загрузки страницы с разных устройств. Самыми важными параметрами из выводимых будут индекс скорости и TTFB («Time To First Byte») или «Время до получения первого байта», то есть время за которое сервер получает запрос от пользователя и начинает отправлять ему информацию.

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

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

Выполняет сразу несколько тестов на скорость одновременно, и выводит таблицу с подробными данными, в том числе при условиях повышенного количества запросов. Основными параметрами являются First Byte и Speed Index.

 

  • Яндекс.Метрика
  • Google PageSpeed ​​Insights

  • PR-CY

  • GTmetrix

  • WebPageTest

  • Айри
     

IP помогает проверить скорость соединения вашего сайта с серверами, расположенными в разных точках России. Сайт просчитывает среднее время отклика сервера и отображает результаты в цветовом диапазоне (отклик до 0.2 секунд — зеленый, больше секунды — красный), что особенно полезно если ваш бизнес ориентирован на российский сегмент рынка, и вы работаете не только в крупных городах, но и регионах.

 

Стресс-тестирование при повышенных нагрузках

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

Предпочтительным инструментом для «домашних» отечественных проектов будет Яндекс.Танк, инструмент нагрузочного тестирования, в основе которого заложен высокопроизводительный асинхронный генератор нагрузки, способный генерировать десятки и сотни тысяч HTTP-запросов в секунду. Есть и другие годные инструменты того же рода: например, k6 и Loader (оба сервиса требуют предварительной регистрации для использования), которые отображают каким будет отклик хостинга при постепенном росте количества единовременно зашедших посетителей сайта в количестве от нуля до тысячи. За процессом теста можно следить в реальном времени, по окончанию будет создан подробный отчет.

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

 

Советы и рекомендации

Чтобы избежать ложных представлений о работе вашего потенциального хостинга, мы можем выделить следующие рекомендации по тестированию:

 

  • Обращайте внимание на тип данных, которые предоставляют вам сервисы по веб-анализу. Например, инструмент Google PageSpeed Insights выводит общую оценку основываясь не конкретно на работе вашего хостинг-сервера, а на качестве оптимизации содержимого вашего сайта в целом, чтобы создать представление об отклике сервера и скорости отображения сайта у пользователей, необходимо смотреть на показатели, непосредственно связанные с этими параметрами.

  • Воздержитесь от измерений скорости работы хостинга, засекая при этом время самостоятельно — такое “тестирование” будет иметь мало пользы, лучше всего опираться на точные измерения, которые можно получить программным путем.

  • Не рекомендуется оценивать скорость работы хостинга по загрузке с ваших собственных устройств, так как данные о сайте, сохраненные в кэше вашего браузера на компьютере или смартфоне, могут исказить информацию об отклике сервера у людей, которые впервые заходят на ваш сайт. Для объективной оценки нужно тестировать скорость работы самого сервера, без опоры на конфигурацию вашего устройства и интернет-соединения.

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

Заключение: как выбрать хостинг с помощью тестирования

Мы поговорили об основных параметрах, которые требуется проверить при переносе сайта на новый хостинг, описали основные параметры, которые требуется протестировать, и методы, с помощью которых это тестирования можно осуществлять, а именно тестирование через командную строку SSH, применение PHP-скриптов и онлайн-сервисов по анализу скорости работы сайта и его доступности для пользователей. Надеемся что эти методы помогут вам использовать бесплатный тестовый период вашего потенциального хостинга с максимальной пользой, и принять осознанное решение при выборе услуг.

Веб-хостинг — Лучший хостинг веб-сайтов

Веб-хостинг от простого до профессионального.

Множество вариантов хостинга веб-сайтов, гарантия безотказной работы 99,9%, бесплатный SSL-сертификат, простая установка WordPress и годовая подписка.

Да, вот как мы катаемся.

Начало работы

Начиная всего с

Выберите свой идеальный план веб-хостинга.
У нас есть все.

Общий
хостинг

Простой, доступный и включает в себя год. Счет!

Начинается с

Узнать больше

WordPress
хостинг

2,5-кратная скорость, повышенная безопасность и бесплатная миграция.

Начинается с

Подробнее

VPS
хостинг

Полный root-доступ в полностью масштабируемой среде хостинга.

Начиная с

Узнать больше

Выделенный
хостинг

Максимальная производительность. Получите полный контроль над сервером.

Начинается с

Узнать больше

Начните с HostGator.
Оставайтесь с HostGator.

Эта чешуя аллигатора.

Мы занимаемся этим с Юрского периода (он же с 2002 года), поэтому мы знаем, что для того, чтобы помочь новичкам и профессионалам, нужны всевозможные планы. Наши инструменты созданы для того, чтобы расти вместе с вами, поэтому вы никогда не перерастете нас (в отличие от некоторых других ребят, просто скажу). Вот что значит быть непоколебимым.

Бесплатный домен

Получите первый год регистрации домена у нас.

Бесплатные переносы сайтов

Уже есть сайт? Принесите его к нам, мы попали в ловушку.

Неизмеряемая пропускная способность

Привлекайте весь трафик, какой пожелает ваше маленькое сердце. Мы можем справиться с этим.

Гарантия безотказной работы 99,9 %

Лучшая возможность — это доступность, поэтому мы позаботимся о том, чтобы ваш сайт оставался в рабочем состоянии.

Установка в один клик

Интеграция ваших приложений не может быть проще.

Бесплатный сертификат SSL

Покажите своим посетителям, что вы серьезно относитесь к безопасности. Узнайте больше

Узнайте, что говорят эти клиенты.

Слайд 1 из 5

«Отличные серверные услуги. Быстрые и на 110% надежные серверы. Нравится отношение компании к клиентам.»

— Ян Пабло Рохас

«Я люблю HostGator, у меня никогда не было проблем, и поддержка потрясающая!»

— Джим Эдельстон

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

— Джазил Галарза

«Очень прост в настройке. У меня не было опыта работы с хостингом до регистрации в HostGator, но они сделали все просто».

— Мэтью Хадсон

«Я очень люблю HostGator! Серьезно! Отличный веб-хостинг по доступным ценам с лучшим обслуживанием клиентов!»

— Кори Джонсон

Поддержка 24/7/365.
Мы работаем, когда вы работаете.

Позвоните нам

(866) 964-2867

Напишите нам в чат

Напишите нам в Твиттере

@HGSupport

Найдите ответы

Учитесь

Есть вопросы?
Что ж, у нас есть ответы.

    Есть еще вопрос?

  • См. нашу базу знаний

Начало работы

Подключить личный домен | Firebase Hosting

Вам не нужно отказываться от своих уникальных доменных имен, ориентированных на бренд, с Хостинг Firebase. Вы можете использовать собственный домен (например, example.com или app.example.com ) вместо домена, созданного Firebase для вашего Сайт, размещенный на Firebase.

Firebase Hosting предоставляет SSL-сертификат для каждого из ваших доменов и обслуживает ваш контент через глобальную CDN.

В оставшейся части этого документа описаны шаги по подключению пользовательского домен.

При подключении личных доменов обратите внимание на следующее:
  • Каждый личный домен можно подключить только к одному сайту хостинга.
  • Каждый личный домен может иметь не более 20 субдоменов на домен вершины, из-за ограничений на чеканку SSL-сертификатов.

Настройте свой домен для хостинга

Убедитесь, что вы выполнили мастер «Начало работы» из вашего проекта Страница хостинга Firebase так что у вас есть сайт Firebase Hosting в вашем проекте Firebase.

Шаг 1 : Добавить домен
  1. Из вашего проекта хостинг страницы, войти в мастер подключения личного домена:

    • Если у вас есть только один хостинг-сайт, нажмите Добавить личный домен .
    • Если у вас несколько хостинг-сайтов, нажмите Просмотрите для нужного сайта, затем нажмите Добавить личный домен .
  2. Введите собственное доменное имя, которое вы хотите подключить к своему хостингу. сайт.

  3. (необязательно) Установите этот флажок, чтобы перенаправлять все запросы в личном домене на второй указанный домен (такой, что example.com и www.example.com перенаправление на тот же контент).

  4. Щелкните Продолжить , чтобы начать процесс проверки.

Шаг 2 : Подтвердите право собственности на домен

Если требуется в мастере настройки Connect Domain , подтвердите свой домен вершины.

Эти шаги гарантируют, что ваш домен еще не связан с Firebase и что вы являетесь владельцем указанного домена.

  1. На сайте провайдера домена найдите страницу управления DNS.

  2. Добавьте и сохраните новую запись со следующими входными данными:

    • Введите : добавьте запись TXT.

      Firebase Hosting требует, чтобы вы постоянно сохраняли эту запись TXT. присутствует в настройках DNS, чтобы подтвердить ваше право собственности на домен и разрешить Firebase назначать и обновлять SSL-сертификаты для вашего сайта.

      Ваш провайдер домена может указывать этот термин как «Тип записи».

    • Хост : Введите свой ключ домена вершины.

      Доказательство того, что вы являетесь владельцем домена вершины или корневого домена, право собственности на все его поддомены.

      Ваш провайдер домена может указать этот термин как «Имя хоста», «Имя», или «Домен».

    • Значение : Скопируйте уникальное проверочное значение в поле.

      Firebase Hosting проверяет это значение, чтобы подтвердить право собственности на домен.

      Ваш провайдер домена может указывать этот термин как «Данные».

  3. Подождите до 24 часов для распространения обновленных записей TXT, затем нажмите Проверить .

    Обратите внимание, что вы можете нажать Отмена , чтобы безопасно закрыть Подключить домен окно и открыть его позже. Это не влияет на распространение время, но вам будет предложено повторно введите свое доменное имя, когда вы снова открываете окно.

    После достаточного времени распространения нажмите Подтвердить в Connect Domain окно консоли Firebase позволяет вам начать SSL-сертификат процесс обеспечения.

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

    Если при нажатии Подтвердить появляется сообщение об ошибке, ваши записи не распространяется или ваши значения могут быть неверными.

Примечание: Не стесняйтесь проверить правильность обновления ваших DNS-записей с помощью Служба Dig в G Suite Toolbox. Обратите внимание, что хотя ваши записи обновляются, может потребоваться больше времени для распространение или предоставление SSL-сертификата.

Шаг 3 : Go live

В окне Connect Domain консоли Firebase выберите Быстрая настройка для нового сайта или Расширенная настройка , если у вас уже есть сайт работает на другом хостинг-провайдере и нуждается в миграции с нулевым временем простоя.

Быстрая настройка
  1. Вернитесь на сайт управления DNS вашего поставщика доменных имен, чтобы создать Записи DNS A указывают вашу страницу на хостинг Firebase. Добавить и сохранить записи со следующими входами:
  • Введите : добавьте две записи DNS A.
  • Хост : введите ключ личного домена для обеих записей.
  • Указываемый вами хост является доменом, на котором вы хотите обслуживать содержание; этот домен может быть доменом вершины или субдоменом.

    Ваш провайдер домена может указать этот термин как «Имя хоста», «Имя» или «Домен».

  • Значение : Назначьте одно значение каждой записи DNS A для указать ваш домен на указанные IP-адреса.
  • Ваш провайдер домена может указать этот термин как «Данные», «Указывает на», «Содержание», «Адрес» или «IP-адрес».
  • Подождите, пока ваш SSL-сертификат будет подготовлен. Это может занять до 24 часов после того, как вы укажете свои записи A на Хостинг Firebase. В большинстве случаев распространение ваших записей и предоставление вашего сертификата SSL произойдет в течение нескольких часов, в зависимости от вашего провайдера домена.
  • Расширенная настройка
    1. Окно Connect Domain консоли Firebase попросит вас предоставить токен для переноса существующего сайта. Ты нужно только выполнить одно из следующих действий, чтобы предоставить токен:
    • Обновить записи DNS TXT : Посетите сайт вашего провайдера домена. Сайт управления DNS. Добавьте запись TXT с ключом вашего домена и указанное значение.
    • Разрешить до 24 часов для распространения ваших записей TXT.
    • Загрузить файл на существующий сайт : Загрузить токен на ваш существующий сайт по указанному URL-адресу и проверьте его существование.
    Эта страница должна обслуживаться через HTTPS и не обязательно должна быть действительной или безопасный. Зашифрованный токен действителен только для одной попытки. Если миграция не удается, для ваших записей будет сгенерирован новый токен.
  • Выделите время для вашего SSL-сертификат быть обеспеченным. Это может занять до 24 часов. В большинстве случаев распространение ваших записей и подготовка вашего SSL-сертификата произойдет в течение нескольких часов, в зависимости от вашего провайдера домена.
  • После предоставления сертификата SSL вернитесь к своему DNS сайт управления DNS провайдера, чтобы добавить записи DNS A, указывающие на ваш страницу на хостинг Firebase. Добавляйте и сохраняйте записи со следующими входы:
    • Введите : добавьте две записи DNS A.
    • Хост : Введите свой ключ личного домена для обеих записей.
    • Указываемый вами хост является доменом, на котором вы хотите обслуживать содержание; этот домен может быть доменом вершины или субдоменом.

      Ваш провайдер домена может указать этот термин как «Имя хоста», «Имя» или «Домен».

    • Значение : Назначьте одно значение каждой записи DNS A для указать ваш домен на указанные IP-адреса.
    • Ваш провайдер домена может указать этот термин как «Данные», «Указывает на», «Содержание», «Адрес» или «IP-адрес».
    Обязательно удалите все записи A или записи CNAME, которые указать на других поставщиков. Также удалите все записи AAAA. Если какая-либо из этих записей типы существуют, Firebase не может предоставить SSL-сертификат.

    Дождитесь подготовки SSL-сертификата

    После того, как мы подтвердим право собственности на домен, мы предоставим SSL-сертификат для вашего домен и развернуть его в нашей глобальной CDN в течение 24 часов после того, как вы укажете свой Записи DNS A для хостинга Firebase.

    Ваш домен будет указан как одно из альтернативных имен субъектов (SAN) в SSL-сертификат FirebaseApp. Вы можете просмотреть этот сертификат с помощью браузера инструменты безопасности. Во время подготовки домена вы можете увидеть недопустимый сертификат, который не включает ваше доменное имя. Это нормальная часть процесс и разрешится после того, как сертификат вашего домена будет доступен.

    Для пользователей Advanced Setup ваш веб-сайт будет размещаться на вашем предыдущем хостинге провайдер, пока статус настройки в вашем проекта Страница хостинга Firebase обновления до Подключено .

    Примечание. Firebase Hosting автоматически повторно предоставляет SSL-сертификаты по мере необходимости для пользовательские домены.

    Ключ вашего личного домена

    При добавлении или редактировании записей DNS различные провайдеры домена ожидают вас для ввода различных входных данных для поля Host в их управлении DNS места. Ниже мы собрали общие данные от популярных провайдеров. Подробные инструкции см. в документации поставщика домена.

    Тип домена Ключ личного домена
    Домен Apex

    Общие входы включают:

    • @
    • Имя домена вершины (например, пример .com )
    • Оставить поле Хост пустым
    Поддомен

    Общие входы включают:

    • Полное имя поддомена (например, приложение пример .com )
    • Только часть поддомена (например, только приложение , и опустив . пример . com )
    • Только www для субдомена www. пример .com

    Общие поставщики доменов

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

    Облачная вспышка
    Значение проверки.
    Тип Хост Значение
    Ввод записей DNS TXT
    TXT пример . com указано в консоли Firebase
    Ввод записей DNS A
    А пример .com 199.36.158.100
    А www 199.36.158.100
    Домены Google
    Значение проверки.
    Тип Хост Значение
    Ввод записей DNS TXT
    ТХТ @ указано в консоли Firebase
    Ввод записей DNS A
    А @ 199. 36.158.100
    А www 199.36.158.100
    Облачный DNS Google
    Значение проверки
    Тип Хост Значение
    Ввод записей DNS TXT
    ТХТ пример .com указано в консоли Firebase
    Ввод записей DNS A
    А пример .com 199.36.158.100
    А www 199. 36.158.100
    НазваниеДешево
    Значение проверки.
    Тип Хост Значение
    Ввод записей DNS TXT
    ТХТ @ указано в консоли Firebase
    Ввод записей DNS A
    А @ 199.36.158.100
    А @ 199.36.158.100
    Площадь
    Значение проверки.
    Тип Хост Значение
    Ввод записей DNS TXT
    ТХТ @ указано в консоли Firebase
    Ввод записей DNS A
    А @ 199.36.158.100
    А www 199.36.158.100
    Статус Описание
    Требуется установка

    Возможно, вам потребуется изменить конфигурацию записей DNS.

    • В большинстве случаев ваши записи DNS A не распространялись от вашего поставщика доменных имен на серверы хостинга Firebase.
      Совет по устранению неполадок. Если прошло более 24 часов, проверьте, вы указали свои записи на хостинге Firebase.

    • В более редких случаях, особенно при использовании расширенной настройки потока, вызовы SSL могут не выполняться, потому что:

      • В ваших записях DNS есть записи A или CNAME, которые указать на других хостинг-провайдеров.
        Совет по устранению неполадок. Убедитесь, что ваши записи A указывают только на Firebase Hosting и удалите все записи CNAME.
      • Не удалось выполнить миграцию, и токен (записи DNS TXT или загруженные файл, предоставленный вашему сайту) теперь недействителен.
        Совет по устранению неполадок: нажмите Просмотреть для домена, затем предоставьте новый токен вашему существующему домену.
    В ожидании

    Вы правильно настроили личный домен, но Firebase Hosting не предоставил SSL-сертификат.

    Иногда следующие проблемы могут затормозить создание SSL сертификат для личного домена:

    • Ваши записи CAA слишком строгие.
      Совет по устранению неполадок. Убедитесь, что центры сертификации `letsencrypt.org` и `pki.goog` разрешено создавать SSL-сертификаты для ваш домен.
    • Ваш код вызова недействителен.
      Если вы используете расширенный Поток установки и миграция не удались, ваш токен (и его вызов код) теперь недействительны.
      Совет по устранению неполадок: нажмите Просмотреть для домена, затем предоставьте новый токен вашему существующему домену.
    • Вы запросили сертификаты для слишком большого количества субдоменов.
      Совет по устранению неполадок: как правило, Firebase Hosting не рекомендует более 20 поддоменов в одном личном домене apex благодаря SSL ограничения на чеканку сертификатов.
    Подключен

    Ваш личный домен имеет правильные записи DNS и имеет SSL сертификат.
    Вы можете обслуживать содержимое своего сайта.

    Требуется повторная проверка

    Firebase может потребовать повторной проверки вашего домена вручную права собственности, если запись TXT добавлена ​​при первоначальном подтвердил право собственности на домен был изменен или удален из настроек DNS вашего домена.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *