t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化にごちゃごちゃ追記したのですが、結論やっぱり無理です。23になってしまいました。その後、CloudFlareのCDNをoff(=DNS上、www.hits-net.comの解決結果がIncapsulaのCNAME)状態であれば通ります。Planゆえのなにかかもしれません。23の主要な原因はこれです。https://support.incapsula.com/hc/en-us/articles/231496108-Grace-period-for-removed-sites※24時間以内に同じFQDNを追加削除すると駄目だよっていう感じの話。以下、完全に推測です。したら本当にIncapsulaがゴミ持ってるかもしれないし・・・。上述の動作なら通常テストするときに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)」を解決してしまうことになります。確かにこのパターンはそうそうないかも。うまく行ったように感じるのは、CloudFlareのキャッシュが帰ってくるからかと思います。(CloudFlareのTTLが300秒なので多分最大5分待てばいい。Reuse使えれば話は違うんだろうけどなぁ。OriginをCNAMEで登録したいなぁ。いいや、ということで、多段は諦めて、Incapsulaでキャッシュすることにしました。ブログがAWSになりました。t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化ではでは。ともコメントするども。昨日以降したAWS環境ですが早速トラブルです。いうかまぁ起きそうだなぁとは思ってましたが、メモリが足りずmariaDBが落ちてました。Aborting確かにちょいとメモリが足りないしswapがないんですよねー。0にいろんな方も同じ状況みたいで、swapを作る方法がありました。t2.microでもssdだし、swap作っても大丈夫?かな。