BLOG

某国際機関のウェブサイト制作を引き受けることになり、CMS導入を希望されたのでお手軽WordPressで構築しようとしたのですが。
いかんせんお相手は某国際機関（‥ってどこやねん！というツッコミはおいといて）のウェブサーバーにWordPressを入れることは、色々と大変でして（手続き、承認、セキュリティ、‥ウンヌンカンヌン）。

そこでReverse-Proxyを先方にて用意していただき、我々は別サーバー上にWordPressサイトを作ってReverse-Proxyにて接続してもらう、という事になりました。
しかしながらうまく動作せず、ハマってしまいました。

ググってみましたが、意外な事に情報が見つからず。
最終的には自己解決したので、その内容をシェアいたします。

Reverse-ProxyとWordPress、それぞれの関係性

ウェブブラウザーからアクセスするURLが「 https://sample.site/blog/ 」(A)

Reverse-Proxy がアクセスするURLが「 https://origin.site/samplesite_blog/ 」(B)

(A)にReverse-Proxy が搭載されています。

(B)にWordPressが存在します。

このような関係性です。

(B)のWordPress側では以下に記載の通り設定を行います

FAQ/インストール

他には、(B)の出力、特にリンクを変えるために、以下の設定を wp-config.php 先頭部分に追記します。

define('WP_SITEURL'    , 'https://sample.site/blog/');
define('WP_HOME'       , 'https://sample.site/blog/');
define('WP_CONTENT_URL', 'https://sample.site/blog/wp-content');

というところまでは、あちこちで紹介されているのですが。

‥はい、失敗します。

WordPress側で行う具体的な設定はこちら

(B)のURLを、「 https://origin.site/blog/ 」(B')
としてください。パスの部分「/blog/」を(A)と(B)で同じにする、という事です。

理由は私も明確に説明できませんが。
WordPressは、REQUEST_URIに含まれるパスとローカル上のパス（この場合は /blog と /samplesite_blog ）が異なる時に、パスが違うと判断するようです。

これはパーマリンク設定を ?p=xxx 以外にしたときに発生します。
どのページを開いても 404 Not Found となってしまうのです。

でも、Reverse-Proxy側で変えてもらうのは大変‥

(B)を(B')にすること自体は、WordPress側で簡単にできます。
でも、Reverse-Proxyを設定している(A)側にも、(B)が(B')に変わったよ、と言わないといけない。

そう言ってすぐ対応してくれるのなら何の問題もないのですが、いかんせんお相手は某国際機関（ってどこ？？）。
手続きが大変で、変更に時間がかかると申すのです。

だから何とかしてWordPress側だけでパスを変える必要があったのです。

WordPress側のパスを、このような方法で変えました

結論、こうしました。

wp-config.php（先頭部分） に以下の設定を追記しました。

$_SERVER["SCRIPT_NAME"] = str_replace("/samplesite_blog","/blog",$_SERVER["SCRIPT_NAME"]);
$_SERVER["REQUEST_URI"] = str_replace("/samplesite_blog","/blog",$_SERVER["REQUEST_URI"]);

WordPress側でURLを置換して、（A)のパスと同じにしました。

でもまだ足りません。
サーバー内のパスは、相変わらず /samplesite_blog のままです。

そこで、このようにしました。
２案ありますが、どちらか採用しやすい方法でOKです。

案１

・WordPressインストールディレクトリを、/samplesite_blog から /blog に変更（リネーム）する。

・ルートディレクトリ上の.htaccess で、 RewriteRule を使い、 /samplesite_blog を /blog に向くよう設定する。

RewriteRule ^samplesite_blog(.*)$  /blog$1

案２

・WordPressインストールディレクトリを、/samplesite_blog から /blog に変更（リネーム）する。

・シンボリックリンクを張る。

$ ln -s blog samplesite_blog

こんなかんじです。

これで無事期待通りの動きとなりました。
めでたしめでたし。

SEO対策として必要な事

基本これでOKですが、SEOの観点で考えると、(A)でも(B)でもアクセス出来てしまう事はよろしくありません。重複コンテンツとなるからです。

なので、(B)からのアクセスは一切許可しないようにしました。

やり方は色々ありますが、今回は wp-config.php に以下の記述をすることで対応しました。

if ( @$_SERVER['REMOTE_ADDR'] != 'xxx.xxx.xxx.xxx' ) {
	header("HTTP/1.1 401 Unauthorized");
	exit;
}

xxx.xxx.xxx.xxxは(A)のIPアドレスです。
ここからのアクセス以外をすべて拒否する設定です。

もっとシンプルに、.htaccessなどウェブサーバー側で行っても良いです。
今回 wp-config.php に記述したのは、デザイン会社さんなど別のところが.htaccessを触る可能性があるので、万が一設定を消されても良いようにした、というのがその理由です。

これで、一通り動くようになりました。

改めて、めでたしめでたし。

多段Reverse-Proxyで起きた問題への対応（2023.02.27追記）

設定を行ってから数日後、動作確認をしていたところ特定のURLでリダイレクトが発生し、しかもその時のホスト名が(B)のorigin.siteになってしまい、焦った事がありました。そのための対策は以下の通りしていたはずなのに・・。

FAQ/インストール

具体的にはこういう設定をしていたのですが、うまく行っていない。

$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];

