我已经解决了这个差不多半天了。 🙁
在我的笔记本电脑上运行的Nginx上，我不使用proxy_pass，这个try文件工作的很好。 我写的JavaScript web应用程序在加载页面时执行客户端路由。 但是，如果网页被刷新，则是接收请求的服务器。
我在我的笔记本电脑上运行我的Nginxconfiguration
location /viewer { try_files $uri /viewer/index.html; } 使用上面的configuration，如果我请求在我的文件系统上不存在的http：// localhost / viewer / getservice ，我将与/viewer/index.html一起提供服务。 这工作很好！
但是，我们在工作中有不同的configuration。 我们所有的静态文件/ html页面都存储在上游的S3存储桶中。
这是我们的工作configuration
location /viewer { proxy_pass http://s3-bucket-server/viewer; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Origin' $cors_header; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,Keep-Alive,User-Agent,Origin,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type'; }
当我像这样访问它时，上面的configuration很好用， http://internal-app.docs.svr/viewer 。 我可以点击我们的左侧导航，这改变了客户端的位置path
http://internal-app.docs.svr/viewer/settings http://internal-app.docs.svr/viewer/docs http://internal-app.docs.svr/viewer/permissions etc
但是，如果假设我在http://internal-app.docs.svr/viewer/permissions并且单击了浏览器，通常会发生的情况是，它会在我们的Web服务器internal- app.docs.svr。 不幸的是，没有nginx位置规则可以处理这个规则。
我想达到的是，当上述情况发生（404），有Nginx服务/viewer/index.html。 我不想要redirect，因为我想保持最后的path。 在这种情况下，它是/viewer/permissions 。 我写的JavaScript应用程序将最终处理/viewer/permissions 。
我终于得到它使用下面的configuration工作
error_page 404 @proxy;
然后
location @proxy { rewrite ^ /viewer/index.html break; proxy_pass http://s3-bucket-server; }