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エラー例：

• 証明書ファイルが存在しない場合:

  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

  loading certificates: open xxxxx: no such file or directory のようなエラーは、Caddyfileに指定したSSL証明書ファイルのパスが誤っているか、ファイル自体が存在しないことを示します。サイト設定内で証明書（.crt/.cer/.pem）や秘密鍵（.key）ファイルのパスが正しいか、該当パスに実ファイルがあるかを確認してください。ServBayでは手動インポートやACMEによるSSL証明書の自動取得もサポートしていますので、ServBayのSSL設定もご確認ください。

• Webルートディレクトリのパスエラー（スペースを含む）:

  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

  parsing 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

不備がある場合は、NGINXがエラー箇所のファイルと行番号を明示します。主なエラー例は次の通りです。

1. 構文エラー: 例）セミコロン（;）の省略や、波カッコ（}）の数に誤りがある場合。
2. パスの間違い: includeやその他指示で指定したパスのファイルやフォルダが存在しない場合。
3. ポート競合: 監視ポートが他プログラムと重複している場合。

Apacheの設定チェック

Apacheはapachectl configtestコマンドで構文チェックが行えます。

/Applications/ServBay/bin/apachectl configtest

問題なければ「Syntax OK」と返ります。エラーがある場合は詳細情報が表示されます。代表的なエラー例：

1. モジュール読み込み失敗: 設定ファイルでLoadModule参照のモジュールが存在しない場合やパスミス。
2. .htaccessの構文エラー: サイトフォルダの.htaccessファイルに文法ミスがあると、Apache設定テスト全体の失敗やディレクトリアクセス不可の原因になります。
3. ディレクトリ権限の不備: DirectoryやFilesディレクティブでの権限設定（Require、Allow、Denyなど）がアクセスを阻害している場合。

500内部サーバーエラーの対処

500 Internal Server Errorは、サーバー側で処理時に予期しない問題が発生しリクエストを完了できないことを示すHTTPステータスコードです。多くの場合、Webアプリのバックエンドスクリプト（PHP、Python、Node.jsなど）の実行失敗が原因となります。

基本のチェック手順

500エラーに遭遇したときは以下のステップが有効です。

1. 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を含む記載を探しましょう。

2. バックエンドサービス（PHP-FPM等）が動作中か確認: PHPの場合、PHP-FPMプロセスが正常に動作しているかチェックします。

   ps aux | grep php-fpm

   php-fpm: master processやphp-fpm: pool wwwを含む行が表示されるか確認。なければPHP-FPMが停止・クラッシュしています。ServBay UIまたはservbayctlコマンドで起動してください。

3. バックエンドスクリプト（PHP等）のエラーログ確認: FastCGIやスクリプトエラーがサーバーログで示されていた場合、対応する言語のエラーログも見ましょう。

   • PHP: /Applications/ServBay/var/logs/php/php_error.log PHPの場合はFatal error、Parse error、Warning、Noticeのうち、ご利用スクリプトに関連するものを探してください。本番環境ではdisplay_errorsは無効が推奨ですが、開発中は一時的に有効（php.ini設定）にして内容把握も可能です。

4. ファイルとディレクトリの権限チェック: サーバープロセス（通常は_wwwユーザー等）がWebファイルとディレクトリへの読込・書込権限を持っているか確認します。

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

   ルート・配下のファイル/ディレクトリに対して、少なくとも読み込み権限が必要です。アップロード先やログの書き込みが絡む場合は書き込み権限も必要。chmodやchownコマンドで調整できますが、操作は慎重に。

サーバー別 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またはサイト毎の設定におけるfastcgi_passの指定が、PHP-FPM等の正しいアドレス・ソケットへ向いているか確認。
  2. client_max_body_size: 大きなファイルアップロードで500エラーが発砲する場合は、この値が小さすぎないか見直し。
  3. try_files指示: 適切なインデックスまたはFastCGIへのリクエスト引渡し設定になっているか確認。

• Apacheの場合:

  1. mod_rewriteモジュール: .htaccessによるURLリライトルール利用時は、mod_rewriteが有効か確認。
  2. .htaccess内容: 誤った記述は即500エラーの原因。特にRewriteRule等の構文要チェック。
  3. 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

-allオプションはWebサーバーに関連する連携サービス（例：FastCGI設定時はPHP-FPM等）も同時に再起動を試みます。

サービス状態の確認

servbayctl statusコマンドで現在のサービス稼働状態を確認できます。

# Caddyの状態表示
servbayctl status caddy -all

# NGINXの状態表示
servbayctl status nginx -all

# Apacheの状態表示
servbayctl status apache -all

出力結果には「running（稼働中）」や「stopped（停止中）」等が表示され、起動に成功したかの判断材料となります。

詳細なトラブルシューティング手順

上記で解決できない場合、下記のより高度な確認を行いましょう。

1. ブラウザ開発者ツールの利用: ブラウザの開発者ツール（通常F12）を開き、「コンソール（Console）」や「ネットワーク（Network）」タブでJavaScriptエラーやHTTPステータス、レスポンスなどを確認し、問題がフロント側かバックエンド側かを切り分けます。
2. curl -vコマンドで詳細確認: ターミナルにて curl -v your-website.servbay.demoを実行し、リクエスト・レスポンスやSSL/TLS、ヘッダ情報などプロトコルレベルの診断ができます（your-website.servbay.demoはご自身のサイトドメインで置き換えてください）。
3. 一時的にファイアウォールを無効化: macOS標準やサードパーティのファイアウォールが接続を阻害している場合があります。一時的に停止し、問題が解消されれば、必要なポート（80,443等）が開放されているかルールを確認。
4. 異なるブラウザ/端末での動作チェック: 別のブラウザや他端末からもサイトにアクセスし、すべてで発生するかを確認。キャッシュや固有設定の問題切り分けに効果的です。
5. ローカルのDNSやhostsファイル設定の確認: 独自ドメイン利用時（localhostやIPアドレスを除く）は、/etc/hostsやローカルDNS設定で、指定ドメインが正しく127.0.0.1や::1に向いているかを確認しましょう。

まとめ

Webサーバーの不調はローカル開発では頻繁に発生しますが、設定ファイルの構文点検、エラーログの精読、サービス状態・ファイル権限の確認を徹底すれば、多くの問題は解決できます。ServBay内蔵のトラブル診断やservbayctlコマンドは強力なサポートとなります。複雑な事例では公式ドキュメントやサポートチームへの問い合わせもご活用ください。