FastPanel изнутри: как на самом деле работает хостинг на nginx и Apache

Первое, что видит человек после установки FastPanel — красивая админка, кнопка «добавить сайт», и вроде всё работает. Но стоит копнуть глубже, и начинается самое интересное. Решил рассказать, как это хозяйство устроено изнутри.

Миф: FastPanel — это nginx

Формально да. На портах 80 и 443 висит nginx, он отдаёт статику и проксирует динамику. Но если вы думаете, что ваш PHP обрабатывается через nginx + php-fpm — вы ошибаетесь.

FastPanel использует связку: nginx → Apache → PHP (mod_php).

То есть: nginx принимает запрос, смотрит — если статика (картинка, CSS, JS), отдаёт сам. Если PHP — проксирует на Apache, который висит на локальном порту. Apache уже грузит mod_php и выполняет скрипт.

Звучит как костыль? Возможно. Но работает. И вот почему.

mpm_itk и AssignUserId

Apache стоит не с обычным worker или prefork, а с mpm_itk. Это такой модуль, который позволяет каждому виртуальному хосту Apache работать от своего системного пользователя.

То есть у меня на сервере: каждый сайт выполняется от своего отдельного пользователя. mpm_itk перед обработкой запроса делает setuid() и setgid() на нужного пользователя. Это значит, что даже если на соседнем сайте дыра, до моих файлов он не доберётся — прав не хватит.

Конфиг выглядит так:

<VirtualHost 127.0.0.1:81>
    AssignUserId siteuser siteuser
    DocumentRoot /var/www/site/data/www/example.com
</VirtualHost>

Всё гениально и просто.

Грабли с upload_tmp_dir

Самая популярная проблема, с которой приходят ко мне в комментарии: «Не загружается изображение в WordPress, пишет ошибку». И начинается танец с бубном — права, chmod, chown.

А дело вот в чём. PHP по умолчанию складывает временные файлы при загрузке в системный /tmp. Но /tmp на серверах часто доступен только для чтения всем. Или туда пишет www-data, а у нас пользователь сайта.

Решение прописано в конфиге Apache для сайта:

php_admin_value upload_tmp_dir /var/www/site/data/tmp
php_admin_value upload_max_filesize 100M
php_admin_value post_max_size 100M

Важный момент: upload_tmp_dir должен принадлежать тому же пользователю, от которого работает Apache. Если забыть — WordPress скажет «не удалось переместить загруженный файл», хотя проблема не в wp-content/uploads, а во временной папке.

Я на эту граблю наступал раза три, пока не запомнил.

nginx: статика и прокси

nginx в этой схеме выступает умным балансировщиком. Его конфиги лежат отдельно для каждого сайта. Он:

• Отдаёт статические файлы напрямую (images, css, js) — это быстро
• Проксирует PHP на локальный Apache
• Добавляет headers для кэширования статики
• Работает с SSL (Let’s Encrypt через панель)

Если в логах nginx ошибка 502 — значит Apache упал. Если 504 — PHP завис.

FastPanel свой PHP

Отдельная песня — /opt/fphp/bin/php. Это сборка PHP от разработчиков FastPanel, которая лежит отдельно от системного. Используется для внутренних скриптов панели.

Почему это всё не меняют?

Связка nginx → Apache выглядит архаично. Все современные панели типа CyberPanel, Hestia, aaPanel используют nginx + php-fpm напрямую. Но FastPanel — консерваторы.

У этого подхода есть плюс: mod_php работает предсказуемо. Он не падает с ошибками пула php-fpm, не теряет соединения с БД, не требует танцев с pm.max_children. Просто берёт и работает годами.

Минус — он жрёт память. Apache с mod_php под каждый запрос резервирует память процесса. На слабых серверах (1-2GB RAM) это чувствуется.

Что починить, если сайт лежит

Быстрая диагностика для FastPanel:

1. systemctl status nginx — жив ли nginx
2. systemctl status apache2 — жив ли Apache
3. journalctl -u apache2 —no-pager -n 20 — что в логах
4. Проверить конфиг сайта в папке Apache — не сломан ли
5. ls -la /var/www/site/data/tmp/ — чисто ли во временной папке

