PHPでWebサイトやWebアプリケーションを動かす場合、ApacheとPHPを組み合わせて利用するケースは非常に多くあります。
その中でも、現在よく利用されている構成の一つが「Apache+PHP-FPM」です。
PHP-FPMは「FastCGI Process Manager」の略で、PHPをFastCGIとして効率よく実行するための仕組みです。
Apache自身がPHPプログラムを直接実行するのではなく、Apacheが受け取ったPHPファイルへのリクエストをPHP-FPMへ渡し、PHP-FPMがPHPプログラムを実行します。
基本的な処理の流れは次のようになります。
ブラウザ
↓
Apache
↓
mod_proxy_fcgi
↓
PHP-FPM
↓
PHPスクリプトを実行
↓
Apache
↓
ブラウザ
たとえば、ユーザーが次のURLへアクセスしたとします。
https://example.com/index.php
Apacheがこのリクエストを受信すると、PHPファイルの処理をPHP-FPMへ渡します。
PHP-FPMはindex.phpを実行し、その実行結果をApacheへ返します。
Apacheは受け取った結果をHTTPレスポンスとしてブラウザへ返します。
つまり、ApacheとPHP-FPMの役割を簡単に整理すると、次のようになります。
Apache
→ HTTPリクエストの受付や静的ファイルの配信
PHP-FPM
→ PHPプログラムの実行
このようにWebサーバーとPHP実行環境を分離できることが、PHP-FPMを利用する大きな特徴です。
PHP-FPMとは
PHPをFastCGIとして実行する仕組み
PHP-FPMは、PHPに用意されているFastCGIのプロセスマネージャーです。
FastCGIを利用すると、PHPを実行するためのプロセスをあらかじめ起動して待機させることができます。
リクエストが発生するたびにPHP実行環境を一から起動するのではなく、待機しているPHP-FPMのワーカープロセスが処理を担当します。
そのため、Webサーバーとは独立してPHPプロセスを管理できます。
PHP-FPMでは複数のワーカーを管理できる
PHP-FPMでは、複数のPHPワーカープロセスを起動できます。
イメージすると次のようになります。
PHP-FPM
├─ PHPワーカー
├─ PHPワーカー
├─ PHPワーカー
└─ PHPワーカー
複数のアクセスが発生した場合、それぞれのワーカーがPHPリクエストを処理します。
PHP-FPMにはワーカー数を管理するためのさまざまな設定が用意されています。
代表的なものが次の設定です。
pm
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
アクセス数やサーバーのメモリ容量に合わせてこれらを調整することで、PHPの実行環境を最適化できます。
ApacheとPHP-FPMを連携する方法
mod_proxy_fcgiを利用する
Apache 2.4系では、PHP-FPMとの連携にmod_proxy_fcgiを利用できます。
mod_proxy_fcgiは、ApacheからFastCGIバックエンドへリクエストを転送するためのモジュールです。
PHP-FPMをバックエンドとして使用する場合は、基本的に次のApacheモジュールが必要になります。
mod_proxy
mod_proxy_fcgi
重要なのは、mod_proxy_fcgi自体がPHP-FPMを起動するわけではないことです。
PHP-FPMはApacheとは別のサービスとして起動しておく必要があります。
そのうえでApacheがFastCGI経由でPHP-FPMへ接続します。
PHP-FPMをインストールする
Debian・Ubuntu系の場合
PHP-FPMのインストール方法はLinuxディストリビューションやPHPバージョンによって異なります。
Debian・Ubuntu系では、一般的には次のようなコマンドを利用します。
sudo apt update
sudo apt install php-fpm
PHPのバージョンを指定してインストールする環境では、次のようなパッケージ名になることもあります。
php8.x-fpm
ただし、実際のバージョン番号やパッケージ名は環境によって異なります。
使用しているOSのリポジトリや導入済みPHPのバージョンを確認してください。
PHP-FPMの起動状態を確認する
PHP-FPMをインストールしたら、サービスが正常に起動しているか確認します。
例として、次のようなコマンドを使用します。
systemctl status php8.x-fpm
ここで使用するphp8.x-fpmは例です。
実際にはサーバーにインストールされているサービス名へ置き換える必要があります。
PHP-FPMが停止している場合は、環境に応じて次のように起動します。
sudo systemctl start php8.x-fpm
設定変更後は再起動することもあります。
sudo systemctl restart php8.x-fpm
Apacheでmod_proxy_fcgiを有効にする
Debian・Ubuntu系の設定例
Debian・Ubuntu系では、a2enmodを利用してApacheモジュールを有効にできます。
sudo a2enmod proxy
sudo a2enmod proxy_fcgi
有効化したらApacheを再起動または再読み込みします。
sudo systemctl restart apache2
モジュールが読み込まれているか確認する場合は、次のようなコマンドを利用できます。
apachectl -M
一覧に次のモジュールが表示されていれば、読み込まれています。
proxy_module
proxy_fcgi_module
なお、Apacheの設定方法やモジュールの有効化方法はLinuxディストリビューションによって異なります。
Red Hat系などでは設定方法やサービス名が異なる場合があります。
ApacheとPHP-FPMの通信方法
PHP-FPMとApacheを接続する方法には、大きく分けて2種類あります。
Unixドメインソケット
TCP/IP
どちらもPHP-FPMのlisten設定によって指定します。
Unixドメインソケット
Unixドメインソケットは、ApacheとPHP-FPMを同じサーバー上で動かす場合によく利用されます。
PHP-FPM側では、たとえば次のように設定します。
listen = /run/php/php-fpm.sock
この場合、ApacheとPHP-FPMは次のような形で通信します。
Apache
↓
/run/php/php-fpm.sock
↓
PHP-FPM
ネットワーク用のTCPポートを利用せず、Unix上のソケットを使ってプロセス間通信を行います。
TCP/IP
PHP-FPMをTCPポートで待ち受けさせることもできます。
たとえばPHP-FPM側を次のようにします。
listen = 127.0.0.1:9000
この場合は次のような通信になります。
Apache
↓
127.0.0.1:9000
↓
PHP-FPM
同じサーバー内でTCPを利用することも可能です。
また、ApacheとPHP-FPMを別のホストやコンテナで動かす構成では、TCPを使用することがあります。
UnixドメインソケットでApacheとPHP-FPMを連携する方法
PHP-FPM側のlistenを設定する
PHP-FPMのプール設定ファイルを確認します。
環境によって異なりますが、Debian・Ubuntu系では次のような場所に配置されることがあります。
/etc/php/8.x/fpm/pool.d/www.conf
設定ファイル内のlistenを確認します。
listen = /run/php/php-fpm.sock
実際のソケット名やパスは環境によって異なります。
たとえば次のような名前になっている場合もあります。
/run/php/php8.4-fpm.sock
Apache側で指定するパスとPHP-FPM側のlistenは必ず一致させる必要があります。
Unixソケットの権限を設定する
Unixドメインソケットを利用する場合、Apacheからそのソケットへ接続できる権限が必要です。
PHP-FPMでは、たとえば次のような設定を利用できます。
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
ただし、www-dataはあくまで一例です。
Apacheの実行ユーザーやグループはOSや設定によって異なります。
環境によってはapacheなどのユーザー名が使われる場合もあります。
そのため、Apacheがどのユーザー・グループで動作しているか確認し、PHP-FPMのソケットへアクセスできるように設定する必要があります。
また、環境によってはPOSIX ACLを利用して、
listen.acl_users
listen.acl_groups
などでアクセス権を設定することもできます。
つまり、重要なのは特定のユーザー名に固定することではなく、ApacheからPHP-FPMのUnixソケットへ正常に接続できる権限を設定することです。
Apache側でUnixソケットを指定する
FilesMatchとSetHandlerを利用する
Apache 2.4では、FilesMatchとSetHandlerを利用してPHPファイルをPHP-FPMへ渡す方法があります。
基本的には次のように設定します。
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost/"
</FilesMatch>
/run/php/php-fpm.sockの部分はPHP-FPM側で設定されている実際のソケットパスへ置き換えます。
PHP-FPM側が、
listen = /run/php/php8.4-fpm.sock
ならApache側も、
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost/"
</FilesMatch>
のようにします。
fcgi://localhost/の意味
Unixソケットの設定では、次の記述が少し分かりにくいかもしれません。
proxy:unix:/run/php/php-fpm.sock|fcgi://localhost/
ここにlocalhostと書かれていますが、PHP-FPMへTCP接続しているという意味ではありません。
実際の接続には、次のUnixソケットが利用されます。
/run/php/php-fpm.sock
したがって、
Unixソケット
+
fcgi://localhost/
というApache固有のFastCGIハンドラーの記述形式として理解するとよいでしょう。
VirtualHostでPHP-FPMを設定する
実際のWebサイトでは、VirtualHost単位でPHP-FPMへの接続を設定することがあります。
たとえば次のようになります。
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/example.com/public
<Directory /var/www/example.com/public>
AllowOverride All
Require all granted
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost/"
</FilesMatch>
</VirtualHost>
この場合、PHPファイルへのアクセスは次のような流れで処理されます。
example.com/index.php
↓
Apache VirtualHost
↓
FilesMatch
↓
mod_proxy_fcgi
↓
PHP-FPM
↓
index.phpを実行
設定を変更したら、Apacheの設定ファイルに構文エラーがないか確認します。
apachectl configtest
問題がなければApacheを再読み込みします。
sudo systemctl reload apache2
TCPでApacheとPHP-FPMを連携する方法
PHP-FPM側を設定する
TCPで通信する場合は、PHP-FPMのlistenを次のように設定します。
listen = 127.0.0.1:9000
同一サーバー内でApacheからのみ利用する場合は、外部ネットワークからアクセスできるアドレスではなく、127.0.0.1のようなループバックアドレスを利用する方法があります。
必要に応じて接続可能なクライアントも制限できます。
listen.allowed_clients = 127.0.0.1
Apache側を設定する
Apache側では次のように記述できます。
<FilesMatch "\.php$">
SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>
この設定では、PHPファイルへのリクエストを127.0.0.1:9000で待ち受けているPHP-FPMへ転送します。
処理の流れは次のようになります。
ブラウザ
↓
Apache
↓
127.0.0.1:9000
↓
PHP-FPM
↓
PHP実行
UnixソケットとTCPはどちらを選べばよいのか
同一サーバーならUnixソケットがよく使われる
ApacheとPHP-FPMが同じサーバーに存在する場合、Unixドメインソケットがよく利用されます。
たとえば次のような構成です。
Apache
↓
Unixソケット
↓
PHP-FPM
ただし、同一サーバーだから必ずUnixソケットを使わなければならないわけではありません。
同じサーバー上でも、
127.0.0.1:9000
を利用したTCP接続は可能です。
別サーバーならTCPを利用する
ApacheとPHP-FPMが異なるホストに存在する場合は、通常TCP通信が必要になります。
Apacheサーバー
↓
TCP/IP
↓
PHP-FPMサーバー
Dockerなどのコンテナ環境でも、コンテナ同士をTCPで接続する構成が利用される場合があります。
UnixソケットとTCPの違い
主な違いを整理すると次のようになります。
| 項目 | Unixソケット | TCP |
|---|---|---|
| 主な用途 | 同一ホスト | 同一ホストまたは別ホスト |
| 指定例 | /run/php/php-fpm.sock | 127.0.0.1:9000 |
| ネットワーク通信 | 不要 | 使用する |
| アクセス制御 | ファイル権限やACL | IPやネットワーク設定 |
| 別ホストへの接続 | 基本的に不可 | 可能 |
| コンテナ間通信 | 構成による | 利用しやすい |
サーバー構成に応じて適切な方法を選択します。
PHP-FPMのプロセス管理方式
PHP-FPMではpmによってプロセスの管理方式を指定できます。
主な方式は次の3種類です。
static
dynamic
ondemand
static
staticでは、基本的に固定数のPHPワーカープロセスを維持します。
たとえば、
pm = static
pm.max_children = 10
のように設定します。
常に一定数のPHPプロセスを起動しておきたい場合に利用できます。
dynamic
dynamicでは、アクセス状況などに応じてPHPワーカープロセス数を増減します。
たとえば次のように設定します。
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
dynamicでは次のような設定が重要になります。
pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
ondemand
ondemandでは、リクエストが発生したときにワーカープロセスを生成します。
一定時間使用されていないプロセスを終了させることもできます。
アクセスが少ない環境などで利用されることがあります。
pm.max_childrenとは
PHP-FPMの同時処理能力に関係する
pm.max_childrenはPHP-FPMの重要な設定項目です。
dynamicやondemandでは、生成できる子プロセス数の上限を指定します。
staticでは、子プロセス数そのものに関係します。
PHP-FPMの各ワーカーは基本的に1リクエストずつ処理するため、pm.max_childrenはPHP-FPMが同時処理できるリクエスト数にも大きく関係します。
値を大きくしすぎない
pm.max_childrenを増やせば、同時に処理できるPHPリクエスト数を増やせる可能性があります。
しかし、PHPワーカープロセスはそれぞれメモリを消費します。
そのため、
pm.max_childrenを増やす
↓
PHPワーカーが増える
↓
メモリ使用量が増える
という関係があります。
値が小さすぎるとアクセス集中時にリクエスト待ちが発生しやすくなります。
一方、値を大きくしすぎるとサーバーのメモリ不足を引き起こす可能性があります。
サーバーのメモリ容量やPHPアプリケーションのメモリ使用量を確認しながら調整することが重要です。
PHP-FPMのプールとは
サイトごとに設定を分けられる
PHP-FPMでは「プール」と呼ばれる単位で設定を分けられます。
たとえば、
example.com
↓
PHP-FPM pool A
shop.example.com
↓
PHP-FPM pool B
のような構成が可能です。
プールごとに、
user
group
listen
pm
pm.max_children
などを個別に設定できます。
たとえばサイトごとに別のUnixソケットを用意することもできます。
/run/php/example.sock
/run/php/shop.sock
Apache側でそれぞれ異なるPHP-FPMプールへ接続すれば、サイトごとにPHP実行環境を管理できます。
PHP-FPMプールは完全なセキュリティ分離ではない
PHP-FPMのプールを利用すると設定や実行ユーザーを分けられますが、完全なセキュリティ分離機構として考えるべきではありません。
プールを分けたからといって、仮想マシンやコンテナのようにすべてのリソースが完全に独立するわけではありません。
セキュリティ要件が高い環境では、OSユーザー、ファイル権限、コンテナ、仮想化なども含めて設計する必要があります。
ProxyPassMatchを使う方法もある
ApacheではFilesMatchとSetHandler以外に、ProxyPassMatchを利用してPHPリクエストをPHP-FPMへ転送する方法もあります。
たとえばTCP接続では、構成に応じて次のような設定が利用されることがあります。
ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/"
ただし、ProxyPassMatchではURLと実際のファイルパスとの対応を正しく設計する必要があります。
一般的なPHPサイトを初めて構築する場合は、
<FilesMatch "\.php$">
SetHandler ...
</FilesMatch>
の形から理解すると分かりやすいでしょう。
PHP-FPMが正常に動作しているか確認する方法
PHP-FPMサービスを確認する
最初にPHP-FPMサービスの状態を確認します。
systemctl status php8.x-fpm
実際のサービス名は使用している環境に合わせて変更します。
正常に起動していることを確認してください。
Unixソケットを確認する
Unixソケットを使用している場合は、実際にソケットが作成されているか確認します。
たとえば次のようにします。
ls -l /run/php/
次のようなソケットが存在しているか確認します。
php8.x-fpm.sock
Apacheの設定、
SetHandler "proxy:unix:/run/php/php8.x-fpm.sock|fcgi://localhost/"
と実際のソケットパスが一致していることが重要です。
PHPが正常に実行されるか確認する方法
phpinfo()を利用する
動作確認用として、一時的にPHPファイルを作成する方法があります。
<?php
phpinfo();
たとえばDocumentRootに、
/var/www/html/info.php
として保存します。
そのうえで、
https://example.com/info.php
へアクセスします。
PHP情報画面が表示されれば、
Apache
↓
mod_proxy_fcgi
↓
PHP-FPM
↓
PHP実行
という一連の処理が機能していると判断できます。
ただし、phpinfo()ではPHPのバージョンや設定、パス、モジュール、環境情報など多くの情報が表示されます。
本番環境では確認後に必ず削除するなど、公開したままにしないことが重要です。
503 Service Unavailableが表示される場合
PHP-FPMへの接続状態を確認する
ApacheとPHP-FPMの連携に問題がある場合、503エラーが発生することがあります。
ただし、503エラーが表示されたからといって、必ずPHP-FPMが停止しているとは限りません。
次のような原因が考えられます。
PHP-FPMが停止している
Unixソケットのパスが間違っている
ソケットのアクセス権限に問題がある
TCPポートへ接続できない
PHP-FPMがリクエストを処理できない
Apache側のFastCGI設定に問題がある
まずPHP-FPMの状態を確認します。
systemctl status php8.x-fpm
次にPHP-FPMのlistenとApache側の接続先を比較します。
PHP-FPM側が、
listen = /run/php/php8.x-fpm.sock
なら、Apache側も、
SetHandler "proxy:unix:/run/php/php8.x-fpm.sock|fcgi://localhost/"
のように同じソケットを指定する必要があります。
Permission deniedが表示される場合
Unixソケットの権限を確認する
Apacheのエラーログなどに、
Permission denied
が表示される場合、Unixソケットのアクセス権限に問題がある可能性があります。
PHP-FPM側の次の設定を確認します。
listen.owner
listen.group
listen.mode
例として、
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
などがあります。
ただし、使用するユーザー名やグループ名は環境によって異なります。
Apacheが実際にどのユーザー・グループで実行されているか確認し、PHP-FPMソケットへ接続できるように設定します。
Apacheのエラーログを確認する
ApacheとPHP-FPMのトラブルでは、ログの確認が非常に重要です。
Apacheのエラーログは環境によって異なりますが、たとえば次のような場所にあります。
/var/log/apache2/error.log
または、
/var/log/httpd/error_log
リアルタイムでログを確認する場合は、たとえば次のようにします。
tail -f /var/log/apache2/error.log
Apache側のログだけで原因が分からない場合は、PHP-FPM側のログも確認すると問題を切り分けやすくなります。
mod_proxy_fcgiの接続再利用について
enablereuse=onは慎重に使用する
Apacheのmod_proxy_fcgiでは、FastCGIバックエンドへの接続を再利用する設定があります。
代表的なのが、
enablereuse=on
です。
接続を再利用すると、新しいFastCGI接続を毎回確立するコストを抑えられる場合があります。
しかし、PHP-FPMとの組み合わせでは無条件に有効化すればよいわけではありません。
PHP-FPMのワーカー数とApache側の接続プール数のバランスが悪いと、持続接続によってPHP-FPMワーカーが占有される場合があります。
その結果、新しいPHPリクエストが処理を待つ状況につながる可能性があります。
そのため、
enablereuse=on
=必ず高速になる
と考えないことが重要です。
アクセス状況やPHP-FPMのpm.max_childrenなどを確認したうえで調整します。
TCPでPHP-FPMを公開するときの注意点
0.0.0.0:9000のような公開設定には注意する
PHP-FPMをTCPで動かす場合、セキュリティには十分注意する必要があります。
たとえば、
listen = 0.0.0.0:9000
とすると、ネットワーク構成によっては外部からPHP-FPMのFastCGIポートへ到達できる可能性があります。
PHP-FPMのFastCGIポートをインターネットへ不用意に公開する構成は避けるべきです。
同一サーバー内のApacheだけからアクセスする場合は、たとえば、
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
のように接続範囲を限定する方法があります。
別ホストからアクセスさせる場合でも、ファイアウォールやプライベートネットワークなどを利用して、必要なWebサーバーからのみ接続できるようにします。
ApacheとPHP-FPMの基本設定例
PHP-FPM側
同一サーバーでUnixソケットを利用する場合の一例です。
[www]
user = www-data
group = www-data
listen = /run/php/php-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
この設定値はあくまで例です。
www-dataなどのユーザー名、ソケットのパス、pm.max_childrenなどは実際のサーバー環境に合わせて設定してください。
Apache側
Apacheでは次のように設定できます。
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/example.com/public
<Directory /var/www/example.com/public>
Require all granted
AllowOverride All
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost/"
</FilesMatch>
</VirtualHost>
この場合のPHP実行の流れは次のようになります。
https://example.com/index.php
↓
Apache
↓
mod_proxy_fcgi
↓
/run/php/php-fpm.sock
↓
PHP-FPM
↓
index.php
↓
実行結果
↓
Apache
↓
ブラウザ
PHP-FPMとApacheを連携するときの確認ポイント
PHP-FPMとApacheが正常に連携しない場合は、次の項目を順番に確認すると原因を切り分けやすくなります。
Apacheのモジュールを確認する
次のモジュールが有効になっているか確認します。
mod_proxy
mod_proxy_fcgi
PHP-FPMが起動しているか確認する
PHP-FPMサービスの状態を確認します。
systemctl status php8.x-fpm
listenとApacheの接続先を確認する
PHP-FPM側が、
listen = /run/php/php-fpm.sock
ならApache側も同じソケットを指定します。
Unixソケットの権限を確認する
ApacheからPHP-FPMのUnixソケットへアクセスできる所有者・グループ・パーミッションになっているか確認します。
TCP接続なら待ち受けアドレスを確認する
PHP-FPMが、
listen = 127.0.0.1:9000
なら、Apache側も対応するIPアドレスとポートを指定します。
ApacheとPHP-FPMのログを確認する
503エラーやPermission deniedなどが発生した場合は、ブラウザに表示されたエラーだけで判断せず、ApacheとPHP-FPM双方のログを確認することが重要です。
PHP-FPMとApacheを連携するメリット
ApacheとPHPを別々に管理できる
PHP-FPMを利用すると、ApacheとPHPは別プロセスとして動作します。
そのため、
Apache側
→ HTTP処理やApacheワーカーを管理
PHP-FPM側
→ PHPワーカーやPHP設定を管理
という形で役割を分離できます。
ApacheとPHPの設定をそれぞれ独立して調整できる点は大きなメリットです。
サイトごとにPHP-FPMを設定できる
複数のPHP-FPMプールを利用すれば、サイトごとにPHPワーカー数やUnixソケット、実行ユーザーなどを分けることができます。
複数サイトを運用するサーバーでは便利な機能です。
PHPプロセス数を細かく調整できる
PHP-FPMではpm.max_childrenなどを利用し、PHPワーカープロセス数を調整できます。
アクセス量やメモリ使用量を監視しながら設定することで、サーバーリソースを効率的に利用できます。
PHP-FPMとApacheの連携方法まとめ
PHP-FPMとApacheを連携する場合、ApacheはWebサーバーとしてHTTPリクエストを受け付け、PHPの実行をFastCGI経由でPHP-FPMへ渡します。
Apache 2.4系では、主にmod_proxy_fcgiを利用してPHP-FPMへ接続できます。
同一サーバー上ではUnixドメインソケットがよく利用されますが、TCP通信を利用することも可能です。
基本的な構成は次のようになります。
ブラウザ
↓
Apache
↓
mod_proxy_fcgi
↓
UnixソケットまたはTCP
↓
PHP-FPM
↓
PHPスクリプト
設定するときに特に重要なのは、Apache側とPHP-FPM側の接続先を一致させることです。
Unixソケットを使う場合は、ソケットのパスだけでなくApacheからアクセスできる権限になっているかも確認します。
TCPを使う場合は、PHP-FPMのFastCGIポートをインターネットへ不用意に公開しないことも重要です。
また、PHP-FPMのpm.max_childrenなどは同時処理性能とメモリ使用量の両方に影響します。
単に値を大きくするのではなく、サーバーのメモリ容量やアクセス状況を確認しながら調整する必要があります。
PHP-FPMとApacheの連携で問題が起きた場合は、「Apacheのモジュール」「PHP-FPMの起動状態」「listenの設定」「Unixソケットの権限」「ApacheとPHP-FPMのログ」を順番に確認すると、原因を特定しやすくなります。
以上、PHP-FPMとApacheの連携方法についてでした。
最後までお読みいただき、ありがとうございました。










