444 is not a real HTTP status code. It is a special value in nginx: return 444; tells nginx to close the connection without sending a response header or body. The 444 appears only in nginx's access log; the client never receives it.
Administrators use it to drop unwanted traffic cheaply, such as requests with unknown Host headers, scanners probing for wp-login.php or .env files, or blocked user agents. For the client, the connection simply closes: browsers show an error such as ERR_EMPTY_RESPONSE, and curl reports "Empty reply from server".
If the site is behind Cloudflare, visitors see 520 instead, because Cloudflare received an empty response from the origin.
Example response
# Nothing is sent back. The client only sees the connection close:
$ curl -i http://example.com/wp-login.php
curl: (52) Empty reply from server
# nginx access.log
203.0.113.7 - - [06/Nov/2026:10:15:32 +0000] "GET /wp-login.php HTTP/1.1" 444 0 "-" "curl/8.11.1"SEO and redirect checking
Because no response is sent, crawlers record a connection error instead of a status code, and Google treats such errors like server errors: crawling slows down and, if the problem persists, pages are dropped. Make sure 444 rules only match unwanted traffic and never real crawlers. A redirect checker reports a connection error for such a hop, since there is no status to show.
Common causes and use cases
- A default
serverblock drops requests for unknown host names withreturn 444;. - Security rules drop vulnerability scanners and bad bots.
- A rule that is too broad also matches legitimate requests, so some visitors get empty replies.