ConoHa WINGキャッシュで更新が反映されない｜滞留61〜63秒を実測

本記事には広告（PR・アフィリエイトリンク）が含まれています。
※本記事にはConoHa WINGの紹介リンク（もしもアフィリエイト経由）を掲載しています。このリンクから申し込みが成立した場合、当サイトに紹介報酬が支払われます。また筆者は本サービスの契約にあたりASPのセルフバック（自己アフィリエイト）制度を利用しています。いずれの事実も測定結果や記述には反映していません。

著者: 佐藤優太（Web制作事業 MOVON 代表） ｜公開日: 2026-08-16 ｜最終更新日: 2026-08-17
この記事は筆者が実際に契約・操作して計測した結果に基づいています。計測条件・計測日・証跡は本文中に明記しています。
本サイトの編集方針: 運営者情報

結論（先に答え）
ConoHa WINGで更新が反映されないとき、まず疑うもの
この記事で測ったもの／測っていないもの
ターミナルを使わない、いちばん短い確認
ヘッダまで見る：x-nginx-cache を1行で取る
1. 観測できた3つの値
連続2回アクセスすると、ページ種別で挙動が違った
キャッシュを経由しない応答を取る：?cb= を付ける
更新しなければ、キャッシュは61〜63秒残った（6ラウンドの実測）
なぜ「更新してから反映されるまで」を測らなかったのか
追記：ConoHa WINGの自動キャッシュクリアは必要か（2026-08-17に測りました）
どうやって測ったか（再現手順）
1. 測定条件
2. 手順
ConoHa WINGで反映されないときの切り分け手順
この記事の限界（正直に書いておきます）
よくある質問
ConoHa WINGについて当サイトが測った他の記録
この記事で使ったサービスについて

結論（先に答え）

ConoHa WING（WINGパックベーシック／12ヶ月契約）に置いた自分のサイトに、ログインしていない状態でHTTPリクエストを投げると、レスポンスヘッダに x-nginx-cache が返ってきました。いま見えている画面がキャッシュから返っているかどうかを、管理画面に入らずに判別する手がかりになります【実測: n=1, 2026-08-16, 匿名HTTP（curl）で取得したレスポンスヘッダ】
ただし各値の意味をConoHa公式のドキュメントで確認しておらず、トップページのように HIT をまったく観測できない場合もありました。万能の判定材料ではありません【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】
同じ日のうちに観測できた値は MISS・HIT・EXPIRED の3種でした【実測: n=1, 2026-08-16, 匿名HTTPのレスポンスヘッダ】
同じURLに連続2回アクセスすると、記事ページと固定ページ /about/ では 1回目 EXPIRED → 2回目 HIT に変わりました。2回目はキャッシュから返っている、と読めます【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】
URLの末尾に ?cb=<エポック秒> を付けて一意なURLにすると、3回とも MISS が返りました。キャッシュを経由しない応答を取り出す手段になります（今回取得したのは応答ヘッダのみで、本文HTMLは取得していません）【実測: n=3, 2026-08-16, 匿名HTTPでキャッシュバスター付きURLの応答ヘッダを取得】
コンテンツを一切更新しない状態で、公開済みの記事ページ1本のキャッシュが切り替わるまでの時間を6ラウンド測ったところ、実測順に ポーリング間隔5秒で 63・62・62秒／ポーリング間隔1秒で 62・61・62秒（最小61秒／最大63秒）でした【実測: n=6, 2026-08-16, 匿名HTTPポーリング・コンテンツ更新なし・対象は記事ページ1本】
この 61〜63秒は「更新しなかった場合にキャッシュが何秒残るか」であって、「設定やコンテンツを更新してから画面に反映されるまでの秒数」ではありません。また6回とも61〜63秒に収まりましたが、サーバー側の内部設定値は確認していないため「ConoHa WINGのキャッシュ保持時間は◯秒です」とは書けません【実測: n=6, 2026-08-16, コンテンツを更新しない条件での測定】
【2026-08-17 追記】更新してから反映されるまでも、測定専用のページを作って測りました。3回とも 56.61秒・59.67秒・60.08秒で、上の滞留時間と同じ帯でした【実測: n=3, 2026-08-17, 測定専用ページへの匿名HTTPポーリング】
【2026-08-17 追記】ConoHa WINGの「自動キャッシュクリア」プラグインは、公開済みのものを更新したときには動きません。 動作のきっかけとして登録されている6件がすべて「公開へ状態が変わったとき」だったためで、停止した状態で測っても反映までの秒数はほとんど変わりませんでした【実測: n=1, 2026-08-17, wp-adminのプラグインエディターで表示したプラグイン本体のソース】【実測: n=3, 2026-08-17, プラグイン有効・停止の両条件での匿名HTTPポーリング】

