Can a browser ever receive status 444?

No. nginx closes the TCP connection without writing a status line, so the browser reports a network error such as ERR_EMPTY_RESPONSE. The 444 only exists in the nginx access log.

Is 444 better than 403 for blocking bots?

For automated scanners, yes: it costs less bandwidth and reveals nothing about the server. For anything a human could hit, 403 is kinder, because it can explain what happened and how to get access.

Does return 444 work with HTTP/2 and HTTPS?

The directive works in any server block, but on HTTPS the TLS handshake happens before nginx sees the request, so a catch-all still needs a certificate. Since nginx 1.19.4, ssl_reject_handshake on refuses the handshake for unknown names instead.

HTTP status code · Unofficial, used by nginx

444 No Response

444 is an nginx-only code that means nginx closed the connection without sending a single byte of response. You will only ever see it in your own access log, usually because a `return 444;` rule caught a scanner, a bot or a request for an unknown host name.

Facts about this status code
Class	4xx/5xx, Unofficial codes (nginx, Cloudflare)
Also known as	Connection Closed Without Response
Defined in	nginx docs: return directive
Cacheable by default	No; nothing is sent, so there is nothing to cache
Safe to retry	No; nginx drops the connection on purpose and will do it again
Relevant headers	None specific to this code

What 444 means

The nginx documentation for the return directive says it plainly: the non-standard code 444 closes a connection without sending a response header. Internally it is NGX_HTTP_CLOSE. The number is written to the access log so you can count these requests, but it never travels over the network, so no browser or API client ever receives a status of 444.

On the other end, the client sees a connection that ended with no reply at all. curl prints "Empty reply from server" (exit code 52) and Chrome shows ERR_EMPTY_RESPONSE. That is the point: a bot probing /wp-login.php or hitting your server by bare IP gets no page, no headers and no hint about what software is running.

When to use it

In a default_server block, to drop requests whose Host header matches none of your sites, which is most of the scanner traffic that hits a public IP.
For paths or user agents you never want to serve, such as vulnerability probes for software you do not run.
Avoid it for anything a real person might hit: they get a blank browser error with no explanation, where a 403 or 404 would tell them something.

Common causes

If you are visiting the site

The server has a rule that silently drops your request, often because you reached it by IP address or an old domain it no longer serves.
Your user agent, path or IP matched a block list aimed at bots.

If you run the server

A `return 444;` in a catch-all server block, a location block or an if on $http_user_agent.
A DNS record for a new domain points at the server before a matching server_name exists, so the request falls through to the 444 default server.

How to fix it

If you are visiting the site

Use the site address the owner publishes instead of an IP or an outdated domain.
If a normal browser gets ERR_EMPTY_RESPONSE on a site you are supposed to reach, tell the site owner; nothing on your side will change it.

If you run the server

Find which rule fired: grep the access log for " 444 " and compare the Host header and path with your server_name and location blocks.
Add the missing server_name for a legitimate domain, or narrow the user agent pattern that caught real clients.
For HTTPS catch-alls, pair the 444 block with ssl_reject_handshake on (nginx 1.19.4+) so you do not need a certificate for unknown names.

How to diagnose 444

Nginx

# Drop requests for host names you don't serve (bare IP, scanners)
server {
    listen 80 default_server;
    server_name _;
    return 444;
}

# HTTPS catch-all without a certificate (nginx 1.19.4+)
server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

# Inside a real site: drop probes for software you don't run
location ~* ^/(wp-login\.php|xmlrpc\.php) {
    return 444;
}

Shell

# What a client sees
curl -v http://SERVER_IP/
# * Empty reply from server
# curl: (52) Empty reply from server

Commonly confused with

444 vs 403: 403 is a real response with headers and usually a body explaining the refusal; 444 sends nothing and just hangs up.
444 vs 499: Both are nginx log-only codes, but 444 means nginx closed the connection and 499 means the client did.

Frequently asked questions

Can a browser ever receive status 444?: No. nginx closes the TCP connection without writing a status line, so the browser reports a network error such as ERR_EMPTY_RESPONSE. The 444 only exists in the nginx access log.
Is 444 better than 403 for blocking bots?: For automated scanners, yes: it costs less bandwidth and reveals nothing about the server. For anything a human could hit, 403 is kinder, because it can explain what happened and how to get access.
Does return 444 work with HTTP/2 and HTTPS?: The directive works in any server block, but on HTTPS the TLS handshake happens before nginx sees the request, so a catch-all still needs a certificate. Since nginx 1.19.4, ssl_reject_handshake on refuses the handshake for unknown names instead.

Last reviewed September 27, 2026 by Arielton Oberek.