ServBay Webサーバー トラブルシューティングガイド
ServBayはCaddy・NGINX・Apacheを標準Webサーバーとして利用でき、柔軟なローカル開発環境を提供します。本環境利用時に、サイトが表示できない・読み込みが遅い・500エラーなどが発生する場合があります。このガイドでは、ServBay環境でよくあるWebサーバー関連の不具合の診断および解決方法をご紹介します。
ServBay内蔵トラブル診断ツールの活用
ServBayには便利なトラブル診断ツールが搭載されており、よくある設定ミスやサービス障害を自動で検知し、解決方法のヒントを表示します。問題発生時はまず本ツールをご利用ください。
ServBayアプリを開き、左サイドメニューの「トラブル診断」をクリックすると、専用の診断画面にアクセスできます。
このツールでは、ServBayのコアコンポーネント状態・ポート競合・設定ファイル構文エラーなどをチェックし、問題箇所特定と最適な対策方法を案内します。
MAMPやLaravel Herdから移行後、初回アクセスが遅い場合
MAMP や Laravel Herd からServBayに乗り換え後、サイトが長時間未アクセスのあと初回アクセス時のみ数秒以上（5秒以上）待たされる現象が発生することがあります。以降しばらくは高速ですが、再び放置すると初回だけ遅くなります。
症状
Chromeブラウザで開発者ツール（F12 または Cmd+Option+I）を開き、“ネットワーク (Network)”タブでページをリロードし、リクエスト詳細のTiming項目でDNS Lookupの時間が約5秒かかっているのを確認できます。
(図：ChromeのNetworkタブでDNS Lookup時間を確認)
原因
MAMP や Laravel Herd はインストール時、macOSのDNS設定を強制的に変更し、/etc/resolver/ ディレクトリに特殊なDNS設定ファイルを作成します。これにより、.test、.local など特定のドメインをローカルで強制解決します。
MAMP / Herdをアンインストールしてもこれらの設定ファイルが残っている場合、該当ドメインへのアクセス時、macOSはまず古い設定でDNS検索（5秒ほどタイムアウト待ち）、失敗後に標準DNSで再解決するため、初回だけ著しく遅延します。
解決方法
MAMPやLaravel Herdの残存DNS設定を完全に削除するには、以下の手順を実施してください：
1. MAMPやLaravel Herdを正しくアンインストール
未完全アンインストールの場合は、公式のアンインストーラーまたはアンインストールスクリプトでクリーンアップしてください。
MAMPアンインストール:
- MAMPアプリ内のアンインストール機能を使用
- または
/Applications/MAMPフォルダーを手動削除し、関連設定ファイルも消去
Laravel Herdアンインストール:
bash
# Herdが提供するアンインストールコマンド
herd uninstall
# 上記が使えない場合、Herdアプリおよび設定フォルダーを手動削除
rm -rf ~/Library/Application\ Support/Herd
rm -rf ~/.config/herd2. /etc/resolver ディレクトリ内の残存ファイル削除
MAMP/Herd削除後も /etc/resolver/ 内にDNSルックアップ設定ファイルが残っている場合があります。手動で確実に消去してください。
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- Laravel Herd専用
注意: これらの削除には管理者権限（sudo）が必要です。
3. *.local ドメイン利用の回避
macOSで *.local ドメインは**LAN用mDNS（Bonjour）**サービス専用です。開発で使用するとDNS競合・アクセス遅延・予期しない挙動につながります。
推奨: 下記のようなドメインサフィックス利用に切り替えてください。
.test- テスト用途に予約されたTLD.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 mDNSResponder5. 修正確認
サイト再アクセス時、下記手順で効果を検証します。
- ブラウザでローカルサイトを開く
- Chrome開発者ツール → “Network”タブを表示
- ページをリロードし、TimingからDNS Lookup時間を確認
- DNS Lookupが50ms未満に収まるかチェック
これでMAMP/Herdからの移行後の初回アクセス遅延問題は原則解消できます。なお、症状が残る場合はVPNやプロキシなど他のサードパーティソフトによるDNS干渉もご確認ください。
Webサーバー設定ファイルのチェック
設定ファイルのミスはサイト表示不可の大きな原因です。ServBayでは各Webサーバー用の構文チェック機能を備えています。
Caddyfileのチェック
Caddy内蔵の 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 結果が返ります。エラーがある場合は原因種別ごとに詳細が表示されます。
注意: caddy validate 実行結果に 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 directoryloading certificates: open xxxxx: no such file or directoryなどのメッセージが出る場合は、Caddyfileで指定したSSL証明書パスが誤っているか、ファイル自体が存在しません。指定した証明書（.crt/.cer/.pem）および秘密鍵（.key）ファイルのパス・存在可否を再チェックしてください。ServBayでは手動インポートまたは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:1388parsing caddyfile tokens for 'root': too many argumentsというエラーは、プロジェクトのパスにスペースが含まれている場合などによく起こります。例：- macOS:
root * /Applications/ServBay/www/public webのpublic web部分が2つの引数として解釈されてしまう - Windows:
root * C:\ServBay\www\public webのpublic web部分も同様
対策はパス全体をダブルクォート
" "で囲むことです。- macOS:
root * "/Applications/ServBay/www/public web" - Windows:
root * "C:\ServBay\www\public web"
推奨: フォルダー・ファイル名にはスペース・特殊記号を極力避け、ハイフン
-やアンダースコア_で分割する命名（例：public-folder,public_dir）をお薦めします。- macOS:
Rewriteルールの誤記:
Caddyfileに、Caddy構文に合致しないリライト記述（NGINXのルールをそのままコピペ等）をすると検証に失敗します。CaddyのRewriteモジュール公式ドキュメントやServBayのNGINXサイト移行ガイドも参照のうえ、正しい構文で記述してください。
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エラーがある場合、該当設定ファイル名・行番号つきで詳細が表示されます。よくあるNGINXミスは：
- 構文誤り（セミコロン
;抜け、カッコ}不整合など） - ファイルパスミス（
includeなどの指示で指定したファイルまたはフォルダー未存在） - ポート競合（設定したリッスンポートが他のプログラムで使用中）
Apache設定の確認
Apacheの apachectl configtest や httpd.exe -t で構文チェックができます。
bash
# macOS
/Applications/ServBay/bin/apachectl configtest
# Windows
C:\ServBay\bin\httpd.exe -tSyntax OKと表示されれば設定正常。エラーがあれば詳細メッセージが出ます。よくあるApacheミスは：
- モジュール読み込み失敗 (
LoadModuleで指定したモジュールやパスミス) - .htaccessの構文ミス （ディレクトリ配下の
.htaccess記述が誤っていると全体の動作に支障） - ディレクトリ権限の設定不備（
Directory,Filesなどでアクセス拒否・許可指示が不適切）
500内部サーバーエラーへの対処
500 Internal Server Errorはサーバー側でリクエスト処理中に予期せぬ問題が起こったことを示す汎用的ステータスコードです。多くはPHP・Python・Node.jsなどのバックエンドスクリプト異常です。
共通の調査手順
500エラー発生時は下記の流れで確認します。
Webサーバーのエラーログ確認: まずエラーログをチェックし、スクリプト実行失敗・ファイル不在・権限エラー等を特定します。
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を含む行を探します。- Caddy:
バックエンドサービス（PHP-FPM等）の稼働確認: PHP利用時は、PHP-FPMの起動状態をチェック。
bashps aux | grep php-fpmphp-fpm: master processやphp-fpm: pool www含む行があればOK。未出力なら未起動またはクラッシュ状態。ServBay UIやservbayctlで再起動できます。PHPなどバックエンドのエラーログチェック: FastCGIやスクリプト自体のエラーは専用エラーログを確認。
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は本番ではOFF推奨ですが、開発時はONで詳細表示が可能（php.iniで設定）。- macOS:
ファイル・ディレクトリ権限の確認: Webサーバープロセスがサイトファイルへ読取・書込できる権限が必要です。
macOS:
bashls -la /Applications/ServBay/www/your-site/Webサーバーユーザー（例：
_www）がディレクトリ・ファイルにアクセス権限を保持しているか、アップロードやログ出力先は書き込み可か確認しましょう。chmodやchownで調整できます。Windows:
cmddir C:\ServBay\www\your-siteWindowsではServBay実行ユーザーがフォルダー権限を持っているか、「プロパティ > セキュリティ」タブで確認・変更します。
各Webサーバー別の500エラー重点対策
Caddyの場合:
- FastCGI設定: Caddyfileの
php_fastcgiやreverse_proxyディレクティブが、PHP-FPMのアドレス（127.0.0.1:9000またはunix:/path/to/php-fpm.sock等）を正しく指定しているか。 - PHP-FPM動作確認: ServBayで選択したPHPバージョン・FPMサービスが稼働中か確認。
- リバースプロキシ設定: Node.js等他バックエンドへのプロキシ利用時、アドレス・ポートの正当性と対象サービス稼働状況をチェック。
- FastCGI設定: Caddyfileの
NGINXの場合:
fastcgi_pass設定:nginx.confや該当サイト設定のfastcgi_passでPHP-FPMのリスン先正しく指定しているか。client_max_body_size: 大容量アップロード時500エラーなら、設定値の上限超過が原因のことあり。try_filesディレクティブ: 正しいインデックスファイル選択・FastCGIへのリクエスト振り分けが動作しているか。
Apacheの場合:
mod_rewriteモジュール:.htaccessによるURLリライトを使う場合、mod_rewriteの有効化必須です。- .htaccess記述: 誤った
.htaccess文法は即座に500エラーになります。RewriteRule等確認を。 AllowOverride設定:.htaccess内容反映のために、該当ディレクトリのAllowOverride設定をAllもしくはFileInfo・Limitを含めて有効化する必要があります。
サービス管理
設定変更やバックエンド修正の反映にはWebサーバー/関連サービスの再起動が必要です。
サービス再起動
servbayctl restart コマンドで必要なWebサーバー種別ごとに再起動します。
bash
# Caddyサービス再起動
servbayctl restart caddy -all
# NGINXサービス再起動
servbayctl restart nginx -all
# Apacheサービス再起動
servbayctl restart apache -all-all オプション指定で、FastCGIなど関連サービスもまとめて再起動できます。
サービス状態確認
servbayctl status コマンドで各サービスの稼働状況を確認できます。
bash
# Caddyサービス状態
servbayctl status caddy -all
# NGINXサービス状態
servbayctl status nginx -all
# Apacheサービス状態
servbayctl status apache -allrunning（稼働中）、stopped（停止中）などのステータスが表示されます。起動・停止確認の指針になります。
高度なトラブルシューティング
上記手順で解消できない場合、さらに深く注意すべきポイント：
- ブラウザ開発ツールで詳細情報確認: F12で「コンソール」と「ネットワーク」タブ表示、JSエラー/レスポンス詳細/ステータスコード/ヘッダー等から前後どちらで障害が発生しているかを判断します。
curl -vコマンド利用: 端末からcurl -v your-website.servbay.demoでアクセス（-vで詳細プロトコル・ヘッダー・SSL/TLS情報など取得）。your-website.servbay.demoはご利用サイト名に置き換えてください。- 一時的なファイアウォール無効化テスト: macOS内蔵や他のセキュリティソフトによるポートブロックの可能性がある場合は一時的に無効化し、問題解消すれば設定見直しを。
- 異なるブラウザ/端末での動作確認: 別環境でも同じ現象が起きるかどうかテストすると、キャッシュやデバイス独自の設定起因か判別できます。
- ローカルDNSやhostsファイル設定の確認: 独自ドメイン使用時は、
localhostやIPアドレスではなくホスト名が127.0.0.1か::1に紐付いているかチェック。- macOS:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hosts
- macOS:
まとめ
ローカル開発でWebサーバー障害はよくある悩みですが、設定ファイル構文確認・エラーログ解析・サービス状態・権限確認等を系統立てて進めることで殆どの問題は自力で解決できます。ServBay内蔵の診断ツールやservbayctlコマンドも大きな助けになります。難しい障害が出た場合は公式ドキュメントや技術サポートにもぜひ相談してください。