この記事で実測したサービス（当サイトの紹介リンク）

▶ ConoHa WING 公式サイトを見る　（本記事の測定はWINGパック12ヶ月・ベーシックの契約で行っています）

ConoHa WINGで更新が反映されないとき、まず疑うもの

WordPressを触っていて、いちばん気持ちが悪いのがこれです。

設定を変えて保存したのに、サイトを開くと古いままに見える。

パーマリンクの形式を変えた、テーマの設定を変えた、記事を直した。管理画面では確かに変わっている。でも公開側を開くと前のまま。このとき人は、だいたい次の3つを同時に疑って混乱します。

そもそも設定が保存できていないのではないか
ブラウザが古いページを覚えているのではないか
サーバー側が古いページを配っているのではないか

この3つを切り分けないまま、設定を何度も保存し直したり、プラグインを入れ直したりするのがいちばん危険です。 直っていないのではなく、直っているのに見えていないだけ、ということが実際にあるからです。

筆者自身、このサイトを構築している最中に同じことに遭遇しました。パーマリンクの形式を変えた直後、トップページの記事リンクが旧形式（?p= の形）のまま表示されているように見えたのに、URLにクエリ文字列を付けて開き直すと新形式で返ってきた、という出来事です。つまり設定は反映済みで、見えていた古い表示のほうが古い中身だった、ということになります。ただしこの出来事はタイムスタンプを取りながら計測したものではなく、本記事の測定とは別の、運用中に記録として残っている体験談です。数値としては扱いません。

そこで今回、「サーバー側が古いページを配っている状態」を外から観測できるかを、管理画面に一切ログインせずに測りました。

この記事で測ったもの／測っていないもの

先に線を引いておきます。

対象	本記事での扱い
レスポンスヘッダ `x-nginx-cache` が存在するか	測った（存在した／n=1）
そのヘッダが返す値の種類	測った（`MISS`・`HIT`・`EXPIRED` の3種を観測／n=1）
キャッシュバスター付きURLの応答ヘッダ	測った（3回とも `MISS`／n=3）
`?cb=` 付きURLが返す本文（HTML）の中身	測っていない（今回取得したのはレスポンスヘッダのみ）
更新しない状態でキャッシュが残る時間	測った（記事ページ1本で6ラウンド／n=6）
トップページ・固定ページでキャッシュが残る時間	測っていない（滞留時間の測定は記事ページ1本のみ）
コンテンツを更新してから反映されるまでの時間	測っていない
コントロールパネルからキャッシュを消す機能	確認していない（機能があるかどうかも含めて未確認。管理画面へのログイン操作を伴うため）
ConoHa公式が公表しているキャッシュ保持時間	確認していない（公式ドキュメントを今回探していない）
ブラウザ側のキャッシュの挙動	測っていない（測定は `curl` で行っており、ブラウザを使っていない）

【実測: n=6／n=3／n=1, 2026-08-16, 項目により測定回数が異なる（滞留時間 n=6・キャッシュバスター n=3・ヘッダ挙動 n=1）。いずれも匿名HTTP（curl）・ログイン操作なし】

「測っていない」「確認していない」と書いた行は、この記事のどこにも数値が出てきません。そこは他の情報源で確かめてください。

ターミナルを使わない、いちばん短い確認

まずターミナルを開かずにできる確認から書きます。ここまでで解決することが少なくありません。

ブラウザのアドレスバーで、確認したいページのURLの末尾に ?cb=1 を付けて開いてください。

https://自分のドメイン/?cb=1

?cb= の後ろの値は、前回と重複しなければ何でも構いません。 次は ?cb=2、その次は ?cb=3 のように手で変えても同じです。これで「まだ誰もアクセスしたことのない別のURL」になります。

実測では、この形のURLは3回とも MISS（キャッシュに当たらなかったことを示す値）を返しました【実測: n=3, 2026-08-16, 匿名HTTPでキャッシュバスター付きURLの応答ヘッダを取得】。

ここで新しい内容が表示されるなら、サーバー側では設定・コンテンツが反映済みで、通常のURLで見えていた古い画面のほうがキャッシュだった、という方向で考えられます。古い内容のままなら、キャッシュではなく設定そのものを疑う番です。

ただし正直に書いておきます。今回の測定で取得したのはレスポンスヘッダだけで、?cb= 付きURLが返す本文（HTML）の中身は取得していません。 上の読み方はヘッダの観測（3回とも MISS）からの解釈であって、本文を突き合わせて確かめたものではありません。ブラウザの開発者ツールで同じヘッダが見えるかどうかも確認していません（本測定は curl のみで行っています）。

ヘッダまで見る：x-nginx-cache を1行で取る

