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 Web-серверів ​

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 секунд.

Chrome показує надто довгий час DNS Lookup(Приклад: перегляд часу DNS Lookup на вкладці Network у Chrome)

Причина проблеми ​

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

Після видалення MAMP чи Herd ці файли можуть залишитись, і macOS буде намагатися виконати DNS-запит через ці старі резолвери, хоча DNS-сервіс більше не працює. DNS-запит «висить» ~5 секунд, лише потім система переходить до стандартного DNS.

Як вирішити проблему ​

Виконайте наступні кроки, щоб повністю прибрати залишкові DNS-налаштування MAMP/Herd:

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

Якщо ще не видалили MAMP чи Herd, скористайтеся офіційним деінсталятором або скриптом:

Видалення MAMP:

  • Через деінсталятор MAMP
  • Або вручну видаліть /Applications/MAMP та приберіть пов’язані конфіги

Видалення Laravel Herd:

bash
# Команда деінсталяції Herd
herd uninstall

# Якщо команда недоступна — видаліть Herd і його конфіги вручну
rm -rf ~/Library/Application\ Support/Herd
rm -rf ~/.config/herd

2. Видалення залишкових файлів у /etc/resolver ​

Навіть після повного видалення, у каталозі /etc/resolver/ можуть залишитись резолвер-файли. Їх треба видалити вручну:

bash
# Перегляд файлів у /etc/resolver
ls -la /etc/resolver

# Видалення конфігів для test та local
sudo rm /etc/resolver/test
sudo rm /etc/resolver/local

# За потреби видаліть й інші файли (наприклад: sudo rm /etc/resolver/herd)

Типові файли від MAMP/Herd:

  • test — для доменів *.test
  • local — для доменів *.local
  • herd — використовується Herd

Увага! Потребується права адміністратора (sudo) для видалення.

3. Не використовуйте *.local як домен ​

macOS резервує суфікс .local для місцевої мережі (LAN) через mDNS (Bonjour). Якщо використовувати .local для локальної розробки — виникає:

  • Конфлікт DNS
  • Повільний доступ
  • Непередбачувана мережна поведінка

Рекомендація: Обирайте інші суфікси, наприклад:

  • .test — зарезервовано для тестування
  • .localhost — завжди веде на локальний IP
  • .dev — реальний TLD, але часто використовується розробниками
  • Або власний суфікс, рекомендований ServBay

4. Очищення DNS-кешу (опціонально) ​

Після внесення змін бажано очистити DNS-кеш, щоб нові налаштування застосувались миттєво:

bash
# Для macOS Big Sur (11) та новіше
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Для Catalina (10.15) й раніше
sudo killall -HUP mDNSResponder

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

Після очищення:

  1. Зайдіть на сайт у локальному ServBay
  2. Відкрийте мережеву вкладку у Chrome Developer Tools
  3. Оновіть сторінку, перевірте показник DNS Lookup
  4. Переконайтесь, що час DNS Lookup <50ms

Якщо проблема не вирішилась — у системі можуть бути інші сторонні програми (VPN, проксі), які впливають на DNS.

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

Помилки у конфігурації — одна з найчастіших причин проблем із доступом. У ServBay є вбудовані інструменти для перевірки синтаксису файлів кожного серверу.

Перевірка Caddyfile ​

Використайте команду Caddy validate для перевірки Caddyfile на наявність синтаксичних помилок.

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 — це внутрішня інформація Caddy, яка не означає помилку. Головне — наявність 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). ServBay підтримує імпорт чи автоматичне створення SSL через ACME.

  • Помилка шляху до кореня сайту (із пробілом):

    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 — 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) призводить до помилки перевірки. Рекомендуємо ознайомитись із документацією Caddy Rewrite та гайдом по міграції з NGINX у ServBay.

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

NGINX має параметр -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. Завантаження модулів: підключений модуль відсутній чи невірний шлях.
  2. .htaccess помилки: помилки синтаксису у .htaccess можуть призвести до відмови всього сервера для каталогу чи цілого сайту.
  3. Неправильні права: параметри Directory, Files — обмежують доступ (Require, Allow, Deny).

