444 No Response
The 444 No Response status code is an nginx directive causing the server to close the HTTP connection without sending any data, including the status code itself.
Usage
The 444 No Response status code instructs nginx to close the connection immediately and send nothing to the client. This code appears only in the nginx logs and is never transmitted over the wire. Blocking malicious HTTP requests is the primary use case, such as requests with illegal Host headers or suspicious patterns.
A typical nginx configuration returns 444 inside a location block or server block to silently drop unwanted traffic.
SEO impact
A 444 sends nothing on the wire, so Googlebot experiences a dropped connection rather than a status code. Google treats such network errors like server errors: crawling slows down, and a URL failing persistently is dropped from the index.
Example
A client sends a request with a suspicious Host header. The nginx server is configured to drop the connection for unrecognized hosts. The 444 status code appears in the nginx access log but no response reaches the client.
Request
GET / HTTP/1.1
Host: malicious.example.re
Response (nginx log entry only)
192.168.1.50 - - [02/Mar/2026:10:15:30 +0000] "GET / HTTP/1.1" 444 0 "-" "curl/8.1.2"
No HTTP response is sent. The connection closes immediately.
How to fix
Search the nginx configuration files for all
return 444 directives. These intentional
connection drops target specific request patterns:
if ($host !~* ^(example\.re)$) {
return 444;
}
Run grep -rn 'return 444' /etc/nginx/ to locate
every rule producing this response. Common
locations include the default server block
(catching requests for unknown
Host headers), location blocks with
pattern-based deny rules, and if conditions
matching suspicious User-Agent
strings.
Review the nginx access log for the request URI, IP, and User-Agent associated with the 444. Cross-reference this data with the configuration rules to confirm whether the block is intentional or a false positive.
Check deny and allow directives in the server
or location block. A blanket deny all combined
with a limited allow list answers blocked clients
with a 403 response. To drop those connections
silently instead, map the 403 to 444:
allow 192.168.1.0/24;
deny all;
error_page 403 =444;
Placing a bare return 444; in the same block does
not combine with allow and deny. The return
directive runs before access checks, so every
request, including those from allowed IPs, has its
connection dropped.
Verify the Host header in the client
request matches an active server_name directive.
Requests arriving at the default server block
(the catch-all for unrecognized hosts) are the
most common trigger for 444 responses.
Enable the nginx error log at info level to
surface additional detail about why a connection
was dropped:
error_log /var/log/nginx/error.log info;
This status code is always an intentional server decision. The fix depends on whether the block rule is correct or misconfigured.
