所以我有一个Nginx服务器设置，应该使用4个服务器块将所有http重定向到https（和非www到www）。
问题是，任何404或不存在的http URL首先获得301重定向到可能是https版本的假设存在（因此创建额外的URL和重定向）。
参见示例：
1）http://example.com/thisurldoesntexit
301重定向
2）https://example.com/thisurldoesntexit
404
有没有办法将用户直接重定向到https 404（网址3）？
答案 0 :(得分：2)
首先，正如已经指出的那样，从一个不存在的页面进行301重定向到单个/notfound名字对象，这是一个非常糟糕的做法，很可能是针对RFC的。
如果用户只是输错了长网址的单个字符，该怎么办？现代浏览器使得回归已经输入的内容以纠正它是非常重要的。用户必须决定您的网站是否值得从头开始重新输入，或者您的竞争对手是否考虑过更好的体验。
如果用户只是简单地按照断开的链接（以非常明显的方式打破）并且可以轻松修复，该怎么办？例如，http://www.example.org/www.example.com/page，其中绝对URL被创建者错误地分类为相对URL，或者可能是像/page.html.这样的URI，最后有一个额外的点。同样地，您将完全混淆用户正在发生的事情，并提供糟糕的用户体验，如果不加考虑，可以很容易地及时更正URL。
但是，更重要的是， 你真正试图解决的是什么问题？！
无论好坏，从http到https方案不加选择地重定向是一种非常常见的做法，而不考虑给定页面是否存在。事实上，如果您使用HSTS，那么http上提供的内容实际上变得毫无意义;带有策略的浏览器甚至不会从那里请求http以外的任何内容。
毫无疑问，为了了解给定页面是否存在，您必须咨询后端。因此，您也可以从后端内部将http重定向到https;但它可能会占用您宝贵的服务器资源，几乎没有额外的好处。
此外，页面的存在与否可能由cookie的内容决定。因此，如果您要求后端必须识别http请求的页面是否存在，那么您将有效地泄露受https保护的私人信息。第一名。 （反过来，如果您的网站没有此类私人信息，那么您可能不应该首先使用https。）
总的来说，整个方法只是一个非常糟糕的想法！
改为考虑 ：
执行 NOT 从所有不存在的网页进行301重定向到单个/notfound页面。非常糟糕的做法，非常糟糕的用户体验。
完全 确定 从http到https进行不加选择的重定向，而不考虑页面是否正确存在。事实上，这不仅是好的，而且是上帝的意图，因为对手不应该能够辨别基于https的网站是否存在给定的页面，所以，如果你确实找到并实现了解决您的“问题”，然后您将有效地创建安全漏洞和数据泄漏。
答案 1 :(得分：0)
使用https://www.drupal.org/project/fast_404模块直接提供404页面而不会过载。
答案 2 :(得分：0)
我建议重定向到404页面是一个糟糕的选择，您应该在错误的网址上提供404。
我陈述这一点的理由是：