Общий хостинг Beget: как он устроен

Эта страница описывает аккаунт общего (виртуального) хостинга Beget так, как его видит владелец. Имя аккаунта — user, домашняя папка — /home/u/user, а сайт из примера — example.com. Чем общий хостинг отличается от VPS: Какой хостинг выбрать. Инструменты, которые понадобятся: curl, SSH, Linux.

Beget: опыт одного автора

Я пользуюсь хостингом Beget с 2011 года, поэтому начну с него.

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

Выбрал я его почти случайно - по совету товарища, который прикинул, что в Петербурге у этого хостера «пинг будет поменьше».

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

Какой веб хостинг выбрать изображение с сайта www.devhops.site
Skype
www.devhops.site

Я думаю, что Beget добился таких результатов благодаря следующим факторам:

  1. Оперативной работе техподдержки.

    Без помощи от сотрудников техподдержки я бы не смог установить на хостинг Django и Flask
  2. Гибкой тарифной сетке
  3. Продуманной партнёрской программе
  4. Удобному и интуитивно понятному дизайну панели управления
  5. Возможности регистрировать доменные имена сразу через BEGET так как они стали официальным регистратором доменных имён.

Список всех официльных регистраторов доменных имён в зоне .ru вы можете изучить здесь

Из-за того, что Beget стал регистратором доменных имён у них даже был небольшой конфликт с другим крупным регистратором REG.RU но, к счастью, на большинстве пользователей он не отразился. У меня у самого до сих пор есть домены, зарегистрированные на REG.RU и сайты к которым привязаны эти домены на хостинге BEGET

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

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

Также можно докупить место на хостинге, заказать установку CMS, например, WordPress или Joomla и многое другое.

nginx перед Apache

Запрос не попадает в Apache напрямую. nginx принимает его первым и решает, что с ним делать. Фронтенд отвечает как nginx-reuseport.

Один вид запросов nginx обслуживает сам: статический файл, который есть на диске. .jpg, .png, .webp, .gif, .svg, .css, .js, .txt, .ico, .woff2 или .pdf в корне документов никогда не доходит до Apache. Всё остальное, включая страницы PHP, передаётся дальше.

Это первый сюрприз после переезда. 301, написанный для картинки или файла CSS в .htaccess, не срабатывает, пока файл существует: nginx отвечает 200 раньше, чем Apache прочитает файл. Образ, похожий на Beget, в плане проверок Docker показывает те же 200; это образ, а не хостинг. Полная таблица того, что где работает: Какие правила где безопасны.

У этого есть вторая сторона. Для существующего статического файла правило перезаписи здесь никогда не срабатывает. Поэтому шаблон, написанный для страниц и задевающий заодно картинки или скрипты, на Beget ничему не мешает, и его никто не замечает. Он проявляется только после переезда на хостинг, где каждый файл отдаёт Apache. Так случилось с правилом для PATH_INFO после переезда на DreamHost: DreamHost: статические файлы проходят через .htaccess.

Что это значит для .htaccess

Apache 2.4 стоит за nginx с AllowOverride All, поэтому .htaccess читается для каждого запроса, который до него доходит. PHP работает как модуль Apache, а не отдельным процессом. Зонд из проверки сервера показывает два важных значения:

vi ~/example.com/probe-7f3a.php

<?php echo "HTTPS=", var_export($_SERVER['HTTPS'] ?? null, true), " XFP=", var_export($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? null, true), " SERVER_SOFTWARE=", $_SERVER['SERVER_SOFTWARE'] ?? '', " sapi=", PHP_SAPI, "\n";

На аккаунте Beget в ответе будет sapi=apache2handler: PHP находится внутри Apache, поэтому php_flag и php_value в .htaccess работают. Второе значение — заголовок прокси: XFP='https' на запросе по https, потому что nginx заканчивает TLS и сообщает Apache, какой протокол использовал посетитель. Удалите зонд после проверки:

rm ~/example.com/probe-7f3a.php

Раз mod_php на месте, блок вида <IfModule mod_php.c> здесь выполняется, а на хостинге без него пропускается. Это безопасный способ сохранить настройки, когда тот же файл уезжает к другому провайдеру: Безопасные правила, защитные блоки и откат.

Где заканчивается HTTPS

TLS заканчивается в nginx. Apache видит обычный HTTP-запрос и заголовок X-Forwarded-Proto: https. Собственная переменная Apache %{HTTPS} остаётся off, поэтому редирект на https, который проверяет только %{HTTPS}, здесь зацикливается. Работающее правило проверяет заголовок:

RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

То же правило на хостинге, где TLS заканчивается в Apache, например на DreamHost, перенаправляет каждый https-запрос на самого себя. Правило, которое работает на обоих хостингах, проверяет оба условия: Редиректы за HTTPS-прокси. Сторона DreamHost: Только Apache, TLS в Apache.

Файлы, FTP и SSH

