しばらく前に、Cloudwaysで既存のVultrサーバーのオペレーティングシステムをDebian 11からDebian 12にアップグレードするために新しいサーバーにレプリケートしました。サーバーの複製により、サーバーの設定はそのままにして最新のOSのサーバーにアップグレードしました。 WordPress アプリケーションを追加すると、サーバー内の他のサイトにリダイレクトされるルーティングエラーが発生することがわかりました。
一時的な方法でNginxサービスを再起動すると問題は解決しましたが、根本的な問題を解決するためにこのバグをクラウドウェイズに報告しました。クラウドウェイズエンジニアリングチームの担当者が問題の原因を特定してエラーを修正しました。
技術的な問題なので、私のような一般ユーザーは知る必要はありませんが、記録目的で問題の原因と解決策について簡単にまとめました。クラウドウェイズで問題が発生した場合は、ライブチャットに連絡するとほとんどの場合、迅速に問題を解決します。
クラウドウェイズサーバーの複製後のルーティングエラーのバグを修正
1. 症状
- 異常なルーティング： サーバー上の新規アプリケーション（WordPress）を作成してURLにアクセスすると、新しいサイトが開かずにサーバー内の他の既存のサイトに接続（リダイレクト）されるという問題が発生しました。
- 一時的な方法でNginxサービスを再起動することでトラブルシューティング： サーバー（nginx/アパッチ）サービスを手動で再起動すると、設定が適用され、新しいアプリケーションの元のURLに正常に接続されました。
2.原因
- ハンドラ名の競合のバグ: 新しいアプリケーションを作成（プロビジョニング）すると、サーバーの設定を自動化するスクリプト（Ansible）内にバグがありました。
- Apacheの再起動がありません： Multi-PHP環境とSingle-PHP環境の設定更新を担当する「ハンドラ（コマンド）」の名前が同じに指定されていました。この競合により、新しい仮想ホスト（Virtual Host）ファイルがサーバー上に正常に作成されたにもかかわらず、 Apacheサーバーをリロードする手順は「スキップ」処理れました。
- 古い設定を維持する： Apacheが新しい設定を読み取ることができず、過去の設定（Stale vhosts）をそのまま維持したため、新しく作成されたアドレスを認識せず、奇妙な既存のサイトに接続したのです。
- 참고사항: これは単にDebian 12 OS自体の問題ではなく、新しく複製されたサーバーに適用された特定のプロビジョニングスクリプトパスにのみ存在したシステムバグでした。
3. 解決
- スクリプトの変更: クラウドウェイズのエンジニアリングチームでクラッシュを起こしたハンドラの名前をそれぞれ固有の名前に変更することで、クラッシュを排除しました。
- サーバー正規化： 問題が発生したサーバーのApacheを再ロードして、押されていた仮想ホスト設定をすべて正常に適用しました。
👉実際、この症状はApache Webサーバーに関連する設定の競合のために発生しました。結果的な話ですが、Webスタックをハイブリッドスタックの代わりに ライトニングスタックで設定した場合、このようなルーティング問題自体を避けることができたようです。
クラウドウェイズでライトニングスタックを選択すると、Apache（Apache）を経由しないため、サイト速度の面では確かに高速です。しかし、Apache環境のコアである.htaccessファイルをサポートしていないため、これに基づいて動作する一部 WordPress プラグイン（セキュリティ、キャッシュなど）で互換性の問題が発生する可能性があります。だから私は安定性のために主にハイブリッドスタックを使う方です。ただし、複雑な機能を必要としないシンプルなウェブサイトであれば、ライトニングスタックを選択するのも良い選択になります。
ウェブスタックは アプリケーション設定 » WebStackで変更することができます。
基本的な解決策
この問題は、クラウドウェイズシステム（バックエンド自動化スクリプト）で根本的に解決されました。
エンジニアリングチームがアプリケーションを作成するときに駆動されるスクリプト自体の論理エラー（名前の競合）を修正したため、将来同じ問題は再発しません。
したがって、後で複製したサーバーに新しいアプリケーションを追加するとき クラウドウェイズ開発チームがサーバー構成ファイルを直接変更したり、ユーザーがサーバーを毎回手動で再起動する必要はありません。 新しいアプリケーションを作成すると、通常のURLに自動的にリンクされます。
コメントを残す