ここで説明ですが。

WordPressは、HTTP_HOST を使ってリダイレクト先URLなどを自動で生成しています。
しかしながら、HTTP_HOSTはWordPressが動いているホスト名(B)です。リダイレクト先URLを作るのであれば、クライアント（ウェブブラウザー）上で指定されたURL(A)のホスト名を使わないといけません。

URL(A)のホスト名は、下の引用先を見てもらうと分かる通り、HTTP_X_FORWARDED_HOST ヘッダーを使えばおおよそ分かりますから、上のコードを書いてください、という話はごもっとなのです。

X-Forwarded-Host (XFH) ヘッダーは、 HTTP の Host リクエストヘッダー内でクライアントから要求された元のホストを特定するための事実上の標準となっているヘッダーです。

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-Host

さて、そんな前提を知っていただいたうえで。
改めて (B)にリダイレクトされた原因を探ったところ、HTTP_X_FORWARDED_HOST　に入っている値がそもそも正しくなかった、という事がわかりました。

じゃあ誰がこの値を設定したの？という話ですが、おそらくWordPressを搭載したサーバーである、Xserver側ではないかと推測しています。というのは、Xserver側では既にReverse-Proxyを立てていて、アプリケーションサーバー（例えばphp-fpm）に処理を引き継いでいるように見えるからです。その時に正しくHTTP_X_FORWARDED_HOST を指定しなかったのではないか、とという推測です。

‥いやまてよ、ここまで書いてふと思ったのですが。某国際機関のReverse-Proxyを設定した人のミスかもしれませんね‥、可能性ゼロではない‥まあいいや、それ話すとまた別の話になるので。

要は、HTTP_X_FORWARDED_HOST　の値が期待値ではない場合は使えないし。それを設定する相手に責任を押し付けてもしょうがない話だし。じゃあ別の方法で HTTP_HOST を変えてしまえば良いよね、という結論に達し、このように直しました。

$_SERVER['HTTP_HOST']   = 'sample.site';  // (A)のホスト名

これで無事、リダイレクト時に(B)のホスト名に行く事が無くなりました😅

ちなみに、どういうときにリダイレクトが発生するかというと、例えばこれです。

https://sample.site/news
↓
https://sample.site/news/

最後に「/」があるかどうか、です。
具体的にこのリダイレクトが走った処理を追っかけて行ったら、 wp-includes/canonical.php でした。

canonical といえば 正規のURLにするってもの。
そう、 /new は NGで /news/ が正規のURLなのです。

ということで、そもそもHTMLコーディング時に指定したURLがいけないので、コーダーさんに依頼して直してもらいました。

WordPress側で 正規のURLに変えてくれるならいいじゃない、と思うでしょうが。
URLを変える、という事はブラウザー側でもう一度正規のURLにアクセスしなおす、という処理が発生するという事でもあります。もう一度アクセスする、という事はその間表示に時間がかかるという事です。

表示に時間がかかるという事は、訪問に来た人にとって決して良い体験ではありません。下手したら離脱されかねません。少しでも表示を速くしてユーザー体験をよくすることも私たちプロフェッショナルの務めだと思っています。

ちょっとだけ宣伝

ウェブサイト制作といっても、ＩＴ技術の上に成り立っているわけですから、ＩＴの基本的な構造を知るエンジニアが居るのといないのとでは、できる幅が全然違います。

私たちは、ウェブ制作とマーケティングができる「エンジニア集団」の会社ですから、デザイン中心の制作会社さんで出来ない、という事にも対応いたします。

ちょっとした相談でもお気軽にお問合せください。