SiteGuardとの戦い：番外編（濡れ衣付き）
濡れ衣：Wordpressのループバックエラー
WordPressのサイトヘルスを確認したら、ループバックエラー（403）だってよ。
最初はSiteguardの仕業かと思ったけど防御解除しても変わらないから別の理由。
そして、このループバックはサイトURLへのアクセスとなる。
そして、WordpressサイトはCloundFrontでCDNやってるので当然サイトURLはCloundFrontのIPとなる。
結果、ループバックリクエストがグローバルからのアクセスとなって弾かれる。
対処は/etc/hostsにサイトURLを追加すること。基本的に実体のWordpress自身がCDN非経由でアクセスする分には不都合はないのでこれでよいはず。
なお、この方法を使うとCloudFrontによるキャッシュが行われていることがサイトヘルスには分からなくなるため『ページキャッシュは検出されませんでしたが、サーバーのレスポンスは良好です』という警告が表示される可能性がある。
なお、当サイトはCDNによるキャッシュとRedisによるキャッシュを併用してるが、どうもヘルスチェックはRedisによるキャッシュを認識しない（WP Super CacheやW3 Total Cacheじゃないと認識しないのかね）模様。
本題：SiteGuardの応答キャッシュ追加とnginxのコンフィグでのヘッダー追加で同一項目が重複すると、nextcloudに怒られる
SiteGuardの高度な設定で応答ヘッダを追加できる。
とりあえずデフォルトの設定をそのままにしていたのだが、なぜかnextcloudのヘルスチェックで以下のヘッダーが無いと怒られた。
X-Frame-Options:SAMEORIGIN
X-XSS-Protection:1; mode=block
X-Content-Type-Options:nosniff
Strict-Transport-Security:max-age=31536000実際のところは、上記のヘッダーは全てnginxのコンフィグに記載されており、なおかつSiteGuradの応答ヘッダー追加機能によって追加されてもいる。
とりあえず一旦、SiteGurad側の応答ヘッダー追加機能を停止してnextcloudのヘルスチェックを走らせると今度は何も言われない。
で、両方ONになっているときはやはり怒られる。そのときの実際の応答ヘッダーを開発ツールから確認したところ、両方でヘッダーが追加されていると同じヘッダーが2つ追加されることが分かった。
どうも、重複するのがだめらしいので、Strict-Transport-Securityヘッダー以外はSiteGuardに委ねる事にしてnginxのコンフィグでのヘッダー追加をコメントアウトしてサービス再起動することでnextcloudに怒られる事無くSiteGuardの応答ヘッダー追加機能によりヘッダーが追加できた。
あと、なぜかPHP-FPMがハングアップしたのでサービス再起動。何が原因だろうか・・・