Nginx 444: No Response
Quick reference
| Code | 444 |
|---|---|
| Name | No Response (nginx internal) |
| Category | nginx proprietary — not an HTTP standard code |
| Standard HTTP? | No |
| Client behavior | Sees a connection reset, no HTTP response |
What nginx 444 means
Nginx 444 is not a real HTTP status code — it is a special nginx return code used exclusively in nginx configuration to instruct nginx to close the TCP connection immediately without sending any HTTP response whatsoever. No status line, no headers, no body. The TCP connection is simply dropped.
From the client's perspective, a 444 looks like a network-level connection reset: ERR_CONNECTION_RESET in Chrome, curl: (52) Empty reply from server in curl, or a socket exception in application code. The client receives no indication of what went wrong.
This deliberate silence is the point. 444 is used as a security measure to handle requests that should receive no response — not even an error page that could be scraped for server information. Common targets: requests with no Host header (indicating a direct IP scan), requests to IP addresses rather than domain names, known malicious user agents, and DDoS traffic that should be dropped rather than responded to.
Where 444 appears in logs
Nginx logs 444 as the status code in the access log, even though it never appears in an HTTP response. This allows operators to audit how many requests are being silently dropped and by which rules:
192.0.2.55 - - [26/Apr/2026:10:22:01 +0000] "GET / HTTP/1.1" 444 0 "-" "-" # Status 444, 0 bytes sent, empty referrer and user-agent
The user-agent field is typically empty or a known bot string for 444-triggering requests.
Common nginx 444 configuration patterns
Drop requests without a Host header (direct IP access):
server {
listen 80 default_server;
listen 443 ssl default_server;
server_name _;
# Silently drop any request that doesn't match a named server block
return 444;
}
This is the most common use. Any HTTP request that reaches the server without a matching Host: header (typically automated scanners or bots hitting the server by IP) is dropped silently. Legitimate browser requests always include a Host header matching a configured server_name.
Drop requests from specific IPs or CIDR ranges:
server {
listen 80;
server_name example.com;
# Block known bad IP ranges silently
deny 198.51.100.0/24;
# Or use 444 for specific location:
location / {
if ($remote_addr = "198.51.100.5") {
return 444;
}
# ... normal config
}
}
Drop requests with known malicious user agents:
map $http_user_agent $bad_agent {
default 0;
~*masscan 1;
~*zgrab 1;
~*python-requests 0; # don't block legitimate python
"" 1; # empty user agent = drop
}
server {
listen 80;
server_name example.com;
if ($bad_agent) {
return 444;
}
}
Drop slow HTTP attacks (Slowloris):
server {
listen 80;
server_name example.com;
client_header_timeout 10s;
client_body_timeout 10s;
# nginx returns 408 on timeout by default, but you can
# drop incomplete requests instead:
# Use 444 in a limit_req_zone context for flood protection
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
limit_req zone=req_limit burst=20 nodelay;
limit_req_status 444; # return 444 on rate limit exceeded
}
444 vs 400 and 403 for unwanted requests
| Response | Client sees | Best for |
|---|---|---|
| 444 (no response) | Connection reset | Bots, scanners, DDoS — no info leakage |
| 400 | HTTP 400 error page | Malformed requests from potentially legitimate clients |
| 403 | HTTP 403 error page | Authenticated users with insufficient permissions |
| 429 | HTTP 429 with Retry-After | Rate-limited legitimate clients who should back off |
Use 444 only when the request clearly comes from automated tools or attackers who should get no information. Use proper HTTP codes for legitimate clients who may have made an error — they need the response to understand what went wrong.
Frequently asked questions
Does 444 work in Apache or other web servers?
No. 444 is an nginx-specific internal code. Apache does not have an equivalent built-in mechanism. To achieve the same effect in Apache, use RewriteRule with the [R=444,L] flag or configure the firewall to DROP packets from specific sources instead.
Is 444 better than returning 403 for bots?
For sophisticated bots, yes. A 403 response confirms the server is running and has access control, which bots can use to fingerprint the server. A 444 gives no information at all. For naive bots and scanners, either is equally effective at preventing access.
Can returning 444 cause issues for legitimate traffic?
If the 444 rule is too broad (for example, blocking all requests without checking the Host header while also serving content on the default server), legitimate traffic can be accidentally dropped. Always test configuration changes with a staging environment and monitor access logs for unexpected 444 entries after deploying.
Does Cloudflare or a CDN change how 444 works?
When Cloudflare proxies your domain, Cloudflare's edge servers make requests to your origin on behalf of visitors. If nginx returns 444 to Cloudflare, Cloudflare sees a connection reset from origin and returns a 520 or 502 error to the browser — the visitor never sees 444 directly. Configure 444 rules to allow Cloudflare IP ranges through, then drop everything else.
Related guides
Nginx 499 · HTTP 400 · HTTP 403 · HTTP 429 · Cloudflare 520