画像やリンクが無効になっている可能性もあるのでご了承下さい。
一度は設定して動作までこぎ着けていた ReverseProxy を用いた Proxy Cache を効かせて高速化する手法なんだけど、結局は知識不足で見えない所の安定動作が望めないので止めていた。
でもやっぱ悔しいし、大量アクセス時に裁けるリクエスト数が 1.5 倍程度上昇する事を確認しているので、是非やっておきたいとここ数日はずっと検証ばかりしている。
ググって出てくる情報をいろいろと絡めつつ安定するような形にまでこぎ着けてみたけど、ただ一点だけ上手く動作させることが出来ずにいる。
それは wp-admin の扱い。WordPress にログインしようとすると wp-login.php を叩いて認証を行った後、成功すると /wp-admin にリダイレクトされる。ReverseProxy を用いていない通常時であれば /wp-admin/index.php が参照されてダッシュボードが表示される。
でも現状は URI が /wp-admin/ になると /wp-admin/index.php が実行されず、PHP ファイルがダウンロードされてしまう。それならばと、強制的に wp-admin/index.php にリダイレクトされると、管理者個人設定で行っているダッシュボードのカラー設定が有効にならなくなってしまう。
さてどうしたものか。
あと、ReverseProxy を噛まして WordPress を動作させている解説サイトによっては
set_real_ip_from 127.0.0.1;
real_ip_header X-Forwarded-For; が http や server ブロックに存在しない所があるけど、これもまたバックエンドでのアクセス制御が上手く動かなくなるからド嵌まりするポイントでもあった。具体的には wp-login.php や wp-admin 以下へのアクセス制限が働かなくなる。
どこかに乗っている情報を適当に組み合わせるのでなく、しっかり理解しながら作業しないとだな……
自分の意図する動作設定が出来たら、改めて記事にしていこうと思う。
2015/12/27 00:11 追記 くだらないミスに気付いて解決……
再度、VMware 上の検証環境で https://example.com/wp-admin と末尾に / の無いアクセスから / 付きにしつつ、そこからダッシュボードを表示出来る事を確認。
real_ip を付与することで、wp-login.php へのアクセス制限もバックエンド側で制御可能である事も確認した。
動作確認の取れた conf を稼働ホストに scp してからホスト名を書き換えて systemctl restart nginx なんてした。それでもなんだか PHP ファイルがダウンロードされてしまう現象が変わらずで「なにこれ?」と考えて居たが「ハッ!!!」と気付いた事があった。
Proxy Cache の Purge やってないと。rm -fr /var/cache/nginx/* をやったら無事に自分が思う正常動作をしてくれるようになった。
コメント