ServBay

Русский

English
简体中文
繁體中文
Español
العربية
Português
日本語
Deutsch
Français
Tiếng Việt
Türkçe
Italiano
हिन्दी
Bahasa Indonesia
Bahasa Melayu
Polski
Nederlands
Українська
ไทย
한국어

Русский

English
简体中文
繁體中文
Español
العربية
Português
日本語
Deutsch
Français
Tiếng Việt
Türkçe
Italiano
हिन्दी
Bahasa Indonesia
Bahasa Melayu
Polski
Nederlands
Українська
ไทย
한국어

Appearance

Руководство по устранению неполадок веб-серверов ServBay ​

ServBay поддерживает использование Caddy, NGINX и Apache в качестве основного веб-сервера, предоставляя гибкие возможности для локальной разработки. В процессе использования могут возникнуть ситуации, когда сайт недоступен, работает медленно или возвращает ошибки (например, 500 Internal Server Error). Это руководство поможет диагностировать и решить самые распространённые проблемы, связанные с веб-серверами в среде ServBay.

Использование встроенного инструмента диагностики неполадок ServBay ​

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

Откройте приложение ServBay и в левом навигационном меню выберите Диагностика ошибок, чтобы перейти к встроенному интерфейсу диагностики.

Диагностика с помощью инструмента ServBay

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

Медленный первый доступ к сайту после перехода с MAMP или Laravel Herd ​

Если вы мигрировали с MAMP или Laravel Herd на ServBay и заметили, что первый визит на сайте после простоя занимает более 5 секунд, а последующие обращения осуществляются быстро, возможно, проблема повторяется при повторном простое.

Симптомы ​

В браузере Chrome откройте инструменты разработчика (клавиши F12 или Cmd+Option+I), перейдите на вкладку Сеть (Network), обновите страницу и просмотрите Timing — в поле DNS Lookup будет показано около 5 секунд ожидания.

Долгое DNS Lookup в инструментах разработчика Chrome(Иллюстрация: просмотр времени DNS Lookup во вкладке Network инструментов Chrome)

Причина ​

При установке MAMP или Laravel Herd они изменяют настройки DNS macOS, добавляя специальные файлы конфигураторов разрешения DNS для перехвата доменов (*.test, *.local и др.), обычно расположенные в директории /etc/resolver/.

Даже после удаления MAMP или Herd эти конфигурационные файлы часто остаются. При попытке обратиться к сайту с аналогичным суффиксом (например, .test), macOS сперва пытается выполнить DNS запрос через старый конфигуратор, но так как служба DNS для MAMP/Herd больше не работает, запрос истекает по таймауту (5 секунд), а затем система переходит на стандартный DNS.

Решение ​

Следуйте этим шагам для полноценного удаления остаточных настроек DNS от MAMP или Laravel Herd:

1. Корректная деинсталляция MAMP или Laravel Herd ​

Если вы ещё не полностью удалили MAMP или Laravel Herd, воспользуйтесь их официальным деинсталлятором или скриптом:

Удаление MAMP:

  • Используйте встроенную функцию деинсталляции приложения MAMP
  • Или вручную удалите папку /Applications/MAMP и связанные файлы

Удаление Laravel Herd:

bash
# Команда для удаления Herd
herd uninstall

# Если команда недоступна, удалите приложение и конфиги вручную
rm -rf ~/Library/Application\ Support/Herd
rm -rf ~/.config/herd

2. Удаление остаточных файлов в /etc/resolver ​

Даже после корректного удаления MAMP или Herd файлы конфигуратора в /etc/resolver/ могут остаться, их нужно удалить вручную:

bash
# Посмотреть содержимое каталога /etc/resolver
ls -la /etc/resolver

# Удалить конкретные конфиги (например, test и local)
sudo rm /etc/resolver/test
sudo rm /etc/resolver/local

# Если остались другие файлы, созданные MAMP/Herd, удалите их тоже
# Например: sudo rm /etc/resolver/herd