В 90% случаев проблема либо в правах (забыли chown), либо Apache упал и не поднялся (часто из-за ошибки в .htaccess).

Итог

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

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

Миф: FastPanel — это nginx. Формально да. На портах 80 и 443 висит nginx, он отдаёт статику и проксирует динамику. Но если вы думаете, что ваш PHP обрабатывается через nginx + php-fpm — вы ошибаетесь. FastPanel использует связку: nginx → Apache → PHP (mod_php). То есть: nginx принимает запрос, смотрит — если статика (картинка, CSS, JS), отдаёт сам. Если PHP — проксирует на Apache, который висит на локальном порту. Apache уже грузит mod_php и выполняет скрипт. Звучит как костыль? Возможно. Но работает. И вот почему. Такая схема — классика «двухступенчатого» хостинга, и у неё есть свои неожиданные преимущества.

mpm_itk и AssignUserId. Apache стоит не с обычным worker или prefork, а с mpm_itk. Это такой модуль, который позволяет каждому виртуальному хосту Apache работать от своего системного пользователя. То есть у меня на сервере каждый сайт выполняется от своего отдельного пользователя. mpm_itk перед обработкой запроса делает setuid() и setgid() на нужного пользователя. Это значит, что даже если на соседнем сайте дыра, до моих файлов он не доберётся — прав не хватит. Конфиг выглядит так: <VirtualHost 127.0.0.1:81> AssignUserId siteuser siteuser, DocumentRoot /var/www/site/data/www/example.com </VirtualHost>. Всё гениально и просто. Изоляция между сайтами на shared-хостинге — это именно то, что делает mpm_itk бесценным.

Почему изоляция важна. На обычном VPS без такой схемы все сайты выполняются от одного пользователя — и один скомпрометированный сайт открывает злоумышленнику доступ ко всем остальным. FastPanel закрывает эту проблему на уровне веб-сервера: каждый сайт — отдельный системный пользователь, отдельные права, отдельная песочница. Даже если взломали сайт A, до файлов сайта B не добраться. Для мультисайтинга — это огромный плюс. Помню, как на другой панели один заражённый WordPress заразил все сайты на сервере, и мне пришлось чистить всё. С FastPanel такая ситуация невозможна.

Грабли с upload_tmp_dir. Самая популярная проблема, с которой приходят ко мне в комментарии: «Не загружается изображение в WordPress, пишет ошибку». И начинается танец с бубном — права, chmod, chown. А дело вот в чём. PHP по умолчанию складывает временные файлы при загрузке в системный /tmp. Но /tmp на серверах часто доступен только для чтения всем. Или туда пишет www-data, а у нас пользователь сайта. Решение прописано в конфиге Apache для сайта: php_admin_value upload_tmp_dir /var/www/site/data/tmp, php_admin_value upload_max_filesize 100M, php_admin_value post_max_size 100M. Важный момент: upload_tmp_dir должен принадлежать тому же пользователю, от которого работает Apache. Если забыть — WordPress скажет «не удалось переместить загруженный файл», хотя проблема не в wp-content/uploads, а во временной папке. Я на эту граблю наступал раза три, пока не запомнил.

Как диагностировать проблему с загрузкой. Первое — проверьте, что upload_tmp_dir существует и принадлежит нужному пользователю: ls -la /var/www/site/data/tmp. Владельцем должен быть тот же пользователь, что указан в AssignUserId. Второе — проверьте, что в папке хватает места: df -h. Третье — включите отображение ошибок PHP в лог и посмотрите точное сообщение. В девяти случаях из десяти проблема либо в правах на временную папку, либо в превышении upload_max_filesize. Это решается за минуту, если знать, куда смотреть. Знание архитектуры экономит часы гугления.

nginx: статика и прокси. nginx в этой схеме выступает умным балансировщиком. Его конфиги лежат отдельно для каждого сайта. Он: отдаёт статические файлы напрямую (images, css, js) — это быстро; проксирует PHP на локальный Apache; добавляет headers для кэширования статики; работает с SSL (Let’s Encrypt через панель). Разделение труда идеальное: nginx — быстрая раздача статики и терминация SSL, Apache — исполнение PHP. Каждый делает то, что умеет лучше всего. Если в логах nginx ошибка 502 — значит Apache упал. Если 504 — PHP завис. Это простейшая диагностика, которая сразу указывает направление поиска.

