こんにちは、標準的レンタルサーバーを運営している吉岡です!今日はエックスサーバーを利用している皆さんが一度は直面する「サブドメインだけPHPバージョンを変えたいのに、設定項目が見当たらない!」という悩みについて、エンジニアの視点から徹底的に解説していきますよ。
エックスサーバーは国内シェアも高く、非常に安定したサーバーなのですが、その設計思想ゆえに「ドメインごとにPHPを固定する」という仕様がサブドメインにも影響してしまうんです。メインサイトは最新のWordPressで爆速に、でもサブドメインの古いツールはそのまま動かしたい……。そんな「わがまま」を叶えるための具体的な手順を、初心者の方でも迷わないように網羅しました。「ここ、ちょっと難しいかも」というポイントもしっかりフォローするので、一緒に頑張りましょうね!
この記事で解決できること
- サブドメインごとに個別のPHPバージョンを割り当てる具体的な方法
- 設定後に発生しがちな「500エラー」の確実な回避・解決策
- 高速化機能「Xアクセラレータ」との競合を防ぐための設定手順
- 古いPHPを使い続ける際のセキュリティ上の注意点と代替案
エックスサーバーのサブドメインphpバージョン変更
サーバーパネルの管理仕様と設定継承の仕組み
エックスサーバーを運用していると、「サブドメインの設定画面にもPHPバージョンの切り替えスイッチがあればいいのに……」と思ったことはありませんか?実は、エックスサーバーの現行仕様では、PHPバージョンの設定はあくまで「ドメイン(親ドメイン)単位」でしか管理できないようになっているんです。これには、サーバー側のファイル構造が大きく関係しています。
なぜサブドメイン単体で設定できないのか?
通常の共用サーバーでは、サブドメインを作成すると親ドメインの public_html ディレクトリと同列、あるいはその配下にフォルダが作られます。エックスサーバーの場合、この親ドメインに対して設定された php.ini や実行エンジンの指定が、その配下にあるすべてのディレクトリに対して「再帰的」に適用される仕組みになっているんですね。これを「設定の継承」と呼びます。
継承のメリットとデメリット
この仕組みは、大量のサブドメインを運用する際には一括で管理できて非常に楽なのですが、今回のように「特定のサイトだけ古いPHP 7.4で動かしたい」という場合には大きな壁となります。親ドメインをPHP 8系に上げると、サブドメインで動いていた古いプログラムが突然「クリティカルエラー」を吐いて停止してしまう……なんていうトラブルは、サーバー管理者の日常茶飯事なんです。でも安心してくださいね、この「継承」を上書きして、特定の場所だけ別のPHPを実行させる手法がちゃんと存在します。それが次から説明する「CGIモード」を活用した方法です。
CGI版PHPのコマンドパスを特定する方法
サブドメインのPHPを個別に変更するための第一歩は、サーバー内にインストールされている「PHP本体」の場所(パス)を突き止めることです。エックスサーバーには、過去のバージョンから最新のものまで、驚くほどたくさんのPHPが「隠しキャラ」のように用意されているんですよ。これを使わない手はありません!
コマンドパスの確認手順
まずは、エックスサーバーの「サーバーパネル」にログインしてください。メニューの中に「サーバー情報」という項目がありますので、そこをクリックし、さらに「コマンドパス一覧」というタブを開きます。すると、ズラーッとPHPのパスが並んでいるはずです。ここで注意してほしいのが、似たような名前のパスが2種類あることです。具体的には /usr/bin/php8.1(CLI版)と /usr/bin/php-fcgi8.1(CGI/FastCGI版)です。
なぜ「php-fcgi」版を選ぶ必要があるのか?
ここが非常に重要です。Webサイトとしてブラウザからアクセスして動かす場合は、必ず「php-fcgi」と付いている方のパスを選んでください。CLI版は「コマンドライン」専用で、Webサーバー(Apache)との連携に必要な情報を正しく処理できない場合があるんです。もしPHP 7.4を使いたいのであれば、/usr/bin/php-fcgi7.4 というパスをしっかりと手元にメモしておきましょうね。このパスを間違えると、後でどんなに設定を頑張っても「404」や「500」エラーから抜け出せなくなってしまいますよ。
php.fcgiファイルの作成とアップロード
パスが特定できたら、次はそのPHPを呼び出すための「命令書」を作成します。専門用語で「ラッパースクリプト」と呼びますが、要するに「このディレクトリのPHPファイルが呼ばれたら、このバージョンのPHPエンジンで動かしてね」と仲介してくれる小さなファイルのことです。
実行スクリプトの書き方
PCでメモ帳などのテキストエディタを開き(できれば、VS CodeやTeraPadなどの高機能なエディタがおすすめですよ)、以下の2行を記述してください。例としてPHP 7.4を使う場合の記述を紹介しますね。
#!/bin/sh
exec /usr/bin/php-fcgi7.4
コードの意味をちょっとだけ解説
1行目の #!/bin/sh は「これはシェルスクリプトですよ」という宣言です。2行目の exec は、指定したパスのPHPを実行しなさい、という意味になります。このファイルを php.fcgi という名前で保存しましょう。拡張子が .fcgi になっていることが、エックスサーバーで動作させるための必須条件になります。作成したファイルは、対象となるサブドメインの公開ディレクトリ(通常は public_html の中にあるサブドメイン名のフォルダ)の直下に、FTPソフトを使ってアップロードしてくださいね。
パーミッション705と改行コードの注意点
さて、ここからが一番の「落とし穴」です。ファイルを作ってアップロードしただけでは、サーバーは「このファイルを実行していいのか分からないよ!」とそっぽを向いてしまいます。ここで「パーミッション(権限)」と「改行コード」という2つの設定を完璧にこなす必要があります。
エックスサーバー特有の「705」ルール
エックスサーバーはセキュリティを確保するために「suEXEC」という仕組みを採用しています。これは「他人のファイルを勝手に実行させない」ための厳しいルールです。先ほどアップした php.fcgi のパーミッションは、必ず「705」または「755」に設定してください。多くのブログで紹介されている「644」などの設定では、実行権限がないため絶対に動きません。逆に「777」のようなガバガバな設定にすると、サーバーが「危険すぎる!」と判断して500エラーを出してしまいます。この「ちょうどいい権限」が 705 なんです。
意外と気づかない「改行コード」の罠
Windowsを使っている方は特に注意してください。Windowsで作成したファイルの改行コードは通常「CRLF」ですが、サーバーのOSであるLinuxは「LF」という形式しか受け付けません。もしCRLFのままアップロードすると、見た目は完璧なのに「ファイルが見つからない」といった謎のエラーに悩まされることになります。アップロードする前に、エディタの設定で改行コードを「LF」に変更して保存するか、FTPソフトの転送モードを「アスキーモード」に設定してアップロードするようにしましょう。ここ、本当に多くの人がハマるポイントなんですよ。
.htaccessでActionを指定する正しい記述
いよいよ仕上げです。Webサーバー(Apache)に対して、「このフォルダにある .php ファイルには、さっき作った php.fcgi を使って処理を開始せよ」という最終命令を下します。これには .htaccess という設定ファイルを使います。
.htaccessに追記するコード
サブドメインのルートディレクトリにある .htaccess を開き、以下の内容を追記してください。すでに記述がある場合は、なるべく上の方に追記するのがコツですよ。
Action myphp-script /php.fcgi
AddHandler myphp-script .php
パス指定の重要なルール
ここで1点、非常に大切なことがあります。Action 行に記述する /php.fcgi というパスは、サーバー上の絶対パスではなく「URLとしてのパス」です。もし、サブドメインのルート( https://sub.example.com/ )の直下にファイルを置いたなら /php.fcgi でOKです。しかし、もしサブディレクトリ( https://sub.example.com/wp/ )などの配下で個別に設定したい場合は、/wp/php.fcgi のように記述を調整する必要があります。この「スラッシュから始まるパス」が、ドメインのトップページから見た場所を指していることを忘れないでくださいね。これで、設定はすべて完了です!
エックスサーバーサブドメインphpバージョンの罠
XアクセラレータVer.2の無効化と設定変更
「よし、完璧に設定したぞ!」と思ってサイトにアクセスしても、なぜかPHPバージョンが変わっていない……。そんな時、十中八九あなたの邪魔をしているのが、エックスサーバー自慢の高速化機能「Xアクセラレータ Ver.2」です。皮肉なことに、この高速化技術が「便利すぎて不便」な状況を作り出しているんですね。
Xアクセラレータ Ver.2の動作原理と競合
Xアクセラレータ Ver.2は、PHPの実行を「PHP-FPM」という非常に高速なモードで固定して処理します。このモードはサーバーパネルの設定を直読みするため、我々が .htaccess で一生懸命書いた「独自の設定(AddHandlerなど)」を、親切心(?)で無視してしまう仕様なんです。つまり、どんなに正しいスクリプトを書いても、Ver.2が有効な限りはパネルで設定したバージョンが優先されてしまいます。
解決策は「Ver.1」へのダウングレード
これを回避するには、一時的に「高速化」の恩恵を少しだけ譲歩する必要があります。サーバーパネルの「高速化」→「Xアクセラレータ」から、対象ドメインの設定を「Ver.1」または「OFF」に変更しましょう。Ver.1であれば、静的ファイルのキャッシュ機能は維持しつつ、PHPの実行に関しては .htaccess の指示を聞いてくれるようになります。もちろん、メインドメインの表示速度が数ミリ秒落ちる可能性はありますが、サブドメインの互換性を守るためには避けて通れない道なんです。どちらを取るか、サイトの目的に合わせて判断してくださいね。
500エラーや反映されない時の解決策一覧
設定が終わった瞬間に画面が真っ白になり、「500 Internal Server Error」という無慈悲な文字が出ると、心臓がバクバクしますよね(私も何度も経験しました……)。でも、このエラーが出るということは、設定が「効いている」という証拠でもあるんです。原因はだいたい決まっていますので、落ち着いてチェックしていきましょう。
| 確認項目 | 原因 | 解決アクション |
|---|---|---|
| パーミッション | php.fcgiが644や777になっている | FTPソフトで「705」に変更する |
| 改行コード | Windowsの「CRLF」で保存されている | エディタの設定を「LF」にして再保存 |
| コマンドパス | メモしたパスが間違っている(CLI版など) | サーバーパネルで再度パスを確認し修正 |
| .htaccessの記述 | Actionのパス指定が間違っている | URL上のパス(/からの記述)か再確認 |
| 反映の遅延 | サーバー側のキャッシュが残っている | 5分ほど待機してから再読み込み |
それでも解決しない場合は?
もし上記をすべて試してもダメなら、一旦 .htaccess の追記部分をコメントアウト(行頭に # を付ける)して、サイトが表示されるか確認しましょう。もし表示されるなら、問題は php.fcgi 側。エラーが消えないなら .htaccess 自体の記述ミス(全角スペースの混入など)です。こうやって「切り分け」をすることが、吉岡流のトラブルシューティングのコツですよ!
php.iniを読み込ませ正常に動作させるコツ
ここまでの設定で、とりあえずPHPのバージョンは切り替わります。しかし、WordPressなどの本格的なアプリを動かす場合、もう一つ忘れてはいけないのが php.ini の存在です。これがないと、ファイルのアップロードサイズ制限が初期値(2MBなど)に戻ってしまったり、タイムアウトが頻発したりして、非常に使いにくいサイトになってしまうんです。
-c オプションで設定ファイルを指定する
CGIモードで動作させている場合、PHPは標準の php.ini を読み込んでくれません。そこで、先ほど作成した php.fcgi を以下のように改造して、明示的に php.ini の場所を教えてあげましょう。
#!/bin/sh
exec /usr/bin/php-fcgi7.4 -c /home/ユーザーID/ドメイン名/xserver_php/php.ini
パスの調べ方と重要性
-c の後に続くパスは、サーバーパネルの「php.ini設定」で確認できるディレクトリを指定します。エックスサーバーではドメインごとに xserver_php フォルダ内に設定ファイルが生成されているので、これを参照させるのが一番安全です。これを指定しないと、セッションが維持できずに管理画面から何度もログアウトさせられる……なんていう、原因不明のバグに襲われる可能性があるんですよ。「バージョンを変えたら挙動がおかしいな?」と思ったら、この -c オプションの追記を検討してみてくださいね。
EOLを迎えた古いPHPを運用する安全上のリスク
ここで少し、運営者としての「お節介」をさせてください。今回紹介した方法で、例えば PHP 5.6 や 7.4 などの古いバージョンを動かすことは可能ですが、これには大きなリスクが伴います。PHPには「サポート期限(EOL)」があり、期限が切れたバージョンには新しいセキュリティパッチが提供されません。
脆弱性を放置する危険性
サポートが終了したPHP(EOL:End of Life)を使い続けるということは、鍵の壊れたドアをそのままにしているようなものです。新たな脆弱性が発見されても修正されないため、悪意のある攻撃者にサイトを改ざんされたり、踏み台にされたりする危険が極めて高いんです。特にサブドメインが乗っ取られると、同じアカウントで管理している「メインドメイン」まで被害が及ぶ可能性があります。
(出典:PHP公式サイト Supported Versions)
どうしてもの時の「応急処置」として考える
「どうしても古いプログラムを修正する時間が取れない」という場合の、あくまで期間限定の応急処置と考えてくださいね。もし可能であれば、プログラムを改修して PHP 8系に対応させるか、古いサイト自体を静的なHTMLに変換してしまうなどの恒久的な対策を並行して進めることを、強くおすすめします。安全なサーバー運用こそが、ユーザーの信頼に繋がりますからね!
独立した別ドメインとして追加する代替案の検討
最後になりますが、「.htaccess やスクリプトを弄るのは、どうしても不安……」という方に向けた、ちょっとした裏技をお教えします。それは、サブドメインを「サブドメイン設定」としてではなく、一つの「独立したドメイン」としてエックスサーバーに追加してしまう方法です。
独立ドメインとして追加するメリット
エックスサーバーのパネルから「ドメイン設定」→「ドメイン設定追加」で、例えば sub.example.com をそのまま追加しようとすると、通常はエラーになります。しかし、一旦外部のDNSサーバーを経由させたり、設定のタイミングを工夫したりすることで、サーバーパネル上で「独立したドメイン」として認識させることができる場合があります。これができると、特別なスクリプトを書かなくても、コントロールパネルの「PHPバージョン切り替え」からポチポチ選ぶだけで、サブドメインのバージョンを自由に変えられるようになるんです。
運用の手間とコストの天秤
ただし、この方法はDNSの知識が必要になりますし、SSLの設定が少し複雑になることもあります。また、本来のサブドメイン管理の枠を外れるため、後で構成を整理する時に混乱するかもしれません。「技術的な苦労をしてCGIモードでいくか」「DNS設定を頑張ってパネル管理の楽さを取るか」。ご自身のスキルと、これからそのサイトを何年運用するかという計画に合わせて選んでみてくださいね。迷ったら、まずは今回解説した「CGIモード」から試してみるのが王道ですよ!
結び:エックスサーバーサブドメインphpバージョン
お疲れ様でした!「エックスサーバー サブドメイン phpバージョン」の個別変更について、仕組みから具体的な手順、そして注意点まで駆け足で解説してきましたが、いかがでしたでしょうか?最初は「難しそう……」と感じたかもしれませんが、一度やってみると「あ、こういうことか!」とパズルが解けるような楽しさもあるはずです。
エックスサーバーという強力なプラットフォームの上で、メインサイトの速度を犠牲にすることなく、大切なサブドメインのコンテンツを共存させる。そのためには、今回紹介したような「少しだけ裏側を知る」ための知識が、あなたの強力な武器になります。もし途中で止まってしまったり、エラーが消えなかったりしても、一つ一つ要素を切り分けてチェックすれば必ず解決できますよ。あなたのサイト運営が、より快適で安全なものになることを、吉岡も心から応援しています!また分からないことがあったら、いつでもブログを覗きに来てくださいね。それでは、また!
【深掘り】エックスサーバーでのPHP個別設定に関するよくある質問
ここでは、実際に設定を試みた方から寄せられる「さらに踏み込んだ疑問」について、私、吉岡が一つずつお答えしていきますね。技術的な仕様が絡む部分なので、少し難しいかもしれませんが、ここを理解しておくとトラブルに強くなれますよ。
Q1. メインドメインの.htaccessとサブドメインの.htaccess、どちらが優先されるの?
これは「サブドメイン側の設定が優先」されます。エックスサーバーのディレクトリ構造では、親ドメインの設定が子ディレクトリへと引き継がれますが、子ディレクトリ(サブドメイン)に .htaccess が置かれている場合、その中身が親の設定を上書き(オーバーライド)する仕組みになっています。ですので、今回紹介した手順でサブドメイン側にしっかりと記述を行えば、メインサイトに影響を与えることなく、そのディレクトリ内だけを別世界(別バージョン)に変えることができるんです。この「上書き」のルールを知っておくと、他の設定変更でも応用が利きますよ。
Q2. php.fcgi を設置したのに、phpinfo() で確認するとバージョンが変わっていないのはなぜ?
まず確認してほしいのは、ブラウザやサーバーのキャッシュです。エックスサーバー側で設定が反映されるまで、最大で数分程度のタイムラグが発生することがあります。また、ブラウザが古い情報を表示していることもあるので、Ctrl + F5(スーパーリロード)を試してみてください。それでもダメな場合は、.htaccess の Action 行に書いたパスが間違っている可能性が高いです。例えば、/php.fcgi と書いたのに、実際には public_html/sub/ の中にファイルを置いていた……なんてことはありませんか?その場合は /sub/php.fcgi と書かなければなりません。URLのルートから見てどこにあるか、もう一度指差し確認してみましょうね!
Q3. PHPのバージョンを変えたら、WordPressのプラグインが動かなくなった!
これはPHPのバージョンの互換性の問題ですね。例えば、PHP 8系から 7.4 に「下げた」場合、最新のプラグインが 8系専用の構文を使っているとエラーになります。逆に 8系に「上げた」場合、古いプラグインが対応していないと同じことが起こります。この場合は、一度すべてのプラグインを無効化し、一つずつ有効に戻しながら「犯人」を特定していく地道な作業が必要になります。こういった互換性のチェックを安全に行うためにサブドメインを活用するのは、非常に賢い運用方法だと言えますよ。
設定ミスをゼロにする!公開前最終チェックリスト
「よし、設定できた!」と思っても、意外な見落としがあるものです。公開してユーザーさんにエラーを見せてしまう前に、私と一緒にこの5つの項目を確認してみませんか?これさえクリアしていれば、大抵のトラブルは防げますよ。
設定完了後の「これだけは確認!」リスト
- php.fcgi の改行コードは「LF」になっていますか?(Windowsのメモ帳で保存すると「CRLF」になり、動かない原因の第1位です!)
- パーミッションは「705」に設定されていますか?(644のままだと実行権限がないため、サーバーに門前払いされてしまいます。)
- Xアクセラレータは「Ver.1」または「OFF」になっていますか?(Ver.2は非常に強力ですが、今回のような手動設定を無視してしまいます。)
- Action行のパス指定は、URLとしての正しいパスですか?(サブディレクトリに設置した場合は、そのフォルダ名もパスに含める必要があります。)
- php.ini のパス指定(-cオプション)は絶対パスですか?(
/home/ユーザーID/...から始まるフルパスで書かないと、設定が読み込まれません。)
チェックリストの重要性について
サーバーの設定は、たった一文字のスペルミスや、目に見えない改行コードの違いで、すべてが止まってしまうほど繊細なものです。私も駆け出しの頃は「設定は合っているはずなのに、なぜ動かないんだ!」と頭を抱えて一晩中悩んだこともありました。でも、落ち着いて一歩ずつチェックすれば、必ず答えは見つかります。特にエックスサーバーはエラーログも確認しやすいので、もし .htaccess で ErrorLog を指定できる知識があれば、そこを見て具体的なエラー内容を確認するのも手ですね。「難しそう……」と思わずに、まずはこのチェックリストを順番にクリアしていきましょう。
| ステップ | 作業内容 | 注意すべきポイント |
|---|---|---|
| 1. ファイル作成 | php.fcgiの作成 | 改行コードはLF、文字コードはUTF-8(BOMなし) |
| 2. アップロード | サブドメインのルートへ配置 | 転送モードが「アスキーモード」になっているか確認 |
| 3. 権限変更 | 属性(パーミッション)変更 | 「705」または「755」へ確実に変更する |
| 4. .htaccess追記 | ActionとAddHandlerの記述 | 余計な全角スペースが入っていないか注意 |
| 5. 動作確認 | phpinfo()での表示 | キャッシュを削除した状態でバージョンをチェック |
結び:エックスサーバーサブドメインphpバージョン
いよいよ、今回の長い旅も終わりです。エックスサーバーでサブドメインごとにPHPバージョンを使い分ける方法は、一見すると遠回りに見えるかもしれません。しかし、サーバーパネルの標準機能に頼らず、自分たちの手で設定ファイル(.htaccess や php.fcgi)を操ることは、サイト運営者としてのスキルを一段階引き上げてくれるはずです。
これからの運用に向けて
最初は500エラーが出たり、設定が反映されなかったりと、苦労することもあるかなと思います。でも、その一つひとつの試行錯誤が、将来的に大きなトラブルが起きたときの「解決力」に変わるんですよ。もし今のサイトが古くなってきて、どうしても古いPHPを使い続けなければならない状況なら、今回の手順は最強の味方になります。ただ、先ほどもお伝えした通り、セキュリティのことも忘れずに、少しずつ新しい環境への移行も検討してみてくださいね。私、吉岡は、あなたのサイトが常に安全で、快適に動き続けることを応援しています。それでは、素晴らしいサイト運営ライフを!



コメント