Частые файлы:

  • test — для доменов *.test
  • local — для доменов *.local
  • herd — для Herd

Внимание: Для удаления требуется административный доступ (sudo).

3. Не используйте суффикс *.local для доменов ​

В macOS домены с окончанием .local зарезервированы для локальной сети и службы mDNS (Bonjour). Использование .local в разработке может вызвать:

  • конфликты DNS
  • медленное открытие сайтов
  • нестабильное сетевое поведение

Рекомендуемые альтернативы:

  • .test — специальная зона для тестирования
  • .localhost — всегда указывает на localhost
  • .dev — настоящий TLD, часто используется для локальной разработки
  • или пользовательский суффикс, предложенный ServBay

4. Очистка кэша DNS (по желанию) ​

После удаления старых файлов желательно очистить кэш DNS для немедленного появления изменений:

bash
# macOS Big Sur (11) и новее
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Catalina (10.15) и старее
sudo killall -HUP mDNSResponder

5. Проверка результата ​

После очистки попробуйте вновь открыть сайт ServBay:

  1. Откройте сайт в браузере
  2. Перейдите во вкладку Сеть (Network) в инструментах разработчика Chrome
  3. Обновите страницу и проверьте Timing
  4. Убедитесь, что время DNS Lookup сократилось до нормы (обычно менее 50мс)

Выполнив данные действия, вы устраните медленный первый доступ к сайту после перехода с MAMP или Herd. Если проблема осталась, проверьте, нет ли сторонних VPN или прокси, влияющих на работу DNS.

Проверка конфигурационных файлов веб-сервера ​

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

Проверка Caddyfile ​

Для проверки Caddyfile используйте команду validate:

bash
# macOS
/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile

# Windows
C:\ServBay\bin\caddy.exe validate -c C:\ServBay\etc\caddy\Caddyfile

При правильном синтаксисе появится сообщение Valid configuration. При ошибке вы получите подробную подсказку.

Примечание: Команда может выводить много сообщений INFO или WARN — это обычная информация о процессе загрузки и не считается ошибкой. Главное — наличие Valid configuration в конце.

Частые ошибки Caddyfile: ​

  • Ошибка отсутствия сертификата:

    bash
    # macOS
2024/12/09 17:24:16.970 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
... (INFO/WARN сообщения) ...
Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /Applications/ServBay/ssl/private/tls-certs/mail.servbay.host/mail.servbay.host.1crt: no such file or directory

# Windows
2024/12/09 17:24:16.970 INFO using config from file {"file": "C:\\ServBay\\etc\\caddy\\Caddyfile"}
... (INFO/WARN сообщения) ...
Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open C:\\ServBay\\ssl\\private\\tls-certs\\mail.servbay.host\\mail.servbay.host.1crt: no such file or directory

    Ошибка loading certificates: open xxxxx: no such file or directory означает, что путь к SSL-сертификату в Caddyfile неверный или файл не существует. Проверьте прописанные адреса сертификатов (.crt, .cer, .pem) и ключей (.key). Сертификаты можно импортировать вручную или использовать ACME для автоматического выпуска, настройте SSL в ServBay.

  • Ошибка пути к корню сайта (с пробелами):

    bash
    # macOS
2024/12/09 17:26:37.371 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at /Applications/ServBay/etc/caddy/Caddyfile:1388

# Windows
2024/12/09 17:26:37.371 INFO using config from file {"file": "C:\\ServBay\\etc\\caddy\\Caddyfile"}
Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at C:\\ServBay\\etc\\caddy\\Caddyfile:1388

    Ошибка parsing caddyfile tokens for 'root': too many arguments часто вызвана наличием пробелов в пути, например:

    • macOS: root * /Applications/ServBay/www/public web — Caddy считает public и web разными параметрами
    • Windows: root * C:\ServBay\www\public web — то же самое

    Верное решение: заключать пути с пробелами в двойные кавычки ":

    • macOS: root * "/Applications/ServBay/www/public web"
    • Windows: root * "C:\ServBay\www\public web"

    Рекомендация: Избегайте пробелов и специальных символов в имени файлов и папок; используйте дефисы - и подчеркивания _: например, public-folder или public_dir.

  • Ошибка переписывания (Rewrite):

    Некорректные правила rewrite, скопированные из NGINX, приведут к ошибке проверки. Обратитесь к документации Rewrite Caddy или используйте гайд по миграции с NGINX на ServBay, чтобы избежать проблем с синтаксисом.