もう一歩踏み込んで、サーバーがキャッシュをどう扱っているかを見ます。

レスポンスヘッダとは、Webサーバーがページ本文と一緒に返してくる付帯情報のことです。ブラウザの画面には表示されませんが、curl を使えば読めます。

以下は macOS / Linux のターミナルで実行する形です。Windowsのコマンドプロンプトやパワーシェルでは grep が標準では使えません。 その場合は curl -sSI <URL> だけを実行して、出力の中から x-nginx-cache の行を目で探してください。

curl -sSI https://自分のドメイン/ | grep -i x-nginx-cache

-I はヘッダだけを取るオプション、grep -i は大文字小文字を無視して該当行だけを抜き出すものです。ブラウザではなく curl を使うのがポイントで、ブラウザのキャッシュや拡張機能の影響を最初から排除できます。

筆者のサイト（kensho-lab.com）で実際に返ってきたヘッダは、たとえばこういう形でした【実測: n=1, 2026-08-16, 匿名HTTPで取得したレスポンスヘッダ】。

HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8
x-nginx-cache: EXPIRED

（抜粋です。実際には server と content-type の間に date、content-type と x-nginx-cache の間に link とセキュリティ関連の2行が入っています）

最終行の x-nginx-cache が、今回の主役です。

観測できた3つの値

同じ日のうちに、次の3つの値を観測しました。

値	どの場面で観測したか	出典
`MISS`	`?cb=<エポック秒>` を付けた一意なURLへのアクセス（3回とも）	【実測: n=3, 2026-08-16, 匿名HTTP】
`HIT`	記事ページ・固定ページ `/about/` への連続2回アクセスの2回目	【実測: n=1, 2026-08-16, 匿名HTTP】
`EXPIRED`	上記の1回目、およびトップページへの連続2回アクセスの両方	【実測: n=1, 2026-08-16, 匿名HTTP】

ここで正直に書いておきます。この3つの値をConoHa WINGがどう定義しているかは、公式ドキュメントで確認していません。 一般的なnginxのキャッシュ状態表記と同じ語ではありますが、本記事で言えるのは「この条件でこの値が返ってきた」という観測結果までです。値の意味を断定はしません。

観測結果から読み取れることだけを書くと、次のようになります。

?cb= を付けた一意なURL（＝まだ誰もアクセスしていないURL）では、3回とも MISS が返った
同じURLを続けて叩くと、記事ページと固定ページでは2回目が HIT に変わった

この2点から、HIT が返っている間はキャッシュから配られていると扱って切り分けを進めるのが実用的です。ただしこれは観測からの解釈であって、サーバー内部の動作を確認したものではありません。

連続2回アクセスすると、ページ種別で挙動が違った

同じURLに、間を空けずに2回投げた結果です。

対象	1回目	2回目	出典
トップページ	`EXPIRED`	`EXPIRED`	【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】
記事ページ	`EXPIRED`	`HIT`	【実測: n=1, 2026-08-16, 同上】
固定ページ `/about/`	`EXPIRED`	`HIT`	【実測: n=1, 2026-08-16, 同上】

記事ページと固定ページは想定どおりでした。1回目でキャッシュが作り直され、2回目はそこから返っている、と読めます。

引っかかったのはトップページです。 連続2回とも EXPIRED で、HIT を観測できませんでした。原因は特定できていません。 ページ種別によって扱いが違う可能性も、たまたまタイミングが重なった可能性も、どちらも否定できません。この1点だけは「トップページでは HIT が出ないことがある」という観測事実にとどめます。

実務上の意味は1つあります。切り分けをするときは、トップページだけで判断しないほうがいい、ということです。個別記事や固定ページでも同じ確認をしてください。

キャッシュを経由しない応答を取る：?cb= を付ける

ターミナルから同じことをする場合は、クエリ文字列を1つ足すだけです。

curl -sSI "https://自分のドメイン/?cb=$(date +%s)" | grep -i x-nginx-cache

$(date +%s) はエポック秒（実行するたびに変わる数字）です。この書き方は macOS / Linux 向けなので、他の環境では ?cb=1、?cb=2 のように重複しない値を手で入れてください。 値が毎回違えばよく、エポック秒である必要はありません。

これを付けたURLは毎回別のURLになるため、既存のキャッシュには当たらないと考えられます。 ただしサーバー側がクエリ文字列をキャッシュの識別にどう使っているかは確認していません。実際に3回試して、3回とも MISS が返りました【実測: n=3, 2026-08-16, 匿名HTTPでキャッシュバスター付きURLの応答ヘッダを取得】。

?cb= 付きの応答が新しいか古いかで次にやることが変わります。その分岐は後述の「切り分け手順」にまとめました。

