我不知道这里是不是问这个问题的合适地方。但我有一个在 AWS 上的 Amazon EC2 实例上运行的 Web 应用程序。我们想启动一个 WordPress 博客，该博客将放置在www.myapp.com/blog。
我不想让它们位于同一个 Amazon EC2 实例中，因此我创建了另一个实例并设置了我的 WordPress 环境。它已启动并正在运行。
我现在需要做的是将此文件夹指向/blog此实例。我想我们必须使用 Amazon Route 53 来做到这一点？我甚至尝试过这样做，但显然我可以创建一个 CNAMEblog.myapp.com而不是文件夹/blog。我们真的希望它位于www.myapp.com/blog。我应该使用类似的东西.htaccess吗？
答案1
我现在需要做的是将此文件夹指向
/blog此实例。我想我们必须使用 Amazon Route 53 来做到这一点？我甚至尝试过这样做，但显然我可以创建一个 CNAMEblog.myapp.com而不是文件夹/blog。我们真的希望它位于www.myapp.com/blog。我应该使用类似的东西.htaccess吗？
简短的回答。
简而言之，您所描述的内容（正如您所描述）无法工作。虽然blog/是主 Amazon EC2 实例上的目录/文件夹/路径www.myapp.com，但您混淆了服务器和 Web URL 路径的概念；又称：目录、文件夹和路径。
如果您要启动新的 Amazon EC2 实例，则需要设置一个全新的服务器。两台服务器具有相同的基本主机名，www.myapp.com但只有一台具有有效路径，这种/blog情况是不可能发生的。
如果您想将此站点拆分到多个服务器，最好的办法是设置带有子域的新 Amazon EC2 实例blog.myapp.com，然后将所有流量从第一个实例重定向www.myapp.com/blog到该新子域/主机。
更多细节如下。
较长的答案。
因此您有两个 Amazon EC2 实例：
- EC2 实例 1：正在主持
www.myapp.com。 - EC2 实例 2：您想主持
www.myapp.com/blog。
首先，这与 Amazon 的 DNS 服务 Amazon Route 53 完全无关。Amazon Route 53 所做的只是管理主机名和目标 IP 地址等内容的 DNS 条目。理解这一点的一个简单方法是/URL 中第一个路径 ( ) 左侧的任何内容都是主机名。因此在您的示例中：
www.myapp.com/blog
有问题的主机名是www.myapp.com。
www.myapp.com/blog因此，尝试“重定向”EC2 实例 1到EC2 实例 2通过 CNAME 进行复制是绝对不可能的。从技术上讲，这是不可能的，原因如下：
/首先，永远不能为URL右侧的路径数据设置 DNS 条目。- 其次，你基本上是在说你想要EC2 实例 1和EC2 实例 2拥有完全相同的主机
www.myapp.com名仅有的这EC2 实例 2blog/从你的问题所暗示的方式来看，这在技术上是不可能的。
更现实的解决方案是通过 Amazon Route 53 设置新的子域，因此新的 Amazon EC2 实例设置将如下所示：
- EC2 实例 1：正在主持
www.myapp.com。 - EC2 实例 2：将主持
blog.myapp.com。
在这种情况下，您可以设置 Apache 重写规则，强制所有到 的流量请求www.myapp.com/blog转到。使用以下命令blog.myapp.com非常可行且简单：.htaccess
RewriteEngine On
RewriteRule ^blog(/.*)?$ http://www.newdomain.com/ [R=301]
您只需将其放在.htaccess位于根目录中的文件中www.myapp.com，这将重定向来自EC2 实例 1去blog/到blog.myapp.com。
还有一件事：使用 Apache 反向代理的优点/缺点。
以上所述评论者确实提出了设置 Apache 反向代理的潜在用途是将请求传输www.myapp.com/blog到EC2 实例 1到blog.myapp.comEC2 实例 2。是的，这会技术上实现了原始问题概述的目标，但它带来了一个潜在的麻烦：
- 设置 Apache 反向代理的复杂性：现在我并不是说反向代理的概念太复杂以至于普通用户无法学会如何使用它。一旦你掌握了它，它实际上很容易理解。但复杂性来自于必须调整 Apache 配置并在设置的整个生命周期内管理这些配置。例如，在一些 Web 开发商店中，这将被视为 DevOps 任务。而一些开发人员可能不想处理像这样的非常见 DevOps 任务。
- 反向代理意味着两个服务器都获得流量：由于反向代理基本上是将流量从一台服务器路由到另一台服务器的“管道”，因此发往EC2 实例 2仍需经过EC2 实例 1。如果设置单独的 Amazon EC2 实例的目的是确保一个服务器不会影响另一个服务器，则反向代理可能会出现问题。假设大量流量（来自真实用户或攻击）流向
www.myapp.com/blog，会发生什么？EC2 实例 1获得流量以及EC2 实例 2；因此两台服务器都可能存在漏洞。相比之下，简单地RewriteRule将流量反弹到子域在负载方面是轻量级/可忽略不计的，而且由于大多数用户无论如何都会访问子域上的博客blog.myapp.com，因此两台服务器都与各自获得的流量隔离/分离。 - 如果主服务器发生故障，则两个服务器都无法访问：非常容易理解。如果EC2 实例 1正在管理 的流量
www.myapp.com/blog以及 的核心内容www.myapp.com，如果该服务器出现故障，则两个网站都无法访问。通过拥有 这样的子域，blog.myapp.com意味着即使 的主服务器www.myapp.com出现故障，blog.myapp.com仍然可以访问。
也就是说，如果你想探索使用 Apache 反向代理设置，我在 Server Fault 上有两个答案-这个和这个—解释基本配置和设置。
请注意，这些帖子重点介绍了 Solr 和其他使用端口的 Java/Tomcat 应用程序8080，以及我如何使用 Apache 反向代理来简化我的生活，因为在我看来，Tomcat 的配置/管理非常麻烦。Apache 反向代理允许我使用相对容易理解的 Apache 配置来管理站点的前端 Web 访问，而不必处理 Tomcat 的怪癖。但总体概念可以轻松地从 Apache 到 Apache 反向代理设置的使用中进行调整。