URLを同じままにする必要があると述べているため、これはリバースプロキシを介して実現できます。www.mysite.com で応答する Web サーバー (通常は nginx または IIS) をセットアップします。
/portal
この Web サーバーには、要求をオンプレミス サーバー (特定の非パブリック IP およびポート) に転送し、他のすべての要求を WordPress を実行している別の Web サーバー (同じサーバー/クラスター上で実行)に転送するためのリバース プロキシ ルールがあります。リバース プロキシ、または別のプロキシ)、これも特定の IP とポートを使用します。
次に、すべてのユーザー要求はリバース プロキシに到達し、可能であればキャッシュから処理するか、内部 Web サーバーに転送し、応答を透過的にユーザーに送り返します。これは内部操作であり、リダイレクト応答ではないことに注意してください。
この設定は、異なるサブドメイン (ウェブサイトに www.mysite.com、アプリケーションに portal.mysite.com) を使用する単純なソリューションよりも複雑ですが、参照されているウィキペディアの記事で説明されているセキュリティや加速度。
または、上記のように個別のサブドメインを作成し、リダイレクト ルールを使用して へのリクエストをリダイレクトすることもできwww.mysite.com/portal/x
ますportal.mysite.com/x
。この場合、ユーザーのブラウザーには更新された URL が表示されますが、古い URL は引き続き機能します。