Проверка конфигурации NGINX ​

Проверьте синтаксис файла nginx.conf командой -t:

bash
# macOS
/Applications/ServBay/bin/nginx -t

# Windows
C:\ServBay\bin\nginx.exe -t

Если всё верно:

# macOS
nginx: the configuration file /Applications/ServBay/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /Applications/ServBay/etc/nginx/nginx.conf test is successful

# Windows
nginx: the configuration file C:\ServBay\etc\nginx\nginx.conf syntax is ok
nginx: configuration file C:\ServBay\etc\nginx\nginx.conf test is successful

Ошибка укажет на файл и строку, где проблема. Распространённые ошибки:

  1. Синтаксис: отсутсвует точка с запятой ;, несоответствие скобок }.
  2. Пути к файлам: неверный или несуществующий файл/папка в директиве include и других.
  3. Конфликт портов: порт занят другим приложением.

Проверка конфигурации Apache ​

Apache проверяет конфигурацию через команду apachectl configtest:

bash
# macOS
/Applications/ServBay/bin/apachectl configtest

# Windows
C:\ServBay\bin\httpd.exe -t

При успешной проверке — Syntax OK. В случае ошибки — подробная причина. Основные ошибки:

  1. Ошибка загрузки модуля: отсутствует или неправильно указан модуль (LoadModule).
  2. Ошибки .htaccess: при наличии ошибок в .htaccess, сама проверка и доступ к папке невозможны.
  3. Права доступа к папке: директивы Directory, Files с настройками Require, Allow, Deny могут блокировать сайт.

Обработка ошибок 500 Internal Server Error ​

Ошибка 500 означает, что сервер столкнулся с неожиданной проблемой при выполнении запроса. Веб-приложения, как правило, возвращают её при сбое работы бэкенда (PHP, Python, Node.js и др.).

Общие шаги: ​

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

    macOS:

    • Caddy: /Applications/ServBay/var/logs/caddy/error.log
    • NGINX: /Applications/ServBay/var/logs/nginx/error.log
    • Apache: /Applications/ServBay/var/logs/apache/error.log

    Windows:

    • Caddy: C:\ServBay\var\logs\caddy\error.log
    • NGINX: C:\ServBay\var\logs\nginx\error.log
    • Apache: C:\ServBay\var\logs\apache\error.log

    Просматривайте последние строки, ищите слова error или critical.

  2. Проверьте работу сервисов бэкенда (например, PHP-FPM): Если сайт на PHP, убедитесь, что PHP-FPM запущен.

    bash
    ps aux | grep php-fpm

    Найдите процесс php-fpm: master process или php-fpm: pool www. Если их нет, PHP-FPM не работает или завершился — запустите сервис через интерфейс ServBay или командой servbayctl.

  3. Проверьте журнал ошибок PHP: Если в логах сервера ошибка FastCGI или бэкенда, ищите причину в журнале PHP.

    Журнал PHP:

    • macOS: /Applications/ServBay/var/logs/php/php_error.log
    • Windows: C:\ServBay\var\logs\php\php_error.log

    Ищите сообщения Fatal error, Parse error, Warning, Notice — особенно связанные с текущим скриптом. Для отображения ошибок в разработке временно включите display_errors в php.ini.

  4. Проверьте права на файлы/папки: Обычно процессы веб-сервера (например, _www) должны иметь права на чтение файлов сайта и запись в нужные папки.

    macOS:

    bash
    ls -la /Applications/ServBay/www/your-site/

    Убедитесь, что пользователю сервера есть права на папку сайта и её содержимое. Для загрузки файлов или логирования нужны права записи (chmod, chown).

    Windows:

    cmd
    dir C:\ServBay\www\your-site

    В Windows доступ должен быть у пользователя, запустившего ServBay. Настройте через свойства папки – вкладка "Безопасность".

