Wordpress(kusanagi)のbcacheをONにするとCDNのキャッシュがHITしない

実現したいこと

kusanagiを導入したWordpressでbcacheを有効にしています。

その状態でFastlyのCDNを導入したのですが、レスポンスヘッダーを確認してもほとんどの場合、「X-Cache」がMISSとなります。

ほとんどの場合と書きましたのが、bcacheのレスポンスヘッダーが「X-B-Cache:cache」を返した時はX-CacheがHITしますが、「X-B-Cache:create」を返した時はMISSとなります。

実現したいとこととしましては、X-B-Cacheのヘッダーに関係なくX-CacheをHITとしたいのですが実現方法はありますでしょうか。

wordppressサイトの負荷対策のために記事ページを基本的にはCDNで配信しつつ、オリジンサーバーにアクセスがあった場合はbcacheを効かせたいという主旨になります。
よろしくお願いいたします。

発生している問題・分からないこと

kusanagiのbcacheのレスポンスヘッダーの値に関係なく、CDNのキャッシュをHITさせる方法がわからない。

該当のソースコード

・以下のデバックコマンドを実行すると curl -H "Fastly-Debug:1" -v "https://対象サイトのURL/" > /dev/null ・以下のレスポンスが取得できました。 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying IPアドレス... * TCP_NODELAY set * Connected to 対象サイトドメイン (IPアドレス) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /xxxx/cacert.pem CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): } [5 bytes data] * TLSv1.2 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * TLSv1.2 (IN), TLS handshake, Server hello (2): { [106 bytes data] * TLSv1.2 (IN), TLS handshake, Certificate (11): { [3054 bytes data] * TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [333 bytes data] * TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data] * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [70 bytes data] * TLSv1.2 (OUT), TLS change cipher, Client hello (1): } [1 bytes data] * TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data] * TLSv1.2 (IN), TLS change cipher, Client hello (1): { [1 bytes data] * TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data] * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=対象サイトドメイン * start date: May 17 07:41:44 2024 GMT * expire date: May 31 14:59:59 2025 GMT * subjectAltName: host "対象サイトドメイン" matched cert's "対象サイトドメイン" * issuer: C=JP; O=Japan Registry Services Co., Ltd.; CN=JPRS Domain Validation Authority - G4 * SSL certificate verify ok. } [5 bytes data] > GET /対象パス/ HTTP/1.1 > Host: 対象サイトドメイン > User-Agent: curl/7.55.1 > Accept: */* > Fastly-Debug:1 > { [5 bytes data] < HTTP/1.1 200 OK < Connection: keep-alive < Content-Length: 86633 < Server: nginx < Content-Type: text/html; charset=UTF-8 < X-B-Cache: cache < X-F-Cache: BYPASS < X-Signature: KUSANAGI < X-XSS-Protection: 1; mode=block < X-Frame-Options: SAMEORIGIN < X-Content-Type-Options: nosniff < Surrogate-Key: /対象パス /athlete_celeb /対象パス/*. /対象パス/.* 対象サイトドメイン < Accept-Ranges: bytes < Age: 0 < Date: Thu, 30 May 2024 09:41:53 GMT < Via: 1.1 varnish < Fastly-Debug-Path: (D cache-nrt-xxxxx-NRT 0000000) (F cache-nrt-xxxxxx-NRT 0000000) < Fastly-Debug-TTL: (M cache-nrt-xxxxx-NRT - - 0) < Fastly-Debug-Digest: 000000000000000000000 < X-Served-By: cache-nrt-xxxxx-NRT < X-Cache: MISS < X-Cache-Hits: 0 < X-Timer: S0000000.427722,VS0,VE25 < Vary: User-Agent,Cookie < { [5 bytes data] 100 86633 100 86633 0 0 86633 0 0:00:01 --:--:-- 0:00:01 379k * Connection #0 to host 対象サイトドメイン left intact ※サイトを特定できそうな記述やIDのような値は少し加工しています。

試したこと・調べたこと

上記の詳細・結果

VCLを使って制御する方法がありそうですが、私の知識では具体的な書き方が分かりませんでした。

補足

KUSANAGIのバージョンは8.4.2-1です。

コメントを投稿

0 コメント