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.
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.
Configuring 444
The return directive accepts 444 in server,
location, and if contexts. nginx stops
processing immediately and closes the connection
without writing a status line, headers, or body.
A catch-all server block drops requests carrying an
unrecognized Host header, which removes most
automated scanning from the logs of the real virtual
hosts.
server {
listen 80 default_server;
listen 443 ssl default_server;
ssl_certificate /etc/nginx/ssl/dummy.crt;
ssl_certificate_key /etc/nginx/ssl/dummy.key;
return 444;
}
Conditions and paths work the same way.
if ($http_user_agent ~* (badbot|scraper)) {
return 444;
}
location /wp-admin/ {
return 444;
}
Rate limiting reaches the same outcome. Both
limit_req_status and limit_conn_status accept any
code between 400 and 599, so setting either to 444
turns a rejected request into a silent drop rather
than a 503.
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_req_status 444;
Closing the socket normally sends a FIN. Enabling
reset_timedout_connection sends a TCP RST instead,
releasing the socket memory immediately rather than
leaving the socket in FIN_WAIT1, and the directive
covers
444 alongside timed-out connections from nginx 1.15.2
onward.
reset_timedout_connection on;
An error_page 444 line passes a configuration test
and never takes effect, because nginx terminates the
request before consulting the error page table. Using
444 as the target of an error_page is the working
form.
error_page 495 496 497 = @drop;
location @drop {
return 444;
}
Other servers reach the same behavior under
different names. Caddy uses an abort directive,
HAProxy a silent-drop action, and Apache offers no
direct equivalent, answering every request with a
status.
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, route the 403 to a named location
returning 444:
allow 192.168.1.0/24;
deny all;
error_page 403 = @drop;
location @drop {
return 444;
}
The named @drop location sits directly inside the
server block, since named locations do not nest
inside other location blocks.
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.