如何使用nginx为root和proxy提供静态html？

此配置的目标是：

为主页提供普通html以启动SPA，例如

www.website.com

，

www.website.com/？foo=bar

Python REST API的代理，用于1未捕获的所有内容，例如

www.website.com/foo

，

www.website.com/foo？bar=123

html文件位于

/var/www/website.com/index.html

server {
    listen 80;
    server_name website.com;
    return 301 $scheme://www.website.com$request_uri;
}

server {
    listen 80;
    server_name www.website.com;
    access_log off;

    location = / {
        root /var/www/website.com;
    }
    location / {
        proxy_pass http://127.0.0.1:8000;
    }
}

我在Python端看到对

/index.html

的请求，但失败了。如果我删除

location/

，那么我会看到“欢迎使用nginx”页面，因此

location=/

显然不起作用。我做错了什么？

如果请求以斜杠结束，NGINX将其视为对目录的请求，并尝试在目录中查找索引文件。index指令定义索引文件的名称（默认值为index.html）

检查您是否已在当前范围或任何封闭范围中定义。如果是这样，它将在nginx中创建一个内部重定向，该重定向将匹配Python位置（

location/

）

在您的情况下，我认为至少有两种解决方案：

添加另一个与索引文件显式匹配的位置块：

location = /index.html {
    ...
}

在根位置中使用：

location = / {
    try_files $uri $uri/index.html =404;
}

---

您可以使用404页的

错误

重定向流量。“如果在内部重定向期间不需要更改URI和方法，则可以将错误处理传递到指定位置。”

此外，您还有语法错误，这就是显示“欢迎”页面的原因

此解决方案如下所示：

---

看起来这正是发生在我身上的事情。有没有办法不重定向直接选择html？你是说

location=/index.html{}

？这将要求用户使用

www.website.com/index.html

，这是另一种选择problem@DavidTan查看更新答案中的

try_files

。@Cyker从技术上讲，这并不完全正确。变量$uri始终存在。它在

=/

位置块中的内容只能是“/”。而

try\u files

-指令执行它所说的操作，它检查文件系统中是否有与

$root

相关的参数匹配的文件。第一个参数是

/

，它是一个目录而不是一个文件，因此不作为响应使用。第二个参数是

//index.html

，它也是无效文件。try_files不会更改$uri，但最后一个参数除外，但在本例中，它是一个

=404

，并不重要。您可以执行类似

try_files/index.html=404

的操作，这样可以解决问题，而且更精确。由于原始问题提到END请求到

index.html

，并且不知道这是否是

index

-指令的结果，因此使用显式

=/index.html

位置更安全。这非常好。由于代理是对缺失内容的一种全面覆盖，因此将其作为404处理程序是有意义的。反过来，如果代理找不到它（或者被代理的应用程序返回404），它将简单地将404页面传递回客户端。

server {
    listen 80;
    server_name www.website.com;
    index index.html;
    root /var/www/www.website.com;

    error_page 404 = @fallback;

    location @fallback {
            proxy_pass http://127.0.0.1:8000;
    }

}