10 тонкостей работы на хостинге Timeweb

Введение

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

Далеко не каждый пункт данной статьи может стать откровением, а некоторые из моментов описаны даже на сайте хостинг-провайдера Timeweb. Я считаю это нормальным, поскольку нужно иметь значительный запас времени для изучения всех инструкций хостинг-провайдера, а многие подобным ресурсом не обладают. Моя статья раскрывает десятку самых интересных моментов, про которые наверняка не знает новичок, а часть из них может вызвать удивление и у старожилов. Поехали!
 

1. Почта домена сайта

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

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

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

2. Отсутствие нужной БД в phpMyAdmin

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

Есть вариант по решению данной ситуации без необходимости обращения в поддержку - достаточно воспользоваться кнопкой "Выход" в левом верхнем углу экрана в phpMyAdmin, а после вновь зайти туда средствами проблемы управления - нужная база будет отображаться!

3. Возобновления работы сайта после 502

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

По моему опыту могу сказать, что чаще всего проблема связана с тем, что обработчики веб-сервера заняты обработкой уже вызванных скриптов. Например, на PHP 5.3 их выделяется 6 штук, на других версиях по 3, насколько мне удалось выяснить при общении с поддержкой. Это ограничения в рамках моего тарифного плана мощного хостинга Premium на Timeweb, в вашем случае может быть иначе.

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

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

4. Настройки сервера

Получить информацию по настройкам сервера можно, не напрягая себя созданием специальных конфигурационных файлов. 
Это можно сделать при помощи ссылки вида:
http://имя_сервера.timeweb.ru/phpinfo.php.

Пример: http://premium36.timeweb.ru/phpinfo.php

Получить информацию по настройка MySQL можно в разделе "Базы данных MySQL" в интерфейсе "phpMyAdmin". Во вкладке "Сравнения" можно ознакомиться с настройками множества параметров.

5. Mod_cgi и .htaccess

Директивы в файле .htaccess не дают эффекта?
Проверьте, не работаете ли вы через mod_cgi!

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

В такой ситуации я рекомендую обратить внимание на другие директивы файла .htaccess, поскольку сайт может быть запущен через mod_cgi, а не через mod_php, как обычно. Для решения проблемы достаточно будет закомментировать директивы c помощью символа # (решётка), которые относятся к указанию работы сайта через mod_cgi, а после вы можете убедиться в корректном срабатывании размещенных ранее директив.

6. Сайт на поддомене

Зачастую может возникнуть ситуация, когда мы хотим, помимо основного сайта на домене example.ru, разместить и поддомен вида forum.example.ru, на котором разместим сайт с уникальным контентом. Это может быть сайт-одностраничник, форма авторизация или что-то более уникальное.

RewriteEngine on 

RewriteBase / 

RewriteCond %{HTTP_HOST} ^forum\.example\.ru$ 

RewriteCond %{REQUEST_URI} !/forum/ 

RewriteRule ^(.*)$ /forum/$1 [L]

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

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

7. Перенаправление на HTTPS (тип 301)

Периодически может возникать необходимость в реализации перенаправления конкретного типа: 301 (permanent redirect - перемещен постоянно), 302 (temporary redirect - перемещен временно). Порой выбор того или иного типа важен для клиентов с целью сохранения успешной индексации ресурса.

Панель управления в разделе "Сайты" позволяет сделать перенаправление с одного домена на другой.

Однако в данном случае будет реализовано перенаправление типа 302. Если возникает необходимость в перенаправлении со статусом 301, достаточно разместить в файле .htaccess в папке сайта директиву, которая позволяет сделать перенаправление с типом 301 с HTTP на HTTPS:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

8. Отдача статики с помощью Apache

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

В рамках Timeweb, как и на большинстве других известных мне хостингах, используется связка веб-серверов NGINX+APACHE, где за отдачу статического контента отвечает nginx, а за обработку динамики - веб-сервер Apache. Изображения с расширениями, например, JPG, PNG, GIF, являются статичным контентом и сразу отдаются веб-сервером NGINX. При этом инструкции файла .htaccess для них не применяются.

Действенным решением, пускай и не самым удобным в реализации, будет изменение расширения изображения, например, с .PNG на .PNGX. В этом случае запрос будет передан с сервера NGINX веб-серверу Apache, и необходимые инструкции возымеют силу.

9. Сокеты и 1C-Bitrix

Проблема с сокетами при проверке сайта с помощью раздела "Проверка системы"? Не беда.

Чаще всего решение достигается путем удаления АААА-записи в панели управления аккаунтом для домена, на котором расположен ваш сайт.

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

10. DMARC и отправка почты

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

Зачастую проблема может быть связана с тем, что в качестве отправителя указывается какой-либо сторонний домен, а не ящик на используемом вами домене, для которого уже были автоматически добавлены SPF запись и DKIM подпись. Для примера воспользуемся простейшим скриптом, который использует функцию mail():

<?php
if (mail("poluchatel@gmail.com", "Тема письма", "Текст письма",
"From: example@mail.ru \r\n")) {
echo "Сообщение принято к отправке";
} else {
echo "Текст ошибки";
}
?>

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

servername splogger[778]:  poluchatel@gmail.com R=dnslookup T=remote_smtp: SMTP error from remote mail server after end of data: host gmail-smtp-in.l.google.com [2a00:1450:4010:c09::1a]: 550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain's\n550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this\n550-5.7.1 was a legitimate mail. Please visit\n550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC\n550 5.7.1 initiative. r192si14666574lfr.2 - gsmtp

Для решения проблемы достаточно будет указать в качестве отправителя письма реально существующий почтовый ящик на вашем купленном домене, добавленном в панель на хостинге Timeweb. На хостинге для домена, на котором уже создан хотя бы один ящик, нужные записи DNS прописываются автоматически, и такой отправитель успешно пройдет проверку почтовым сервером-получателем письма. Создать почтовый ящик можно в разделе "Почтовый менеджер" в панели управления. 

Заключение

Надеюсь, представленные моменты не утомили вас и позволили почерпнуть что-то новое и интересное. Я буду стараться выкладывать занимательные заметки про хостинг и Web в дальнейшем, следите за моими сообщениями и статьями! Удачи! :)