なお、?cb= を付けたURLはキャッシュを持たないため、毎回サーバーに処理させることになります。確認のために数回叩くのは問題ありませんが、繰り返し大量に叩く使い方はしないでください。

更新しなければ、キャッシュは61〜63秒残った（6ラウンドの実測）

ここからが、この記事の一次情報です。

コンテンツを1文字も更新しない状態で、公開済みの記事ページ1本に対して同じURLを叩き続けました。x-nginx-cache が MISS または EXPIRED を返した瞬間を起点として、同じURLが再び MISS または EXPIRED を返すまでの秒数（＝キャッシュ1周期）を測っています。その間は HIT が返り続けます。1ラウンドごとに間隔を空けて、計6ラウンドです【実測: n=6, 2026-08-16, 匿名HTTPによるポーリング測定・コンテンツ更新なし・対象は記事ページ1本】。

今回の6ラウンドでは、起点も終点もすべて EXPIRED として観測されました。 滞留時間の測定中に MISS は一度も出ていません（MISS が返ったのは ?cb= 付きURLだけです）【実測: n=6, 2026-08-16, ポーリングスクリプトの出力】。

ラウンド（実測順）	ポーリング間隔	測定値	出典
5秒間隔 1回目	5秒	63秒	【実測: n=1, 2026-08-16, ポーリングスクリプトの経過秒】
5秒間隔 2回目	5秒	62秒	【実測: n=1, 2026-08-16, 同上】
5秒間隔 3回目	5秒	62秒	【実測: n=1, 2026-08-16, 同上】
1秒間隔 1回目	1秒	62秒	【実測: n=1, 2026-08-16, 同上】
1秒間隔 2回目	1秒	61秒	【実測: n=1, 2026-08-16, 同上】
1秒間隔 3回目	1秒	62秒	【実測: n=1, 2026-08-16, 同上】
最小	—	61秒	【実測: n=6, 2026-08-16, 上記6ラウンドのうち最小】
最大	—	63秒	【実測: n=6, 2026-08-16, 上記6ラウンドのうち最大】

この測定の誤差は、片側にしか出ません。 切り替わりは必ず「直前のポーリング（HIT）」と「切り替わりを検出したポーリング」の間で起きているため、真値は測定値以下であり、測定値より長くなることはありません。5秒間隔の測定では実際のポーリング間隔が最大6秒開いていた箇所があるので、真値は最大6秒だけ短い側にずれ得ます。1秒間隔の測定は各ポーリング行を証跡に残していないため、実際の間隔のばらつきは確認していません【実測: n=6, 2026-08-16, ポーリングスクリプトの出力】。

ポーリング間隔を5秒と1秒の2条件に分けたのには理由があります。 粗い間隔でしか測っていないと、「たまたまその粒度で見えた数字」なのか「本当にその値なのか」が区別できません。分解能を5倍に上げても61〜63秒の範囲に収まったので、測定の粒度が作り出した数字ではないと言えます【実測: n=6, 2026-08-16, ポーリング間隔5秒3ラウンドと1秒3ラウンドの比較】。

そのうえで、書けないことをはっきりさせます。

6回すべてが61〜63秒に収まったからといって、「サーバー内部のキャッシュ保持時間が60秒に設定されている」とは書けません。設定値そのものを見ていないからです。実測値からの推定であって、確認ではありません。そしてこの61〜63秒は「更新しなかった場合にキャッシュが何秒残るか」であって、「更新してから反映されるまでの秒数」ではありません。後者を測らなかった理由は次の節に書きます【実測: n=6, 2026-08-16, コンテンツを更新しない条件での測定】。

なぜ「更新してから反映されるまで」を測らなかったのか

読者が本当に知りたいのは、おそらく「設定を変えてから、実際に画面に反映されるまで何秒待てばいいのか」のほうだと思います。それを測らなかった理由は2つあります。

1つ目。このサイトには、コンテンツを更新したときにキャッシュを自動で消すプラグインが入っています。 ConoHaのコントロールパネルからWordPressを導入した際に、併せてインストールされたものです。他の導入経路でも同じ状態になるのか、これがConoHa WINGの標準構成なのかは確認していません。 更新を伴う測定をすると、このプラグインが発火する前提になり、測っている対象が「キャッシュの寿命」から「プラグインの動作」に変わってしまいます。なおプラグインの発火条件そのものを確認していないため、実際にどの操作で発火するかも本記事では確かめていません。 今回は更新を一切行わないことで、測る対象を固定しました。

2つ目。測定のために公開中の記事を書き換えることを、筆者のルールとして禁止しています。 読者が読んでいる記事を実験台にしないためです。測定専用の固定ページを用意すれば測れますが、その準備が今回は間に合いませんでした。

