ども。こんばんは。

今日は連投ですね。

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

にごちゃごちゃ追記したのですが、結論やっぱり無理です。

しばらくすると、IncapsulaでError Code 23になってしまいました。

その後、CloudFlareのCDNをoff(=DNS上、www.hits-net.comの解決結果がIncapsulaのCNAME)状態であれば通ります。

これを何度か再現テストして今の所再現率100%なので、やはり、IncapsulaのProxyは名前解決をちゃんと見ているのかもしれませんし、Free Planゆえのなにかかもしれません。

一応Error code 23の主要な原因はこれです。

https://support.incapsula.com/hc/en-us/articles/231496108-Grace-period-for-removed-sites
※24時間以内に同じFQDNを追加削除すると駄目だよっていう感じの話。

以下、完全に推測です。もしかしたら本当にIncapsulaがゴミ持ってるかもしれないし・・・。

上述の動作なら通常テストするときにhostsファイルに書いてアクセスしても同じことが起きるんじゃ？と思いますが・・・。

おそらくですが、hostsを編集した状態でアクセスしても、

元々のDNS(=Incapsulaが知っているDNS解決結果)と同じなら、通してくれる
※都度かどうかはわからないがIncapsula自身が名前解決をしている。これはoriginに対してではなく保護対象として登録したFQDNに対してと思われる。(OriginがCNAMEの場合はもちろん名前解決しますが、今回はOriginはIPアドレス直接指定なので)

のではないかと思います。

CloudFlareを前段に持ってきてCDNをOnにすると、IPアドレスの解決結果はあくまでCloudFlareです。

ということは、Incapsullaからすると、www.hits-net.comは、元々Incapsulaが最初にスキャンしたOriginのIPでもなく、Incapsulaが払い出したCNAMEでもない第3の「なにか(=ここではCloudFlare)」を解決してしまうことになります。
確かにこのパターンはそうそうないかも。

多分それが今回のError Code 23の原因かと。しばらくうまく行ったように感じるのは、CloudFlareのキャッシュが帰ってくるからかと思います。

CloudFlareのCDNをoffにすると割とすぐにError code 23はなくなります。(CloudFlareのTTLが300秒なので多分最大5分待てばいい。)

これCNAME Reuse使えれば話は違うんだろうけどなぁ。
OriginをCNAMEで登録したいなぁ。

もういいや、ということで、多段は諦めて、Incapsulaでキャッシュすることにしました。

【バックナンバー】

• 令和になったことだしクラウドへ移行する – 1 – 全体方針
• 令和になったことだしクラウドへ移行する – 2 – Exchange Server 2010 to Office 365(1)
• 令和になったことだしクラウドへ移行する – 3 – Exchange Server 2010 to Office 365(2)
• 令和になったことだしクラウドへ移行する – 4 – Exchange Server 2010 to Office 365(3)
• 令和になったことだしクラウドへ移行する – 5 – Exchange Server 2010 to Office 365(4)
• 令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。
• 令和になったことだしクラウドへ移行する – 7 – t2.microでmariaDBが落ちる
• 令和になったことだしクラウドへ移行する – 8 – t2.microが激重になる
• 令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

ではでは。またの機会に。