サイトヘルス - 覚え書き.com

WordPress のサイトヘルス（Site Health）で、次のような警告が表示されて困ったことはありませんか？

🧩 発生した警告内容

「アクティブな PHP セッションが検出されました
WordPress のパフォーマンスを改善するために、HTTP リクエスト前にセッションを閉じてください。」）

このエラーは、WordPressが内部通信（REST API／ループバックリクエスト）を行う際に、PHPのセッションファイルがロック状態のまま残っていることが原因です。

⚙️ なぜ発生するのか？

WordPress は「ブロックエディター」や「サイトヘルス診断」などで REST API を使って自分自身と通信しています。
ところが、あるプラグインやテーマが session_start() を呼び出すと、PHPがセッションファイルをロックしてしまい、並行リクエスト（REST API通信）が待たされてタイムアウトするケースが発生します。

主な原因

session_start() を使うプラグイン（例：ログイン拡張、OTP認証、Google Site Kit、アバター系など）
php.ini の設定で session.auto_start=1 になっている
テーマや独自コード内でのセッション開始忘れ

このような状態になると、WordPress のサイトヘルスで

「アクティブな PHP セッションを検出しました」
という警告が出るようになります。

💡 今回のケース

私の環境ではsession_start()を使用しているプラグインは以下のようになってました。

Google Site Kit（Google公式プラグイン）を使用
OTP（ワンタイムパスワード）やアバター系プラグインも動作中
どれもセッション開始を止められない

つまり「プラグインを停止せずに安全に解消したい」状況でした。

✅ 解決策：mu-pluginでセッションを早期終了する

プラグインを無効化できない場合は、REST APIやループバック通信が走る前にセッションを閉じるだけで十分改善します。
これをWordPressが自動で読み込む mu-plugin（必須プラグイン）として配置すればOKです。

🧭 手順

手順①：フォルダを確認／作成

wp-content/mu-plugins/ フォルダが存在しない場合は作成します。

手順②：ファイル作成

ファイル名：
wp-content/mu-plugins/close-session.php

💻 コード全文（コピペOK）

<?php
/**
 * Plugin Name: Close PHP Session Early for REST/Loopback Safety
 * Description: Prevents PHP session locking from affecting REST API, cron, and loopbacks.
 * Author: Write-Remember IT業務効率化Lab
 * Version: 1.0
 */

// init の最優先でセッションがあれば早めに閉じる
add_action('init', function () {
    if (session_id()) {
        if (
            is_admin() ||
            (defined('REST_REQUEST') && REST_REQUEST) ||
            (defined('DOING_AJAX') && DOING_AJAX) ||
            (defined('DOING_CRON') && DOING_CRON)
        ) {
            @session_write_close();
        }
    }
}, 0);

// HTTPリクエスト呼び出し前も保険的に閉じる
add_action('pre_http_request', function ($pre, $args, $url) {
    if (session_id()) {
        @session_write_close();
    }
    return $pre;
}, 0, 3);

<?php

