转到你的桶的静态网站托管设置 设置“Error document”为index.html。

其他人提到的基于S3/Redirect的方法有一些问题。

多重重定向发生在应用程序的路径被解析时。例如:www.myapp.com/path/for/test被重定向为www.myapp.com/#/path/for/test 由于您的SPA框架的操作，当“#”出现和消失时，url栏中有一个闪烁。 seo会受到影响，因为——‘嘿!这谷歌迫使他的手重定向 Safari对你的应用程序的支持值得一试。

解决方案是:

Make sure you have the index route configured for your website. Mostly it is index.html Remove routing rules from S3 configurations Put a Cloudfront in front of your S3 bucket. Configure error page rules for your Cloudfront instance. In the error rules specify: Http error code: 404 (and 403 or other errors as per need) Error Caching Minimum TTL (seconds) : 0 Customize response: Yes Response Page Path : /index.html HTTP Response Code: 200 For SEO needs + making sure your index.html does not cache, do the following: Configure an EC2 instance and setup an nginx server. Assign a public ip to your EC2 instance. Create an ELB that has the EC2 instance you created as an instance You should be able to assign the ELB to your DNS. Now, configure your nginx server to do the following things: Proxy_pass all requests to your CDN (for index.html only, serve other assets directly from your cloudfront) and for search bots, redirect traffic as stipulated by services like Prerender.io

我可以提供更多关于nginx设置的细节，请留下一张便条。经历了惨痛的教训。

一旦云前端分发更新。使您的云前缓存失效一次，使其处于原始模式。 在浏览器中点击url，一切都应该是好的。

这是切题的，但这里有一个提示，对于那些使用Rackt的React Router库和(HTML5)浏览器历史，想要在S3上托管的人。

假设一个用户在s3托管的静态网站上访问/foo/bear。根据David之前的建议，重定向规则将把它们发送到/#/foo/bear。如果您的应用程序是使用浏览器历史记录构建的，那么这样做不会有太大的好处。然而，你的应用程序在这一点上加载，它现在可以操纵历史。

在我们的项目中包括Rackt历史(参见React Router项目中的使用自定义历史)，你可以添加一个侦听器，它可以感知哈希历史路径，并根据需要替换路径，如下例所示:

import ReactDOM from 'react-dom';

/* Application-specific details. */
const route = {};

import { Router, useRouterHistory } from 'react-router';
import { createHistory } from 'history';

const history = useRouterHistory(createHistory)();

history.listen(function (location) {
  const path = (/#(\/.*)$/.exec(location.hash) || [])[1];
  if (path) history.replace(path);
});

ReactDOM.render(
  <Router history={history} routes={route}/>,
  document.body.appendChild(document.createElement('div'))
);

回顾一下:

David的S3重定向规则将/foo/bear定向到/#/foo/bear。 您的应用程序将加载。 历史侦听器将检测#/foo/bear历史符号。 用正确的路径替换历史记录。

链接标签将按预期工作，所有其他浏览器历史功能也是如此。我所注意到的唯一缺点是在初始请求时发生的间隙重定向。

这是受到AngularJS的一个解决方案的启发，我怀疑它可以很容易地适应任何应用程序。

在CloudFront的帮助下，不需要url黑客就可以很容易地解决这个问题。

创建S3桶，例如:react 使用以下设置创建CloudFront发行版: 默认根对象:index.html 来源域名:S3桶域名，例如:react.s3.amazonaws.com 转到错误页面选项卡，单击创建自定义错误响应: HTTP错误码:403:禁止(404:未找到，在S3静态网站的情况下) 自定义错误响应:是 响应页面路径:/index.html HTTP响应码:200:OK 点击创建

对于这个问题，我有4种解决方案。前三个问题已经在答案中提到了，最后一个是我的贡献。

Set the error document to index.html. Problem: the response body will be correct, but the status code will be 404, which hurts SEO. Set the redirection rules. Problem: URL polluted with #! and page flashes when loaded. Configure CloudFront. Problem: all pages will return 404 from origin, so you need to chose if you won't cache anything (TTL 0 as suggested) or if you will cache and have issues when updating the site. Prerender all pages. Problem: additional work to prerender pages, specially when the pages changes frequently. For example, a news website.

我的建议是使用选项4。如果预先呈现所有页面，预期页面将不会出现404错误。页面将正常加载，框架将作为一个SPA进行控制和正常工作。还可以设置错误文档以显示通用的error.html页面和重定向规则，将404错误重定向到404.html页面(不带hashbang)。

关于403禁忌错误，我不让它们发生。在我的应用程序中，我认为主机桶中的所有文件都是公共的，我用具有读权限的everyone选项设置了这一点。如果您的站点有私有页面，让用户看到HTML布局应该不是问题。您需要保护的是数据，这是在后端完成的。

此外，如果你有私有资产，比如用户照片，你可以将它们保存在另一个bucket中。因为私有资产需要与数据同样的关注，并且不能与用于托管应用程序的资产文件进行比较。

既然问题仍然存在，我想我提出另一个解决方案。 我的情况是，我想在合并之前自动将所有拉请求部署到s3进行测试，使它们可以在[mydomain]/pull-requests/[pr number]/上访问 (例如www.example.com/pull-requests/822/)

据我所知，没有s3规则的场景允许在一个桶中使用html5路由有多个项目，所以上面大多数投票建议适用于根文件夹中的项目，不适用于自己子文件夹中的多个项目。

所以我把我的域指向我的服务器，在那里遵循nginx配置做的工作

location /pull-requests/ {
    try_files $uri @get_files;
}
location @get_files {
    rewrite ^\/pull-requests\/(.*) /$1 break;
    proxy_pass http://<your-amazon-bucket-url>;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @get_routes;
}

location @get_routes {
    rewrite ^\/(\w+)\/(.+) /$1/ break;
    proxy_pass http://<your-amazon-bucket-url>;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @not_found;
}

location @not_found {
    return 404;
}

它尝试获取文件，如果没有找到，则假设它是html5路由并尝试。如果你在angular的404页面中没有找到路由，你将永远不会到达@not_found，而会返回angular 404页面而不是not found files，这可以通过在@get_routes中添加If规则来修复。

我不得不说我在nginx配置和使用regex方面感到不太舒服，我得到了这个工作，经过了一些试验和错误，所以虽然这是有效的，但我相信有改进的空间，请分享你的想法。

注意:如果在s3配置中有重定向规则，请删除它们。

顺便说一下，在Safari中工作