Php 如何设置Nginx URI以修复重定向到指定位置时的空URI

问题：当使用包含“%”符号的无效URL访问我们的网站时，Nginx抛出400错误请求错误

我们希望将请求重写为（WordPress）404页面，而不是Nginx页面

我尝试了以下方法：

location @400 {
    rewrite ^ /404 break;
}

error_page 400 =307 @400;

但是，这会在Nginx上生成一个500内部服务器错误

Nginx错误日志显示：'。。。读取客户端请求行…，请求：“获取”时，重定向到命名位置“@400”中的空URI

这并非意外，因为原始URL无效

所以我想我想要的是为重写显式地设置URI。如何做到这一点？还是有更好的方法？我对Nginx不太熟悉。

根据代码，代码应该有点不同

这是从文档中复制的重写：

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

问题是它是否会像这样工作：

location 400 {
    error_page 400 =307 http:/example.com/400.html;
}

。。。因为在您链接的github页面上写的是：

如果在配置中使用类似“error_page 400@name”的内容，则 请求可以传递到没有URI集的命名位置，并且 反过来，可能会导致分段错误或其他不良影响 大多数代码都假定已设置URI

通过此更改，nginx将在中捕获此类配置问题 ngx_http_命名为_location（），如果URI为 未设置，返回500

如果这仍然是当前状态，则意味着nginx中会触发400个错误和500个错误。尽管如此，我仍然可以触发400错误，并且仅使用此配置就可以提供自定义的400页：

error_page 400 /400.html;

因此，您也可以尝试配置自定义错误500页，但我从未运行过该页面，而是只显示了nginx的公共500er页

您可以使用此配置进行尝试

error_page 400 /400.html;
error_page 404 /404.html;
error_page 500 /500.html;

如果这是工作，你可以调整3xx代码和更像你想要的。 当然，您也可以在400错误上提交404错误页面，但我从未成功地重写过这样的错误标题：

error_page 404 =301 http:/example.com/new/path.html;

我有同样的目标（返回444而不是定制的错误消息），并且在使用

@named_location

时遇到了同样的问题（对于某些奇怪的请求，特别是当header中没有设置POST/GET/HEAD方法时，Nginx返回其默认的500错误页面，并报告错误日志：

重定向到命名位置时的空URI读取客户端请求时使用“@named_location”

）

，以下是回应：

[……]问题在于，您正试图将在早期请求处理阶段出现的错误（当请求URI尚未解析时）重定向到一个命名位置。命名位置旨在保留现有的请求URI，而将这样一个不完整的请求重定向到一个命名位置可能会在其他部分造成严重问题因此，尝试执行这种重定向会导致“重定向到命名位置时的空URI”错误。这反过来会阻止使用自定义错误页，因此会返回内部错误页。 如果您想处理在早期请求处理阶段出现的错误，例如400错误请求，请考虑使用显式设置URI的错误页。或者，您可以避免尝试重定向这些错误，因为这通常是更安全的方法。 请注意，服务器是nginx这一事实并不是一个信息泄漏。无论如何，它是以多种方式报告的，包括服务器响应头​出于某些原因，您想隐藏nginx版本，可以通过​服务器令牌指令

因此，我将错误自定义更改如下：

error_page 301 400 403 404 500 502 503 504 =444 /444.html;
location = /444.html {
        return 444;
}

# Instead of:
# error_page 301 400 403 404 500 502 503 504 =444 @named_location;
# location @named_locations {
#         return 444;
# }
# which gives the above-mentioned error and returns Nginx's default 500 error page.

---

这似乎解决了这个问题。

不是我想要的答案，但仍然是OP想要的答案。我想做的是返回444（紧密连接）对于没有

Host

头的请求。这些请求都来自扫描仪，我甚至不想让他们知道在该端口上运行的是NGINX服务器（可能毫无意义，但很有趣）。这适用于大多数请求，但某些扫描仪发送了奇怪的请求，导致400个错误请求。对于这些请求，NGINX将返回一个不错的错误页面，这是我不希望看到的。将

错误\u页面400…

与

return 444

组合在一起是可行的，但会保持连接打开。NGINX尝试对444资源？不好。@Gerben因此444的触发器应始终为400？所有内容均为444。即，对于没有

主机

头的任何请求都没有响应。包括格式错误的请求（400）@Gerben正确的444只能由返回。您可能必须编译自己的版本，或者至少实现自己的模块。