PixelYourSite が Nginx FastCGI キャッシュを無効化する問題の直し方
PixelYourSite を有効にしたとたん Nginx FastCGI キャッシュがまったく効かなくなり、PHP の負荷が急増して 504 Gateway Timeout が頻発するなら、プラグインの「PHP セッションを無効にする」設定をオンにするだけで解決できる。
この問題は、PixelYourSite が訪問者のトラフィック情報を一時保存するために PHP セッションを開始することで発生する。セッション開始時に送信される Cookie（PHPSESSID）とキャッシュを禁止するヘッダー（Cache-Control: no-store など）が Nginx の FastCGI キャッシュを素通りさせ、毎回バックエンドの PHP が起きてしまうのが根本原因だ。
なぜ PixelYourSite が FastCGI キャッシュを無効化するのか
PixelYourSite には、ランディングページの URL やトラフィックソース、UTM パラメータなどをセッション変数に保持する仕組みがある。この処理は includes/class-pys.php 内の controllSessionStart() メソッドで行われ、まだセッションが始まっていなければ session_start() を呼び出す。サーバー側の PHP 設定で session.cache_limiter が nocache に設定されていると、この瞬間に以下の HTTP レスポンスヘッダーが自動的に追加されてしまう。
Set-Cookie: PHPSESSID=...Cache-Control: no-store, no-cache, must-revalidatePragma: no-cache
Nginx FastCGI キャッシュは、これらのヘッダーがついたレスポンスをキャッシュしない。結果として、匿名の一般訪問者に対しても毎回 PHP が実行され、PHP-FPM ワーカーが占有され続ける。アクセスが集中するとすべてのワーカーがビジーになり、レスポンスを返せず 504 エラーに至る。
✗ Cache-Control: no-store, no-cache, must-revalidate
✗ Pragma: no-cache
✗ X-FastCGI-Cache: MISS
✓ （Set-Cookie やキャッシュ禁止ヘッダーは付かない）
上記の通り、問題の本質はセッションに伴うキャッシュ抑制ヘッダーにある。幸い PixelYourSite には、この PHP セッション機能をまるごとオフにする設定が用意されている。
設定変更で PHP セッションを無効化する手順
PixelYourSite のグローバル設定画面から 1 か所切り替えるだけで、セッションに依存しない動作に切り替えられる。手順はどこのサーバーでも共通だ。
「Disable PHP Sessions」の場所と見つけ方
この設定項目は、PixelYourSite のバージョンによっては「PHP Sessions」というセクションに含まれている。「Global Settings」タブを開き、下にスクロールしていくと「Track UTMs」「Track Traffic Source」といった項目の近くに配置されていることが多い。チェックボックスにチェックを入れると、即座に session_start() が呼ばれなくなる。
設定保存後に必ずキャッシュをクリアする
変更を保存したあとは、WordPress のキャッシュプラグイン（WP Rocket など）と Nginx FastCGI キャッシュの両方を必ずクリアする。さもないと、以前のセッション付きレスポンスがキャッシュされたまま残ってしまう。一般的な手順は次のとおりだ。
- WP Rocket の「キャッシュをクリア」を実行する
- サーバーのシェルから
nginx -s reloadまたはキャッシュディレクトリの削除を行う（環境に応じて） - Cloudflare を利用している場合は、Cloudflare 側のキャッシュもパージする
設定変更後の影響とデータ精度について
PHP セッションを無効にすると、ランディングページ、トラフィックソース、UTM パラメータといった情報の受け渡し方法が、サーバーサイドのセッションからブラウザの Cookie へと切り替わる。プラグインはこれらの値を Cookie に保存し、それを読み取って各ピクセルに渡す形になる。そのため、トラッキング自体は継続して機能する。
精度の面で多少の劣化が生じる可能性はあるものの、PixelYourSite の開発チームは「精度の低下は最小限」としている。実際、セッションに頼らなくても、Cookie を正しく読み取れればデータ取得に大きな支障は出ない。EC サイトで大量のアクセスをさばく場合、キャッシュが効かないことによるサーバーダウンのリスクと比較すれば、この切り替えのデメリットはほとんど無視できるレベルだ。
PHP セッション無効化後も問題が続く場合の追加チェック
設定を変更してもキャッシュが MISS のままだったり、PHP ワーカーの高負荷が解消されない場合は、以下のポイントを順に確認する。
キャッシュ除外設定の見直し
Nginx の設定で、特定の Cookie が存在するとキャッシュをバイパスするルールが書かれていないか確認する。たとえば wp- や wordpress_logged_in といった Cookie は除外対象になるが、PHPSESSID が消えたことで意図しないキャッシュ ON が起きていないかもあわせてチェックする。
他のプラグインがセッションを開始していないか調べる
PixelYourSite だけを無効化したときに問題が消えたとしても、同様にセッションを使う別のプラグインが有効になっていないか切り分ける。WooCommerce のカートなどはログインユーザー向けにセッションを使うが、匿名訪問者にまでセッションを開始するプラグインは稀だ。すべてのプラグインを一時停止し、1 つずつ有効にして原因を特定するとよい。
よくある質問
「Disable PHP Sessions」を有効にしてもトラッキングは引き続き動作するか
動作する。セッションの代わりにブラウザの Cookie を使ってランディングページや UTM パラメータを保持するため、Facebook ピクセルや Google アナリティクスへのデータ送信は継続される。
Nginx FastCGI キャッシュ以外のキャッシュ（Varnish や CDN）でも効果はあるか
非常に効果が高い。Cache-Control: no-store や Set-Cookie ヘッダーは、Varnish をはじめとするほとんどの HTTP キャッシュ層で「キャッシュしてはいけないレスポンス」と判定される。PHP セッションを止めるだけで、あらゆるキャッシュ層が正常に機能し始める。
この設定はサイトの表示速度にどれくらい影響するのか
キャッシュが有効になると、PHP の処理を経由せず Nginx が直接静的 HTML を返すため、TTFB（最初の 1 バイトが届くまでの時間）が劇的に短縮される。同時にサーバーの CPU 使用率も下がるため、アクセス集中時のタイムアウトも防ぎやすくなる。
PixelYourSite を最新版にアップデートしてもセッション問題は解決されないのか
2026 年 8 月時点のバージョンでは、PHP セッションを利用する設計が残っている。今後アップデートで標準動作が変わる可能性はあるが、現状はユーザーが手動で「Disable PHP Sessions」をオンにする必要がある。
この記事のポイント
- PixelYourSite が PHP セッションを開始するため、Nginx FastCGI キャッシュが無効化される
- 「Disable PHP Sessions」をオンにするだけでキャッシュが正常に機能するようになる
- 設定後は必ず Nginx と WordPress のキャッシュをクリアする
- トラッキングは Cookie ベースに切り替わり、精度への影響はごくわずか
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている