1. 発生した現象
GitHub Actionsによる自動デプロイが成功(`lftp` 転送完了)した直後、ブラウザおよび `curl` コマンドで本番サイトのHTMLを取得した際、最新の変更内容が反映されず、過去のHTMLが返却される問題が発生しました。
2. 切り分け調査とHTTPヘッダー解析
`curl -I` コマンドを使用して本番レスポンスヘッダーを取得・解析した結果、以下の固有ヘッダーが確認されました。
HTTP/2 200
server: LiteSpeed
x-turbo-charged-by: LiteSpeed
x-cache: HIT
last-modified: Tue, 18 Aug 2026 14:45:45 GMTこの解析により、Lolipopサーバー上で動作する LiteSpeed Web Server のサーバーサイドキャッシュ機能(LiteSpeed Cache)が有効化されており、FTPSでファイルが更新された後も x-cache: HIT として過去のメモリキャッシュを返却し続けていたことが判明しました。
3. .htaccessによるCache-Control再検証の定義
単にブラウザ側のキャッシュを消去するだけでは根本解決にならないため、Webサーバーに対して「HTMLおよびXMLリクエスト時には必ずファイルの更新日時を再検証(revalidate)させる」ルールを .htaccess へ追加しました(コミット a529cc6)。
<IfModule mod_headers.c>
<FilesMatch "\.(html|xml)$">
Header set Cache-Control "max-age=0, must-revalidate"
</FilesMatch>
</IfModule>4. 改善結果の検証
設定適用後、`Cache-Control: no-cache` リクエストおよび通常のアクセスにおいて、レスポンスヘッダーが以下のように変化しました。
HTTP/2 200
server: LiteSpeed
last-modified: Wed, 19 Aug 2026 07:49:21 GMT
x-turbo-charged-by: LiteSpeed
x-cache: MISSx-cache: MISS が返却され、last-modified がデプロイ直後のタイムスタンプに更新されたことで、デプロイ完了と同時に最新コンテンツが即座に訪問者へ配信される状態を確立しました。
5. まとめと注意点
「Cache-Controlを追加すればすべて解決する」という安易な一般論ではなく、採用しているホスティングサーバーのWebサーバーアーキテクチャ(Apache, Nginx, LiteSpeed等)とレスポンスヘッダー(`x-cache`)を具象的に観察・テストすることが、デプロイ障害の迅速な解消において不可欠です。
Evidence
- 本番レスポンスヘッダー:
server: LiteSpeed,x-turbo-charged-by: LiteSpeed - 対応コミット:
a529cc6(fix(cache): add max-age=0, must-revalidate) - 検証コマンド:
curl -I -H "Cache-Control: no-cache" 'https://sleeplatelab.com/legal/commercial-transactions.html?nocache=1' - 実測結果:
x-cache: HITからx-cache: MISSへの遷移確認