ServBay Webサーバー トラブルシューティングガイド
ServBayはCaddy、NGINX、ApacheのいずれかをデフォルトWebサーバーとして選択でき、柔軟なローカル開発環境を提供します。運用中、サイトへのアクセス不可や表示遅延、または500内部サーバーエラーの表示など、さまざまな問題に直面することがあります。本ガイドでは、ServBay環境でよく見られるWebサーバーに関するトラブルの診断・解決方法を分かりやすく解説します。
ServBay内蔵のトラブル診断ツールを活用する
ServBayにはトラブルシューティングツールが内蔵されており、よくある設定ミスやサービスの問題を自動で検出・通知します。トラブル発生時は、まずこのツールをご利用いただくことを強くおすすめします。
ServBayアプリを開き、左側のナビゲーションバーから「トラブル診断」をクリックすると、ServBay内蔵の診断画面へアクセスできます。
このツールでは、ServBayのコアコンポーネントの状態、ポート競合、設定ファイルの構文チェックなどを実行し、問題の特定・対策案を提示します。問題箇所を迅速に特定するのに大変役立ちます。
Webサーバー設定ファイルを確認する
Webサーバーの設定ファイルのミスは、Webサイトが正常に表示されない主な原因の1つです。ServBayではサーバーごとに専用の構文チェックツールが用意されています。
Caddyfileのチェック
Caddyのvalidate
コマンドを用いて、Caddyfileの構成に問題がないか確認できます。
/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile
構文エラーがなければ「Valid configuration」と表示されます。不備がある場合は、エラー内容に基づいたメッセージが示されます。
補足: caddy validate
コマンドは多くのINFO
やWARN
メッセージを出力する場合がありますが、これはCaddyの内部処理の情報であり、必ずしもエラーとは限りません。最終的に「Valid configuration」となれば構文上は正しいです。
よくあるCaddyfileエラー例:
証明書ファイルが存在しない場合:
bash2024/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
1
2
3loading certificates: open xxxxx: no such file or directory
のようなエラーは、Caddyfileに指定したSSL証明書ファイルのパスが誤っているか、ファイル自体が存在しないことを示します。サイト設定内で証明書(.crt
/.cer
/.pem
)や秘密鍵(.key
)ファイルのパスが正しいか、該当パスに実ファイルがあるかを確認してください。ServBayでは手動インポートやACMEによるSSL証明書の自動取得もサポートしていますので、ServBayのSSL設定もご確認ください。Webルートディレクトリのパスエラー(スペースを含む):
bash2024/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
1
2parsing caddyfile tokens for 'root': too many arguments
というエラーは、Webルートのパスにスペースが含まれていることが原因です。例えば、root * /Applications/ServBay/www/public web
のpublic web
部分が2つの引数と認識されてしまいます。正しくは、スペースを含むパス全体をダブルクオーテーション("
)で囲み、root * "/Applications/ServBay/www/public web"
のように記述してください。推奨: ファイル名やディレクトリ名には極力スペースや特殊記号を避け、単語の区切りはハイフン(
-
)やアンダースコア(_
)で行いましょう(例:public-folder
やpublic_dir
)。Rewrite(リライトルール)のエラー:
CaddyfileでCaddyの構文に合わないRewriteルール(NGINXの設定例をコピーするなど)を記述すると、検証エラーの原因となります。Caddy Rewriteモジュールのドキュメントや、ServBayのNGINXサイト移行ガイドを参照し、正しい構文で記述してください。
NGINXの設定チェック
NGINX内蔵の-t
オプションで、nginx.confファイルの構文・有効性をチェックできます。
/Applications/ServBay/bin/nginx -t
正しい場合は次のように表示されます。
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
2
不備がある場合は、NGINXがエラー箇所のファイルと行番号を明示します。主なエラー例は次の通りです。
- 構文エラー: 例)セミコロン(
;
)の省略や、波カッコ(}
)の数に誤りがある場合。 - パスの間違い:
include
やその他指示で指定したパスのファイルやフォルダが存在しない場合。 - ポート競合: 監視ポートが他プログラムと重複している場合。
Apacheの設定チェック
Apacheはapachectl configtest
コマンドで構文チェックが行えます。
/Applications/ServBay/bin/apachectl configtest
問題なければ「Syntax OK」と返ります。エラーがある場合は詳細情報が表示されます。代表的なエラー例:
- モジュール読み込み失敗: 設定ファイルで
LoadModule
参照のモジュールが存在しない場合やパスミス。 - .htaccessの構文エラー: サイトフォルダの
.htaccess
ファイルに文法ミスがあると、Apache設定テスト全体の失敗やディレクトリアクセス不可の原因になります。 - ディレクトリ権限の不備:
Directory
やFiles
ディレクティブでの権限設定(Require
、Allow
、Deny
など)がアクセスを阻害している場合。
500内部サーバーエラーの対処
500 Internal Server Errorは、サーバー側で処理時に予期しない問題が発生しリクエストを完了できないことを示すHTTPステータスコードです。多くの場合、Webアプリのバックエンドスクリプト(PHP、Python、Node.jsなど)の実行失敗が原因となります。
基本のチェック手順
500エラーに遭遇したときは以下のステップが有効です。
Webサーバーのエラーログを確認: エラーの詳細が記録されていることが多く、まず最初に確認すべきポイントです。
- Caddy:
/Applications/ServBay/var/logs/caddy/error.log
- NGINX:
/Applications/ServBay/var/logs/nginx/error.log
- Apache:
/Applications/ServBay/var/logs/apache/error.log
最新のログエントリからerror
やcritical
を含む記載を探しましょう。
- Caddy:
バックエンドサービス(PHP-FPM等)が動作中か確認: PHPの場合、PHP-FPMプロセスが正常に動作しているかチェックします。
bashps aux | grep php-fpm
1php-fpm: master process
やphp-fpm: pool www
を含む行が表示されるか確認。なければPHP-FPMが停止・クラッシュしています。ServBay UIまたはservbayctl
コマンドで起動してください。バックエンドスクリプト(PHP等)のエラーログ確認: FastCGIやスクリプトエラーがサーバーログで示されていた場合、対応する言語のエラーログも見ましょう。
- PHP:
/Applications/ServBay/var/logs/php/php_error.log
PHPの場合はFatal error
、Parse error
、Warning
、Notice
のうち、ご利用スクリプトに関連するものを探してください。本番環境ではdisplay_errors
は無効が推奨ですが、開発中は一時的に有効(php.ini設定)にして内容把握も可能です。
- PHP:
ファイルとディレクトリの権限チェック: サーバープロセス(通常は
_www
ユーザー等)がWebファイルとディレクトリへの読込・書込権限を持っているか確認します。bashls -la /Applications/ServBay/www/your-site/
1ルート・配下のファイル/ディレクトリに対して、少なくとも読み込み権限が必要です。アップロード先やログの書き込みが絡む場合は書き込み権限も必要。
chmod
やchown
コマンドで調整できますが、操作は慎重に。
サーバー別 500エラー特有のポイント
Caddyの場合:
- FastCGI設定: Caddyfileの
php_fastcgi
やreverse_proxy
の設定が、PHP-FPMや他のバックエンドへの接続先(127.0.0.1:9000
やunix:/path/to/php-fpm.sock
等)と一致しているか確認。 - PHP-FPMの稼働: 対応するPHPバージョンのPHP-FPMサービスがServBayで起動中か要確認。
- リバースプロキシ設定:
reverse_proxy
で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内容: 誤った記述は即500エラーの原因。特に
RewriteRule
等の構文要チェック。 AllowOverride
設定: 対象ディレクトリで.htaccess
の内容を反映できるよう、AllowOverride
がAll
又はFileInfo
・Limit
等必須値になっているか確認。
サービスの管理
設定ファイル修正やバックエンド修復後には、Webサーバーや関連サービスの再起動が必要です。
サービスの再起動
servbayctl restart
コマンドで対象Webサーバーを再起動できます。
# Caddyの再起動
servbayctl restart caddy -all
# NGINXの再起動
servbayctl restart nginx -all
# Apacheの再起動
servbayctl restart apache -all
2
3
4
5
6
7
8
-all
オプションはWebサーバーに関連する連携サービス(例:FastCGI設定時はPHP-FPM等)も同時に再起動を試みます。
サービス状態の確認
servbayctl status
コマンドで現在のサービス稼働状態を確認できます。
# Caddyの状態表示
servbayctl status caddy -all
# NGINXの状態表示
servbayctl status nginx -all
# Apacheの状態表示
servbayctl status apache -all
2
3
4
5
6
7
8
出力結果には「running(稼働中)」や「stopped(停止中)」等が表示され、起動に成功したかの判断材料となります。
詳細なトラブルシューティング手順
上記で解決できない場合、下記のより高度な確認を行いましょう。
- ブラウザ開発者ツールの利用: ブラウザの開発者ツール(通常F12)を開き、「コンソール(Console)」や「ネットワーク(Network)」タブでJavaScriptエラーやHTTPステータス、レスポンスなどを確認し、問題がフロント側かバックエンド側かを切り分けます。
curl -v
コマンドで詳細確認: ターミナルにてcurl -v your-website.servbay.demo
を実行し、リクエスト・レスポンスやSSL/TLS、ヘッダ情報などプロトコルレベルの診断ができます(your-website.servbay.demo
はご自身のサイトドメインで置き換えてください)。- 一時的にファイアウォールを無効化: macOS標準やサードパーティのファイアウォールが接続を阻害している場合があります。一時的に停止し、問題が解消されれば、必要なポート(80,443等)が開放されているかルールを確認。
- 異なるブラウザ/端末での動作チェック: 別のブラウザや他端末からもサイトにアクセスし、すべてで発生するかを確認。キャッシュや固有設定の問題切り分けに効果的です。
- ローカルのDNSやhostsファイル設定の確認: 独自ドメイン利用時(
localhost
やIPアドレスを除く)は、/etc/hosts
やローカルDNS設定で、指定ドメインが正しく127.0.0.1
や::1
に向いているかを確認しましょう。
まとめ
Webサーバーの不調はローカル開発では頻繁に発生しますが、設定ファイルの構文点検、エラーログの精読、サービス状態・ファイル権限の確認を徹底すれば、多くの問題は解決できます。ServBay内蔵のトラブル診断やservbayctl
コマンドは強力なサポートとなります。複雑な事例では公式ドキュメントやサポートチームへの問い合わせもご活用ください。