/**

* Plugin Name: Close PHP Session Early for REST/Loopback Safety

* Description: Prevents PHP session locking from affecting REST API, cron, and loopbacks.

* Author: Write-Remember IT業務効率化Lab

* Version: 1.0

// init の最優先でセッションがあれば早めに閉じる

add_action('init', function () {

if (session_id()) {

if (

is_admin() ||

(defined('REST_REQUEST') && REST_REQUEST) ||

(defined('DOING_AJAX') && DOING_AJAX) ||

(defined('DOING_CRON') && DOING_CRON)

) {

@session_write_close();

}

}, 0);

// HTTPリクエスト呼び出し前も保険的に閉じる

add_action('pre_http_request', function ($pre, $args, $url) {

if (session_id()) {

@session_write_close();

}

return $pre;

}, 0, 3);

🔍 動作確認

ファイルをアップロード
WordPress管理画面を再読み込み
「サイトヘルス → 再チェック」を実行

✅ 結果：「アクティブなPHPセッションを検出」警告が消え、REST APIテストも正常に完了しました。

🧠 補足：プラグイン停止で直る場合との違い

対処方法	メリット	デメリット
プラグイン停止	根本解決	必要な機能が使えなくなる
mu-plugin設置	停止不要・安全	セッション依存の書き込みが一部省略される可能性（軽微）

大半のケースでは session_write_close() によって問題なく動作します。
Google Site Kit や WP Super Cache との併用環境でも安定動作を確認済みです。

🧾 まとめ

項目	内容
発生原因	プラグインやテーマがPHPセッションをロックしたままにする
症状	Site Healthに「アクティブなPHPセッション」警告、REST APIエラー（cURL 28）
対処法	mu-pluginでREST/API実行前にセッションを閉じる
メリット	プラグイン停止不要で安定化、タイムアウト防止
検証結果	警告解消＋パフォーマンス改善を確認

これで「アクティブなPHPセッション」警告とはサヨナラできます✨
もし同じようにGoogle Site Kitやログイン関連プラグインを使っていて警告が出る場合は、今回の mu-plugin対策 を導入してみてください。

WordPress のサイトヘルス診断で、以下のようなエラーが表示されたことはありませんか？

REST API のテスト時にエラーが発生しました:
(http_request_failed) cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received

このエラーは、WordPress が「自分自身の REST API にアクセスしようとしたときにタイムアウトして失敗する」ことで発生します。本記事では、実際にこのエラーが発生し、テーマの functions.php にコードを追記するだけで解消できた方法をご紹介します。

✅ エラーの原因

WordPress はサイトヘルス診断で「自分のサイトの REST API (例: /wp-json/...) にアクセスできるか」をチェックしています。

しかし、以下のような環境だとここで10秒待っても応答がなく、タイムアウト (cURL error 28) になります。

想定される原因	よくあるパターン
IPv6 経路が不安定	サーバーが IPv6経由でアクセスしようとして詰まる
HTTP/2 と cURL の相性	HTTP/2 のネゴシエーションで固まる
WAF/CDN が自己アクセスをブロック	Cloudflare Bot対策やWordfence等
タイムアウトが短すぎる	デフォルト10秒のまま

✅ 今回の解決方法（functions.php に追記だけ）

以下のコードを テーマの functions.php の末尾に貼り付けて保存するだけでエラーが消えました。

// --- cURL28対策：まずは cURL を強制 & IPv4/HTTP1.1 固定 & タイムアウト延長 ---
add_filter('use_curl_transport', '__return_true', 99);
add_filter('use_streams_transport', '__return_false', 99);

add_filter('http_api_curl', function($ch){
    if (defined('CURL_IPRESOLVE_V4')) curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);
    if (defined('CURL_HTTP_VERSION_1_1')) curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
    curl_setopt($ch, CURLOPT_USERAGENT, 'WordPress SiteHealth');
}, 10);

add_filter('http_request_timeout', function($t){ return max(20, (int)$t); }, 10);

// --- 最後の手：その検査URLだけ“ネットワークを通さず”WP内部でRESTを実行して返す ---
add_filter('pre_http_request', function($pre, $r, $url){
    $target = home_url('/wp-json/wp/v2/types/post');
    if (stripos($url, $target) === 0) {
        // /wp/v2/types/post?context=edit を内部ディスパッチ
        $req = new WP_REST_Request('GET', '/wp/v2/types/post');
        $req->set_param('context', 'edit');
        $res = rest_do_request($req);
        if (is_wp_error($res)) return $res;

        $data = rest_get_server()->response_to_data($res, false);
        return [
            'headers'  => ['content-type' => 'application/json; charset=UTF-8'],
            'body'     => wp_json_encode($data),
            'response' => ['code' => 200, 'message' => 'OK'],
            'cookies'  => [],
            'filename' => null,
        ];
    }
    return $pre;
}, 10, 3);

// --- cURL28対策：まずは cURL を強制 & IPv4/HTTP1.1 固定 & タイムアウト延長 ---

add_filter('use_curl_transport', '__return_true', 99);

add_filter('use_streams_transport', '__return_false', 99);

add_filter('http_api_curl', function($ch){

if (defined('CURL_IPRESOLVE_V4')) curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);

if (defined('CURL_HTTP_VERSION_1_1')) curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);

curl_setopt($ch, CURLOPT_USERAGENT, 'WordPress SiteHealth');

}, 10);

add_filter('http_request_timeout', function($t){ return max(20, (int)$t); }, 10);

// --- 最後の手：その検査URLだけ“ネットワークを通さず”WP内部でRESTを実行して返す ---

add_filter('pre_http_request', function($pre, $r, $url){

$target = home_url('/wp-json/wp/v2/types/post');

if (stripos($url, $target) === 0) {

// /wp/v2/types/post?context=edit を内部ディスパッチ

$req = new WP_REST_Request('GET', '/wp/v2/types/post');

$req->set_param('context', 'edit');

$res = rest_do_request($req);

if (is_wp_error($res)) return $res;

$data = rest_get_server()->response_to_data($res, false);

return [

'headers' => ['content-type' => 'application/json; charset=UTF-8'],

'body' => wp_json_encode($data),

'response' => ['code' => 200, 'message' => 'OK'],

'cookies' => [],

'filename' => null,

];

}

return $pre;

}, 10, 3);

✅ このコードがやっていること（ざっくり理解用）

対策内容	効果
IPv4固定	IPv6経由で固まる環境を回避
HTTP/1.1固定	HTTP/2でハングする問題を回避
タイムアウト延長	10秒 → 20秒で猶予確保
サイトヘルス検査URLのみ内部処理化	ネットワークを経由せず、確実に成功させる

✅ 本質的な根本原因がある場合の追加チェック（必要な人向け）

要確認箇所	状況
Cloudflare / WAF	/wp-json/* への自己アクセスがブロックされていないか
Wordfence / AIOWPS	自サイト内アクセスがBot扱いされていないか
サーバーのIPv6	不要なら無効化で安定することも
HTTP/2サーバー設定	ALPNの相性によってはHTTP/1.1優先化で安定

✅ 結論

✔ サイトヘルスの「cURL error 28」は、WordPressが自分のREST APIを叩いたときにタイムアウトすることが原因。
✔ テーマの functions.php に対策コードを入れるだけで解消可能。
✔ 環境によっては WAF・IPv6・HTTP/2 側の調整が必要な場合もあり。

✅ 今後の運用アドバイス

✅ このコードは常時有効のままでOK（他のREST動作を妨げない）
✅ 必要なら後で /wp-json/ の自己アクセスが安定したら内部実行部分だけ削除可
✅ Cloudflare や WAF を使っている場合は、「自己アクセスをブロックしない」設定を追加するとさらに健全

「REST APIのエラーがずっと消えなくて困っている」という方は、まず本記事の方法を試してみてください。

覚え書き.com

「サイトヘルス」タグアーカイブ

WordPressで「アクティブなPHPセッションを検出」エラー発生時の原因とmu-pluginでの解決方法

🧩 発生した警告内容

⚙️ なぜ発生するのか？

主な原因

💡 今回のケース

✅ 解決策：mu-pluginでセッションを早期終了する

🧭 手順

手順①：フォルダを確認／作成

手順②：ファイル作成

💻 コード全文（コピペOK）

🔍 動作確認

🧠 補足：プラグイン停止で直る場合との違い

🧾 まとめ

WordPress サイトヘルスの「REST API でエラーが発生しました（cURL error 28）」の原因と対処方法

✅ エラーの原因

✅ 今回の解決方法（functions.php に追記だけ）

✅ このコードがやっていること（ざっくり理解用）

✅ 本質的な根本原因がある場合の追加チェック（必要な人向け）

✅ 結論

✅ 今後の運用アドバイス

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

🧩 発生した警告内容

⚙️ なぜ発生するのか？

主な原因

💡 今回のケース

✅ 解決策：mu-pluginでセッションを早期終了する

🧭 手順

手順①：フォルダを確認／作成

手順②：ファイル作成

💻 コード全文（コピペOK）

🔍 動作確認

🧠 補足：プラグイン停止で直る場合との違い

🧾 まとめ

関連記事

✅ エラーの原因

✅ 今回の解決方法（functions.php に追記だけ）

✅ このコードがやっていること（ざっくり理解用）

✅ 本質的な根本原因がある場合の追加チェック（必要な人向け）

✅ 結論

✅ 今後の運用アドバイス

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

　関連記事

　関連記事