У аккаунта есть FTP и SFTP для передачи файлов и SSH для команд. Провайдер перечисляет все три среди возможностей каждого тарифа (виртуальный хостинг Beget). Доступ по SSH включается в панели управления. Входите с именем аккаунта и паролем из панели; хост — это домен сайта:

ssh user@example.com

Домашняя папка — /home/u/user: первая буква логина, затем сам логин. Сайт из этого примера — ~/example.com/; у сайта на PHP корень документов — ~/example.com/public_html/. Руководства по Python кладут приложение прямо в папку сайта: ~/example.com/ содержит .htaccess, passenger_wsgi.py, код приложения (app.py здесь) и tmp/. Если там есть готовый public_html, сохраните его в другом месте и удалите. Загрузки по FTP получают права по умолчанию сервера, и они не всегда те, что нужны Apache; проверьте их, прежде чем винить код: права и загрузка.

DNS на серверах имён Beget

DNS-серверы, которые нужно указывать при регистрации или переносе доменов, чтобы домен смотрел на сайт в Beget. Домен, который использует DNS Beget, делегирован четырём серверам:

ns1.beget.com ns2.beget.com ns1.beget.pro ns2.beget.pro

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

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

dig +short NS beget.com

ns2.beget.com. ns2.beget.pro. ns1.beget.com. ns1.beget.pro.

2 ноября 2026 года два сервера .pro, ns1.beget.pro и ns2.beget.pro, не отвечали. Домены, делегированные им, не разрешались, а публичные резолверы отвечали "No Reachable Authority", хотя сами сайты оставались доступны.

Когда домен перестаёт разрешаться, спросите резолвер, какие серверы он пробовал и отвечают ли они. Это ответ домена на DNS Beget:

dig +short NS example.com @8.8.8.8

ns1.beget.com. ns1.beget.pro. ns2.beget.com. ns2.beget.pro.

dig +short A example.com @ns1.beget.pro

203.0.113.20

Таймаут на второй команде указывает на сервер имён, а не на сайт. Сами записи и то, как резолвер проходит делегирование: DNS. Как перевести домен на другую пару серверов: Смена DNS.

Python на базовом тарифе

Базовый общий тариф не ограничен PHP: Python указан среди поддерживаемых языков (виртуальный хостинг Beget), а приложения Flask и Django работают там через Passenger. Пошаговые руководства — Настроить Flask на виртуальном хостинге и Установка Django на виртуальный хостинг. База знаний провайдера: статья базы знаний Beget о сайтах на Python. Проверенная настройка Flask из первого руководства собирает Python в ~/.local и запускает приложение из папки сайта.

Войдите в окружение Docker Beget по SSH; приглашение начинается с (docker). Соберите Python 3.11 в ~/.local сначала, если его там нет, как показывает руководство по Flask, затем установите Flask:

ssh localhost -p222

python3 -m pip install --upgrade pip

python3 -m pip install flask

which python3

Команда должна вывести путь внутри ~/.local/bin/.

Приложение, app.py в ~/example.com/:

from flask import Flask app = Flask(__name__) @app.route("/") def index(): return "Hello from Flask on shared hosting\n"

Файл, который ищет Passenger, passenger_wsgi.py, лежит рядом. Он добавляет папку с app.py в путь импорта и выставляет объект Flask как application:

import sys sys.path.insert(0, "/home/u/user/example.com") from app import app as application

В .htaccess в корне сайта ровно две строки: он включает Passenger и называет интерпретатор, собранный в ~/.local:

PassengerEnabled On PassengerPython /home/u/user/.local/bin/python3

Passenger запускает приложение при первом запросе. После изменения кода он держит старую версию, пока не тронут файл перезапуска:

touch ~/example.com/tmp/restart.txt

Локальная проверка тех же двух файлов, с путём импорта, направленным на папку проекта, и тестовым клиентом Flask, который просит главную страницу, отвечает:

200 Hello from Flask on shared hosting

Этот вывод получен тем же кодом приложения в локальном виртуальном окружении; на хостинге запрос идёт через Passenger. Проект Django использует ту же идею с get_wsgi_application() в passenger_wsgi.py.

Когда нужен VPS

У общего хостинга есть потолок. VPS — правильный тариф, когда нужно одно из этого:

Сайту на Flask или Django с обычным трафиком ничего из этого не нужно, он работает на базовом тарифе. Переезжайте, когда приложение запускает фоновый обработчик или требует системную библиотеку, которой общий тариф не даёт.

Проверка на сервере, похожем на Beget

В репозитории есть Docker-образ, который копирует веб-слой этой страницы: nginx спереди, Apache с mod_php за ним, заголовок X-Forwarded-Proto и корень документов, принадлежащий другому пользователю. Соберите и запустите его на своём сайте до загрузки: Образ, похожий на Beget.

Автор статьи: Arthur Isaev

Изображение баннера