Особенности устранения ошибки 500 для разных серверов ​

  • Caddy:

    1. Настройки FastCGI: В Caddyfile директивы php_fastcgi или reverse_proxy должны указывать на адрес PHP-FPM (обычно 127.0.0.1:9000 или, для сокетов, unix:/path/to/php-fpm.sock).
    2. Работа PHP-FPM: Убедитесь, что необходимая версия PHP и сервис PHP-FPM запущены в ServBay.
    3. Настройки reverse_proxy: При проксировании на Node.js или другие сервисы проверьте правильность адреса, порта, а также работу бекенда.

  • NGINX:

    1. Директива fastcgi_pass: В nginx.conf или настройках сайта укажите правильный адрес PHP-FPM.
    2. Директива client_max_body_size: Если ошибка появляется при загрузке больших файлов — возможно, значение директивы слишком мало.
    3. Директива try_files: Проверьте правильность настройки, чтобы запросы к несуществующим файлам попадали на FastCGI.

  • Apache:

    1. Модуль mod_rewrite: Для работы перезаписи URL через .htaccess модуль должен быть активен.
    2. Содержимое .htaccess: Ошибки в директивах приводят к 500 ошибке. Проверьте синтаксис, в частности правила RewriteRule.
    3. Настройка AllowOverride: Убедитесь, что директива разрешает обработку команд из .htaccess (обычно All или список, включающий FileInfo и Limit).

Управление сервисами ​

В большинстве случаев после изменения настроек или решения проблем требуется перезапустить соответствующий сервис.

Перезапуск сервиса ​

Для перезапуска сервиса используйте команду servbayctl restart:

bash
# Перезапуск Caddy
servbayctl restart caddy -all

# Перезапуск NGINX
servbayctl restart nginx -all

# Перезапуск Apache
servbayctl restart apache -all

Параметр -all перезапустит все зависимые сервисы, например FastCGI/PHP-FPM вместе с веб-сервером.

Проверка статуса сервиса ​

Для просмотра состояния используйте команду servbayctl status:

bash
# Проверить статус Caddy
servbayctl status caddy -all

# Проверить статус NGINX
servbayctl status nginx -all

# Проверить статус Apache
servbayctl status apache -all

В ответе будет running (работает), stopped (остановлен) или иное состояние — так вы убедитесь, что сервис успешно запущен.

Продвинутые способы устранения неполадок ​

Если перечисленные методы не помогли, попробуйте:

  1. Инструменты разработчика браузера: Откройте DevTools (F12), вкладки Console и Network. Ищите ошибки JS, статусы HTTP, заголовки и тело ответов — это поможет определить, проблема на фронте или сервере.
  2. Команда curl -v: В терминале выполните curl -v your-website.servbay.demo (замените на ваш домен). Префикс -v покажет подробные этапы запроса, включая заголовки, подключение SSL/TLS.
  3. Временно отключить фаервол: Защитное ПО или системный фаервол могут блокировать соединения. Отключите на время тестирования и, если проблема решена, настройте правила для портов ServBay (80, 443 и др.).
  4. Тестирование на других браузерах/устройствах: Проверьте сайт на разных браузерах и устройствах для исключения проблем с кэшем или специфическими настройками.
  5. Проверьте настройку DNS или hosts: Для пользовательских доменов (не localhost/IP) проверьте файл hosts:
    • macOS: /etc/hosts
    • Windows: C:\Windows\System32\drivers\etc\hosts Домен должен резолвиться в 127.0.0.1 или ::1.

Итоги ​

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