→ この2つは、公開の翌日（2026-08-17）に測定専用のページと投稿を作って解消しました。結果は次の節に書きます。

追記：ConoHa WINGの自動キャッシュクリアは必要か（2026-08-17に測りました）

先に結論です。このプラグインが動くのは「記事を新しく公開したとき」だけで、すでに公開してある記事やページを更新したときには、設計上そもそも呼ばれません。つまり「更新したのに反映されない」と困っている、まさにその場面では、入っていても入っていなくても結果は変わりません。

測定専用の固定ページと投稿を1つずつ作り、本文の目印を書き換えてから、それが実際に外から見えるようになるまでの秒数を測りました。プラグインを有効にした状態と、停止した状態の両方で測っています。

何を更新したか	プラグイン	新しい内容が返るまで
公開済みの固定ページ	有効	56.61秒
公開済みの固定ページ	停止	59.67秒
公開済みの投稿	有効	60.08秒
出典		【実測: n=3, 2026-08-17, 測定専用ページへの匿名HTTPポーリング（0.5秒間隔）】

プラグインを止めても、秒数はほとんど変わりませんでした。 どの回も、新しい内容が現れた瞬間の x-nginx-cache は EXPIRED です。キャッシュが「消された」のではなく、寿命が来て入れ替わったという形でした。この3つの値は、更新しない条件で測った滞留61〜63秒と同じ帯に収まっています【実測: n=3, 2026-08-17, 測定専用ページへの匿名HTTPポーリング】【実測: n=6, 2026-08-16, コンテンツを更新しない条件での測定】。

理由はプラグイン本体を読むと分かりました。管理画面のプラグインエディターで開くと、全体で960文字の短いファイルで、動作のきっかけとして登録されているのは次の6つだけです【実測: n=1, 2026-08-17, wp-adminのプラグインエディターで表示したプラグイン本体のソース】。

new_to_publish / pending_to_publish / draft_to_publish
auto-draft_to_publish / future_to_publish / private_to_publish

6つとも「◯◯から公開へ」という状態の変化です。「公開済みのものを公開済みのまま書き換えた」ときに呼ばれるきっかけは、1つも登録されていません【実測: n=1, 2026-08-17, wp-adminのプラグインエディターで表示したプラグイン本体のソース】。

ではその6つの条件を満たせば消えるのか、も試しました。測定用の投稿をいったん下書きに戻し、別のURL（測定用の固定ページ）のキャッシュが効いている状態を確認してから、投稿を再公開します。プラグインは特定のURLではなくサイト単位で消しに行く実装なので、動いていれば別URLのキャッシュも落ちるはずです。結果は2回とも、再公開の0.8秒後から16秒後まで、ずっとキャッシュが効いたままでした【実測: n=2, 2026-08-17, 再公開直後の別URLを0.2〜1秒間隔で観測】。

ただし、ここから先は断定できません。 プラグインはサーバーの内側（127.0.0.1 の待受）に向けて「消して」と投げる作りで、その受け側が実際に要求を受け取ったのかどうかは、外からは見えないからです。筆者はSSHで中に入っていないため、確認していません。また今回の更新・公開はすべてWordPressのREST API経由で行っており、管理画面の「更新」「公開」ボタンを押した場合は試していません。 プラグインは動作中のディレクトリの値を一緒に送る作りなので、経路が変わると送られる値も変わる可能性があります。

読者にとっての実務的な結論はこうです。 このプラグインは「新しく記事を公開したとき、トップページや一覧に反映されるのを早くする」ためのもので、入っていても、更新の反映は早くなりません。更新が見えないときは、このあとの切り分け手順のとおり ?cb= を付けて確認するか、1分ほど待ってください。

どうやって測ったか（再現手順）

同じことを自分のサイトで試せるように、条件と手順をそのまま書きます。

測定条件

クライアント: macOS 26.6.0 / curl（ブラウザ不使用。ブラウザキャッシュ・拡張機能の影響を受けない。取得したのはレスポンスヘッダのみで、本文HTMLは取得していない）
アクセス状態: 匿名（ログインCookieなし）。WordPressの管理者としてログインした状態では挙動が変わる可能性があるため、読者と同じ条件に揃えました
回線・時間帯: 家庭用光回線 / 2026-08-16 14:30〜15:00（JST）
対象サイト: ConoHa WING（WINGパックベーシック／12ヶ月契約）に置いた自社サイト。公開直後で外部トラフィックがほぼゼロのため、第三者のアクセスでキャッシュが作り直される撹乱が起きにくい状態
滞留時間の対象URL: 公開済みの記事ページ1本（6ラウンドすべて同一URL）
測定の開始点: 対象URLへのリクエストに x-nginx-cache が MISS または EXPIRED を返した瞬間（＝その時点でキャッシュが作り直されたとみなす）
測定の終了点: 同じURLへのリクエストが再び MISS または EXPIRED を返した最初の瞬間
ポーリング間隔: 第1弾は5秒、第2弾は1秒。誤差は片側（真値は測定値以下）
打ち切り上限: 第1弾900秒／第2弾300秒（いずれも到達せず、全ラウンドで切り替わりを検出）
ラウンド間隔: 第1弾30秒／第2弾20秒（前のラウンドの状態を引きずらないため）
コンテンツは一切更新していない【実測: n=6, 2026-08-16, 上記条件での匿名HTTPポーリング測定】