Усунення 500 Internal Server Error ​

500 Internal Server Error — стандартний HTTP-код, який означає, що сервер не може виконати запит через внутрішню помилку (найчастіше у backend — PHP, Python, Node.js).

Загальні кроки діагностики ​

При появі 500:

  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. Перевірте чи запущений backend (PHP-FPM): Якщо сайт працює на PHP, переконайтесь, що PHP-FPM запущений.

    bash
    ps aux | grep php-fpm

    У виході має бути php-fpm: master process або php-fpm: pool www. Якщо немає — PHP-FPM не працює, запустіть сервіс через ServBay UI чи servbayctl.

  3. Перевірте логи скрипта (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 у dev-середовищі для видимості (див. php.ini).

  4. Перевірте права/доступ до файлів і каталогів: Сервер має працювати від певного користувача (наприклад, _www), йому потрібна можливість читати та писати в потрібні директорії.

    macOS:

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

    Переконайтесь, що у сервера є доступ (чтение, запис). За потреби — скористайтесь chmod, chown.

    Windows:

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

    Серверний процес має необхідні права, змінюйте їх у властивостях.

Особливості діагностики 500 для різних серверів ​

  • Caddy:

    1. FastCGI: Перевірте адресу в Caddyfile (php_fastcgi або reverse_proxy) — має співпадати з сокетом PHP-FPM (наприклад, 127.0.0.1:9000 чи шлях до sock-файлу).
    2. Стан PHP-FPM: Вибрана версія PHP, сервіс має бути активним.
    3. Налаштування reverse_proxy: Перевірте порт, адресу та стан сервісу у backend (наприклад, Node.js).

  • NGINX:

    1. fastcgi_pass: Чи правильно вказаний сокет PHP-FPM в nginx.conf.
    2. client_max_body_size: Занадто малий — обмежує завантаження, спричиняє 500.
    3. try_files: Має вказувати на правильний index чи backend FastCGI.

  • Apache:

    1. mod_rewrite: Впевніться, що модуль активний, якщо використовуєте .htaccess.
    2. Синтаксис .htaccess: Перевірка правил rewrite.
    3. AllowOverride: Дозволяє роботу .htaccess; провірте параметри (All, FileInfo, Limit).

Керування сервісами ​

Після змін у конфігах або backend, зазвичай потрібно перезапустити сервер чи сервіс.

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

Скористайтеся servbayctl restart, щоб оновити потрібний сервер.

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

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

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

Параметр -all перезапускає і пов’язані послуги (наприклад, PHP-FPM для FastCGI).

Перевірка статусу ​

Команда servbayctl status допоможе побачити, чи сервер запущений:

bash
# Статус Caddy
servbayctl status caddy -all

# Статус NGINX
servbayctl status nginx -all

# Статус Apache
servbayctl status apache -all

У виході буде: running (працює), stopped (зупинено) тощо.

Розширена діагностика ​

Якщо нічого з попереднього не допомагає — спробуйте наступне:

  1. Інструменти розробника браузера: (F12). Перейдіть на Console та Network. Перевірте JavaScript-помилки, статуси запитів, заголовки — для визначення точки проблеми (frontend чи backend).
  2. curl -v: Термінал, команда curl -v your-website.servbay.demo (ваш домен у ServBay). Виведе весь процес запиту — заголовки, SSL, помилки протоколу.
  3. Тимчасово вимкніть firewall: MacOS чи сторонній, щоб перевірити, чи не блокується порт (80, 443).
  4. Тест на різних пристроях/браузерах: Це дозволить виключити кеш браузера чи специфіку налаштувань пристрою.
  5. Перевірте локальний DNS/hosts: Для нестандартних доменів (не localhost чи IP) — переконайтесь, що вони правильно вказані у hosts:
    • macOS: /etc/hosts
    • Windows: C:\Windows\System32\drivers\etc\hosts

Підсумок ​

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