Что значат ошибки 502 и 504. Ошибка 502 Bad Gateway означает, что nginx не смог получить ответ от Apache — скорее всего, Apache упал или перестал отвечать. Причины: сломанный .htaccess, переполнение памяти, слишком много одновременных запросов. Ошибка 504 Gateway Timeout — это когда Apache отвечает слишком долго: PHP-скрипт завис или ждёт недоступную базу данных. Понимание этой разницы — первый шаг к быстрой диагностике. Когда я вижу 502, я сразу иду в journalctl -u apache2 и смотрю логи. Когда вижу 504 — проверяю, жива ли база данных и не висит ли медленный запрос.

FastPanel свой PHP. Отдельная песня — /opt/fphp/bin/php. Это сборка PHP от разработчиков FastPanel, которая лежит отдельно от системного. Используется для внутренних скриптов панели. Не пугайтесь, если увидите этот путь в процессах — это нормальная работа панели. Свой PHP позволяет панели не зависеть от версии системного интерпретатора и гарантировать стабильность внутренних скриптов. Если панель обновляет свою внутреннюю логику, она не трогает ваш сайтовый PHP. Разделение «панельного» и «пользовательского» PHP — продуманное решение, которое защищает ваши сайты от сюрпризов при обновлениях панели.

Почему это всё не меняют. Связка nginx → Apache выглядит архаично. Все современные панели типа CyberPanel, Hestia, aaPanel используют nginx + php-fpm напрямую. Но FastPanel — консерваторы. У этого подхода есть плюс: mod_php работает предсказуемо. Он не падает с ошибками пула php-fpm, не теряет соединения с БД, не требует танцев с pm.max_children. Просто берёт и работает годами. Минус — он жрёт память. Apache с mod_php под каждый запрос резервирует память процесса. На слабых серверах (1-2GB RAM) это чувствуется. Консерватизм FastPanel — это осознанный выбор стабильности в ущерб новизне.

Мой опыт с памятью. На сервере с 1 гигабайтом RAM связка nginx + Apache + mod_php может упираться в память при нескольких одновременных запросах. Что я сделал: поднял память до 2 GB — и проблема ушла. Либо можно ограничить количество Apache-процессов через mpm-настройки. Для маленьких сайтов достаточно 2-3 гигабайт RAM. Если сайты тяжёлые или нагрузка высокая — подумайте о связке nginx + php-fpm вручную или о более лёгкой панели. Но для 90% случаев — сайты, магазины, блоги — FastPanel-связки с 2 GB RAM достаточно с запасом. Выбор железа под архитектуру — это половина успеха.

Что починить, если сайт лежит. Быстрая диагностика для FastPanel: systemctl status nginx — жив ли nginx; systemctl status apache2 — жив ли Apache; journalctl -u apache2 —no-pager -n 20 — что в логах; проверьте конфиг сайта в папке Apache — не сломан ли; ls -la /var/www/site/data/tmp/ — чисто ли во временной папке. В 90% случаев проблема либо в правах (забыли chown), либо Apache упал и не поднялся (часто из-за ошибки в .htaccess). Эти пять команд — мой персональный чек-лист, который я прогоняю при любой жалобе «сайт лежит». Он позволяет найти причину за пару минут. Запишите его себе — пригодится.

Итог. FastPanel — не идеал, но он честный. Он не прячет от тебя сложность, а просто настраивает всё за тебя. Если знать, как он работает изнутри, любая проблема решается за 5 минут. Надеюсь, кому-то этот разбор сэкономит пару часов гугления. Моя общая рекомендация: FastPanel — отличный выбор для shared-хостинга и небольших серверов, где важна изоляция сайтов и предсказуемость работы. Архитектура nginx → Apache с mpm_itk — это надёжный, проверенный временем подход. Зная его слабые и сильные стороны, вы будете эксплуатировать панель с полным пониманием происходящего.