手順

対象URLに curl -sSI <URL> を投げ、レスポンスヘッダに x-nginx-cache が含まれるかを確認する
同じURLに連続2回投げ、1回目と2回目で値が変わるかを見る（EXPIRED → HIT になれば、2回目はキャッシュから返っている）
?cb=<エポック秒> を付けた一意なURLを投げ、MISS が返ることを確認する（未キャッシュのURLであることの裏取り）
滞留時間の測定は次のループで行う
対象URLを叩き続け、MISS または EXPIRED が返った瞬間を t0 として記録する
以後、一定間隔で同じURLを叩き、値を記録し続ける
再び MISS または EXPIRED が返った時点の経過秒を、そのラウンドの滞留時間として記録する
一定時間空けて次のラウンドに入る。これを3回繰り返す
手順4を、ポーリング間隔の異なる2条件で実施し、計6ラウンドの個別値を残す

証跡の残し方は2条件で違います。5秒間隔の測定は各ポーリングの時刻とヘッダ値を1行ずつ、1秒間隔の測定は開始時刻（t0）と切り替わりを検出した時刻を、それぞれ保存しています。対象URLには公開済みの記事ページを使い、内容は書き換えていません【実測: n=6, 2026-08-16, ポーリングスクリプトの出力を保存した証跡ファイル2点】。

ConoHa WINGで反映されないときの切り分け手順

ここまでの実測を、実際に困っている人の手順に落とします。本記事で測っていない部分は、その旨を書いてあります。

手順1. ?cb= 付きのURLで開いてみる

URLの末尾に ?cb=1 のような重複しない値を付けて開きます。ブラウザのアドレスバーだけで実行できます。冒頭に書いた筆者のケース（パーマリンクを変えた直後）は、まさにこの手順1で「新しい内容が返ってきた」パターンでした。設定は反映済みで、通常のURLで見えていた表示のほうが古かった、ということです。

手順2. 通常のURLで x-nginx-cache を見る

返ってきた値ごとに、次にやることが変わります。

返ってきた値	読み方	次にやること
`HIT`	その応答はキャッシュから配られている、と読めます	手順1で新しい内容が出ていたなら、時間の問題です。手順3へ
`EXPIRED` または `MISS`	その回の応答はキャッシュから返っていない、と読めます	それでも古い内容なら、キャッシュではなく設定側の問題です。手順5へ
ヘッダ自体が出てこない	このヘッダを返さない構成です	本記事の方法は使えません。他の手段で切り分けてください

本記事の実測では、トップページで HIT を一度も観測できていません（連続2回とも EXPIRED）【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】。この手順はトップページだけで判断せず、個別記事や固定ページでも同じ確認をしてください。

手順3. 少し待ってから、もう一度見る

本測定では、コンテンツを更新しない条件で、記事ページ1本について 61〜63秒（6ラウンド）でキャッシュが切り替わりました【実測: n=6, 2026-08-16, ポーリング間隔5秒3ラウンドと1秒3ラウンド】。更新を伴う場合の待ち時間は測っていないので、この数字を待ち時間として当てにしないでください。

手順4. ブラウザ側を切り分ける

curl では新しい内容が返るのに、ブラウザでは古いままなら、原因はブラウザ側にあると絞り込めます。シークレットウィンドウや別のブラウザで開くと確かめられます。なお本測定は curl のみで行っており、ブラウザ側の挙動は測っていません。

手順5. それでも古いなら、設定そのものを疑う

手順1で ?cb= 付きでも古い内容が返るなら、キャッシュの話ではありません。保存できていない、別の場所の設定を見ている、テーマやプラグインが上書きしている、といった方向を調べます。

手順6. コントロールパネルからのキャッシュ操作（本記事では未確認）

ConoHa WINGのコントロールパネルにキャッシュを消す機能があるかどうかも含め、本記事では確認していません。 測定はすべてログインなしの匿名アクセスで行っており、コントロールパネルを開いていないためです。効果があるともないとも書けません。

この記事の限界（正直に書いておきます）

