LiteSpeedのUCSSが、Cloudflareの確認ページで壊れた話(見つけ方と直し方)

自分のサイト(96ish.jp)を開いたら、ページが崩れていました。文字は素のままで、ロゴやアイコンが大きく表示されます。原因は、LiteSpeed Cacheが作った「UCSS」(使われているCSSだけをまとめたもの)が、Cloudflareの確認ページ用のCSSで作られていたことでした。見つけ方と直し方、再発の予防を、実際に見たことだけで、まとめます。

どんな症状だったか

テーマのCSSが読み込まれず、見出しも本文も、飾りのない状態で表示される
ロゴやアイコンのSVGが、画面いっぱいに大きく出る
キャッシュを消して開き直しても、同じ

原因の見つけ方

ブラウザで、ページのHTMLを調べました。

<link rel="stylesheet"> が、Googleフォントの1本だけになっていた(テーマのCSSへのリンクが無い)
代わりに、<style id="litespeed-ucss"> が入っていた。長さは約1,100文字しかない
その中身を読むと、#challenge-error-text と .main-content など、Cloudflareの確認(チャレンジ)ページのスタイルだった

つまり、UCSSを作りに来たQUIC.cloudが、本物のページではなく、Cloudflareの確認ページを受け取ってしまい、それをもとにUCSSを作って、保存していました。UCSSは元のCSSを置き換えるので、全員に壊れたCSSが出ていました。

直した手順

LiteSpeed Cacheの設定で、UCSSのキュー(作成待ち)を、いったん「クリア」した
壊れたUCSSを作り直す(管理バーの「Purge this page – UCSS」)
ページを開き直して、見た目が元に戻ったことを確認した。HTMLの中に challenge-error-text が残っていないことも、確認した

結果(2026-11-02に確認): Skipのルールを入れたあと、トップページのUCSSは作り直されました。HTML末尾のコメントは「QUIC.cloud UCSS loaded ✅」になり、litespeed-ucss の中身は、約1,100文字から約41,600文字に変わりました。challenge-error-text は、入っていません。

注意: 「Purge All」や「Purge All – UCSS/CCSS/LQIP/VPI」は、すべてを作り直すので、QUIC.cloudのクレジットを多く使います。壊れたページだけを、作り直すほうが安全です。

再発の予防(Cloudflare側)

同じことが起きないよう、CloudflareのSecurity rules(無料プラン)に、ルールを1つ作りました。

名前: Allow QUIC.cloud
条件: 送信元のIPが、QUIC.cloudの公式IP一覧(quic.cloud/ips)に入っている。式は ip.src in {…} の形で、2026-11-02時点で152件、約2,200文字。上限の4,000文字に収まった
動作: Skip。「All remaining custom rules」「All rate limiting rules」「All Super Bot Fight Mode Rules」「Browser Integrity Check」「Security Level」をオンにした
ログ(Log matching requests)はオンにして、あとで通過を確認できるようにした

QUIC.cloudのIPは、増えたり変わったりします。式を作るときは、その時点の一覧を、取り直してください。

おまけ: UCSSの数を減らす(ページタイプ単位のフィルター)

作り直しのとき、LiteSpeedの「UCSSキュー」(作成待ちのURL一覧)に、81件が並んでいました。タグのページ、ブログの2ページ目以降、アップロードした画像のURLまで、URLごとに別々に積まれていました。UCSSは1件ずつ、QUIC.cloudに依頼して作るので、件数が多いと、クレジットを使います。ファイルの大きさではなく、依頼の回数で決まります。

そこで、次の1行を、PHPスニペット(WPCodeの「PHP Snippet」、Auto Insert、Run Everywhere)として入れました。

add_filter( 'litespeed_ucss_per_pagetype', '__return_true' );

UCSSが、URLごとではなく、ページの種類(記事、タグ、固定ページなど)ごとに作られる設定です。LiteSpeed Cacheの設定画面に、「この値はフィルターによって上書きされます。現在オンに設定されています」と出れば、効いています。

入れたあと、フィルターを入れる前に積まれていた81件(のちに83件)の順番待ちは、「クリア」で空にしました。クリアしたページは、元のCSSで表示され、崩れません。

UCSSとCSS結合の関係: 設定画面の説明では、UCSSは「各ページで使われていないCSSを、結合ファイルから落とす」ものです。CSS結合をオンにしたまま、UCSSもオンにする組み合わせで、動かしました。UCSSは元のCSSを置き換えるので、追加CSSを変えても、UCSSを作り直すまで、HTMLに出ないことがあります。

※ページタイプ単位にした効果(件数とクレジットの増え方)は、まだ測れていません。数日後に、QUIC.cloudのPage Optimizationの使用率で、確認します。

分からなかったこと(限界)

Cloudflareのどの機能が止めたのかは、特定できませんでした。CloudflareのSecurity Eventsは「サンプル」のログで、壊れた時刻(11/01 01:02ごろ)の前後30分を見ても、QUIC.cloudのIPは見つかりませんでした(見えた数件のIPは、どれも公式一覧に無い)
見えたManaged Challengeの多くは、SEOツールのクローラー(逆引きでSE Rankingと出たもの)など、別のものでした
1つのサイトでの1回の出来事です。ほかの環境でも同じ原因とは、限りません

確認するときのポイント

ページを開き、HTMLのソースで litespeed-ucss のスタイルを探す
中身が数千文字ほどあるか。テーマ由来のクラス名が入っているか。challenge の文字が無いか
HTMLの末尾のコメントが「QUIC.cloud UCSS loaded」になっているか(「in queue」は作成待ち)

3日後の確認(2026-11-05)

3日後に、96ish.jpの8つのURLを取得して、HTML末尾のコメントと、UCSSのCSSファイルの中身を見ました。ここに書くのは、見えた事実だけです。

トップページ: 「UCSS in queue」(作成待ち)。11/02の作り直し直後は「loaded」でしたが、今回取得したキャッシュ(11/04 14:46作成)では、UCSSは適用されていませんでした
記事ページ3つ(HTML入門ガイド、Googleマップのサイテーション、NTT光回線の接続方式): すべて「loaded」で、同じ /ucss/5be3c897….css(26,177文字)を指していました
固定ページ(about-us)と /technical-seo/: どちらも同じ /ucss/115bda98….css(20,802文字)
タグページ: /ucss/93ad1e4c….css(16,639文字)、ブログ一覧の3ページ目: /ucss/837c2a71….css(19,247文字)。どちらも「loaded」
8ページのHTMLと、4つのUCSSファイルのどれにも、challenge の文字や、.main-content{margin:8rem はありませんでした。中身の先頭は、WordPressのブロック用のCSS(:root{--wp-block-synced-color など)でした
11/02にQUIC.cloudの依頼一覧で見えた、確認ページ由来らしいCSS(先頭が *{box-sizing:border-box;margin:0;padding:0}html{line-height:1.15…)は、今回見たページには、適用されていませんでした(what-is-google-map-citations、about-usも含む)

違うURLの記事が同じCSSファイルを使っていたので、ページの種類ごとにUCSSが共有されているように見えます。ただし、見たのは8つのURLだけです。

(使用率の数字は未記入)QUIC.cloudのPage Optimizationの使用率(11/02は20%)が、その後どうなったかは、ダッシュボードで確認してから書き足します。

About the author