WordPressが突然変な動きすると思ったらWAFが原因だった話

この記事は最終更新日から2年以上経過しています。

タイトルの通り、WordPress開発をしていたときにかなりはまった時のお話です。
今回はだらだら経過を書いているだけなので今回学んだことだけ知りたい方は一番下の結論をご覧ください。

とあるサイトのWordPress開発をしているとき、検証環境では問題なく動いていたものが本番環境に移行したら突然一部のプラグインが動かなくなりました。
動かなくなるというのもなんとなく一部のPOST通信している箇所で突然404 Not Foundになってしまうというはっきりしない現象です。
1つのプラグインであればそのプラグインに問題がある可能性も考えられるのですが、確認できた中でも2つのプラグインで挙動が微妙におかしい状況だったので全体的に何かおかしそうな感じ。
全く原因がわからずどんな操作をしても結果は同じ。
別ディレクトリで新規インストールしても結果は変わらず。
パーミッションは必要なファイルも比較したが特に問題はなさそう。
全くわからない状況が3日ほど続きました。。
検証用環境では全く問題なく動作しているので考えられるのは本番環境に移行した際に気づきにくい箇所で検証環境の情報が残っているとかくらいしか思いつきませんでした。
本番移行作業はお客様が「All-in-One WP Migration」というプラグインで実行されたということなのですが、個人的には使ったことがないツールなので、この影響も捨てられずモヤモヤが続きました。

週末になり少しまとまった時間が作れるので意を決してプラグイン内部まで徹底的に調査をすることにしました。
徹底的に調べたところ、404になってしまうPOST通信箇所までは特定できました。
さらにパラメーターをひとつずつ消していったところ、一つのパラメーターを消すことで404が解消されました。
問題となるパラメーターは特定できたので今度はそのパラメーターの調査。
かなり長いパラメーターでURLエンコードされているデータだったのでとにかく見た目わかりずらかったですが根気よく少しずつテキストを短くしていったところ、特定箇所を取り除くと404が解消されるところまでたどり着きました。
ここまでくればあとはどういう文字列の場合か検証するだけ。
結局たどり着いたのはパラメーターに「<?任意の文字列?>」(URLエンコードされた文字列は「%3C%3F任意の文字列%3F%3E」)を含む場合は404になってしまうということがわかりました。
ちなみにGETパラメーターにしても同じ現象が発生することもわかりました。

察しのよい方であればすぐに気づくのかもしれませんが、「<?任意の文字列?>」を含むだけでなぜ404になるのかがまたしばらく？？？という感じでした。
結局たどり着いたところはWAFの設定。
本番環境だけONで検証環境はOFFでした。
ということで本番環境のWAFをOFFにしたら今までの苦労が嘘のように404エラーが解消され正常に動作するようになりました。