滞留時間の6ラウンドは、すべて同一の記事ページ1本での測定です。 トップページ・固定ページでは滞留時間を測っていません。本記事はページ種別で挙動が違う例（トップページで HIT が出ない）を観測しているため、他のページ種別で同じ秒数になるかは分かりません【実測: n=6, 2026-08-16, 記事ページ1本を対象とした6ラウンド】
6ラウンドはすべて同じ日の 14:30〜14:58 に連続して測ったものです。 別の日・別の時間帯で同じ値になるかは測っていません【実測: n=6, 2026-08-16, 連続した約28分間の測定】
取得したのはレスポンスヘッダだけで、本文（HTML）は一度も取得していません。 「?cb= を付けて新しい内容が返るかを見る」という本記事の分岐は、ヘッダの観測からの解釈であり、本文を突き合わせて検証したものではありません
測定は1サイト・1契約（WINGパックベーシック）でのものです。 ConoHa WING全体の挙動を代表しません。プランやサーバーの個体、設定によって違う可能性があります
ポーリング自体がHTTPリクエストです。 測定行為がキャッシュの生成タイミングに影響している可能性を排除していません。とくに測定の開始点は「ポーリングが切り替わりを観測した瞬間」であって、サーバー内部でキャッシュが実際に作られた瞬間とは、最大でポーリング間隔ぶんずれ得ます（ずれる向きは片側で、真値は測定値以下です）【実測: n=6, 2026-08-16, ポーリング間隔5秒・1秒】
6回の実測値は61〜63秒に収まりましたが、内部設定値が何秒であるかは断定できません。 実測値からの推定であり、設定を見たわけではありません【実測: n=6, 2026-08-16, 同上】
トップページだけ連続2回とも EXPIRED で、HIT を観測できませんでした。 原因は特定できていません。ページ種別で挙動が違う可能性を否定できません【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】
このサイトには、コンテンツ更新時にキャッシュを自動で消すプラグインが入っています（ConoHaのコントロールパネルからWordPressを導入した際に併せてインストールされたもの）。他の導入経路でも同じ状態になるかは確認していません。発火条件は公開翌日（2026-08-17）に確認し、上の追記の節に書きましたが、そこにも限界が残っています（サーバー内部の受け側までは見ていない／管理画面のボタン経由は未検証）
すべて匿名HTTPでの測定です。 ログイン中の管理者から見た挙動、およびブラウザから見た挙動は測っていません
MISS・HIT・EXPIRED の各値の定義を、ConoHa WINGの公式ドキュメントで確認していません。 本記事は「この条件でこの値が返った」という観測結果です

追加で測ったものが出てきたら、この記事に加筆して更新日を改めます。

よくある質問

Q. WordPressでパーマリンクを変更したのに、古いURLのままなのはなぜですか。

A. 本記事ではパーマリンク変更を伴う測定をしていないため、原因を断定することはできません。ただし「設定は反映済みなのに古い画面が見えているだけ」なのかどうかは切り分けられます。URLの末尾に ?cb=1 のような重複しない値を付けて開いてください。実測では、この形のURLは3回とも MISS を返しました【実測: n=3, 2026-08-16, 匿名HTTPでキャッシュバスター付きURLの応答ヘッダを取得】。ここで新しいURL形式が見えるなら、設定そのものではなくキャッシュ側の話として扱えます。古いままなら、パーマリンク設定の保存やテーマ・プラグイン側を疑う番です。

Q. ConoHa WINGのキャッシュ保持時間は何秒ですか。

A. 断定できません。本記事で言えるのは、コンテンツを更新しない状態で、記事ページ1本について6ラウンド測った結果が61〜63秒だったということだけです【実測: n=6, 2026-08-16, ポーリング間隔5秒3ラウンドと1秒3ラウンド】。サーバー側の設定値は確認していませんし、ConoHa公式の公表値とも照合していません。

Q. 設定を変えてから何秒待てば反映されますか。

A. 測定専用のページで測った3回は、56.61秒・59.67秒・60.08秒でした【実測: n=3, 2026-08-17, 測定専用ページへの匿名HTTPポーリング】。更新しなかった場合の滞留61〜63秒と同じ帯です【実測: n=6, 2026-08-16, コンテンツを更新しない条件での測定】。ただしこれは測定専用のページ1つ・投稿1つを、1日のうちに測った値であり、あらゆる更新がこの秒数で反映されるという意味ではありません。待たずに確認したい場合は、上の1問目の方法（?cb= 付きのURL）を使ってください。

Q. ConoHa WINGの自動キャッシュクリアプラグインは必要ですか。

A. 「更新した内容を早く反映させたい」という目的なら、効果はありませんでした。 このプラグインが動くのは公開へ状態が変わったときだけで、公開済みのものを書き換えたときに呼ばれるきっかけは登録されていません【実測: n=1, 2026-08-17, wp-adminのプラグインエディターで表示したプラグイン本体のソース】。実際、有効にした状態と停止した状態で反映までの秒数はほとんど変わりませんでした（56.61秒対 59.67秒）【実測: n=3, 2026-08-17, 測定専用ページへの匿名HTTPポーリング】。ConoHaのコントロールパネルから導入すると既定で入るものなので、わざわざ外す理由も特にありません。詳しくは上の追記の節をご覧ください。

Q. コントロールパネルからキャッシュを消せば、すぐ反映されますか。

A. 本記事では、そうした機能があるかどうかを含めて確認していません。 測定はすべてログインなしの匿名アクセスで行っており、コントロールパネルを開いていないためです。効果があるともないとも書けません。

Q. ブラウザのキャッシュとサーバーのキャッシュ、どちらが原因か見分けられますか。

A. curl でヘッダを取れば、サーバーがキャッシュから返しているかどうかの手がかりは得られます。curl では新しいのにブラウザでは古い、という状態であれば、原因はブラウザ側にあると絞り込めます。ただし本記事はブラウザ側の挙動を測っていません。測ったのは curl から見えたレスポンスヘッダの範囲だけです。

Q. トップページで HIT が出ないのはなぜですか。

A. 分かりません。 連続2回とも EXPIRED を返した回があった、という観測事実だけを記録しています【実測: n=1, 2026-08-16, 匿名HTTPの連続2回アクセス】。記事ページと固定ページでは EXPIRED → HIT を観測できているので、切り分けのときはトップページだけで判断しないことをおすすめします。

Q. この方法は他のレンタルサーバーでも使えますか。

A. 確認していません。 キャッシュの状態を示すレスポンスヘッダは、サーバーや構成によって名前も値も異なります。本記事で確認したのは、ConoHa WING（WINGパックベーシック／12ヶ月契約）に置いた1サイトのみです。他社のサーバーは測っていません。

Q. 測定でサイトに負荷はかかりませんか。管理画面へのログインは必要ですか。

A. 今回の測定は、匿名のHTTPリクエストだけで行っています。管理画面へのログイン操作は一切していません。ただし負荷の大きさは測っていません。?cb= 付きのURLはキャッシュを使わずサーバーに処理させることになるため、繰り返し大量に叩く使い方は避けてください。

ConoHa WINGについて当サイトが測った他の記録

このサイトはConoHa WING上で運用しており、契約から運用までのつまずきをその都度測って記事にしています。契約時に実際に請求された金額の内訳はConoHa WING料金は12ヶ月でいくら？に、申込時の「かんたんセットアップ」が完了表示のまま中身が入っていなかったときの切り分けはConoHa WINGかんたんセットアップ失敗の対処法にあります。どちらもこの記事と同じく、うまくいかなかった側の記録です。

また当サイトはConoHa WING以外のレンタルサーバーも実際に契約して、同じ時刻・同じ手順で応答速度と総額を測っています。他社と並べて見たい場合は安いレンタルサーバーの無料お試し比較を参照してください。

この記事で使ったサービスについて

本記事はConoHa WINGの契約者としての測定記録です。2026-08-21に紹介リンク（アフィリエイトリンク）を掲載しました。 もしもアフィリエイト経由の提携が成立したためです（当初はA8.netに申請していましたが、申請から7日経っても審査中のままでした）。掲載にあたっては広告・PR表記に関するポリシーに従い、記事冒頭と末尾で開示しています。リンクを掲載したことによる本文の書き換えはしていません——この記事が報告している内容は、リンクを貼る前と同じままです。

広告（PR・アフィリエイトリンク）の開示
下のリンクは当サイトの紹介リンク（もしもアフィリエイト経由）です。このリンクを経由してConoHa WINGの新規アカウント登録および申込が成立した場合に限り、当サイトへ紹介報酬が支払われます。報酬額は契約プランによって異なり、上位プランほど高く設定されています。なお筆者は本サービスの契約時にASPのセルフバック（自己アフィリエイト）を利用しており、その事実もあわせて開示します。報酬の有無によって測定結果や記述を変えることはしていません。本記事は「更新してもすぐには反映されない」という不都合な挙動をそのまま書いた記録です。

ConoHa WING 公式サイト（当サイトの紹介リンク）

紹介リンクを使いたくない場合は、検索などから公式サイトを直接開いてください。提供される内容もプランの価格も変わりません。

この記事の測定条件・証跡の詳細は運営者情報・編集方針に記載の方針に従っています。広告表示についての方針は広告・PR表記に関するポリシーをご覧ください。