444 Connection Closed Without Response (nginx)

Problem

A request to your server comes back with nothing. The connection opens, the request goes out, and then the socket closes without a single byte of response. curl reports curl: (52) Empty reply from server, Postman labels it 444 Connection Closed Without Response, and browser tools show a failed request with no status code. Nowhere in that exchange did a server send 444 — the code only names the nginx behavior that produced the silence.

Symptoms

• curl exits with code 52 and the message Empty reply from server.
• Postman, Insomnia, or an API client shows a 444 with no headers and no body.
• The request reaches the server (the TCP connection is accepted) but no HTTP response comes back.
• Some requests work and others get dropped — often split by path, User-Agent, Host header, or source IP.
• The nginx access.log shows 444 in the status field for the dropped requests, or shows nothing at all.

What 444 Actually Means

444 is not part of HTTP. It is an nginx-specific instruction: when a location or server block hits return 444;, nginx closes the connection immediately and sends nothing — no status line, no headers, no body. RFC 9110 has no such code, and no byte carrying “444” ever crosses the network. That is by design. The point of 444 is to spend as little as possible on a request you have already decided to refuse: no error page, no explanation, no confirmation that anything is even listening.

This changes how you have to read the failure. A normal rejection — 403, 429, 502 — is a conversation: the server tells you it saw the request and chose to say no. A 444 is a hang-up. From the client’s side, an intentional return 444 and a server that crashed mid-write look identical, because both leave you holding an open socket that went quiet. So the first question is never “what’s wrong with my request” — it is “did something deliberately drop this, or did something break?”

Most of the time it was deliberate. Operators wire return 444 into a few well-worn places: requests to a bare IP with no valid Host header, traffic with the wrong (or missing) SNI on an HTTPS listener, User-Agents on a blocklist, requests to paths that only vulnerability scanners ask for, or a rate-limit limit_req zone configured to drop rather than answer with 429. Cloudflare and other proxies in front of nginx can produce the same empty-reply symptom when they refuse a connection. The pattern that gives it away: the drop is selective. Change the Host header, the SNI, or the source, and the same URL suddenly answers.

Top 3 Causes

1. A deliberate return 444 rule matched your request. A config block drops bare-IP requests, a bad Host or SNI, a blocklisted network, or a scanner-shaped path. The tell: the drop is consistent for one shape of request and disappears when you fix the Host header, use the real hostname for SNI, or come from a different IP. grep -r "444" /etc/nginx on the server finds the rule fast.
2. Wrong protocol or SNI hitting the listener. Plain HTTP sent to an HTTPS-only port, or a TLS handshake with no/incorrect SNI on a server that requires it, gets cut before any HTTP response. The tell: the failure tracks with how you connect (scheme, port, hostname) rather than what you request, and switching http:// to https:// or fixing the hostname changes the result.
3. The upstream died mid-response — no 444 rule involved. An application worker crashed, was OOM-killed, or the upstream closed the socket before nginx could relay a response, so the client gets an empty reply that looks just like a 444. The tell: it is intermittent and correlates with load, deploys, or memory pressure, and the nginx error.log shows upstream prematurely closed connection rather than a clean 444 in the access log.

Diagnose with DechoNet

• HTTP Check tells you whether the host returns a real HTTP response at all, and what final code it lands on — the fastest way to separate “the server answers, just not to me” from “the server drops this request shape.”
• Port Check confirms the target port is actually open and accepting connections, so you know the empty reply is a deliberate hang-up rather than a closed or filtered port.
• SSL Check inspects the TLS handshake and certificate, which surfaces the SNI/hostname mismatches and HTTP-to-HTTPS-port errors that make an HTTPS listener drop you with no response.

Resolution Checklist

• Reproduce with curl -v and confirm you get (52) Empty reply from server — verbose output shows whether the connection was accepted and where it went silent (before or after TLS).
• Send the request with the correct Host header and hostname-based SNI, not a bare IP — many 444 rules exist precisely to drop bare-IP and wrong-Host traffic.
• On the server, run grep -rn "444" /etc/nginx/ to find any return 444; and read what condition guards it (Host, $http_user_agent, map, limit_req, geo/IP allow-lists).
• Check error.log for upstream prematurely closed connection or worker OOM/segfault — if you see those, this is a crash, not a rule, and the fix is in the app, not nginx.
• Confirm scheme and port line up: plain HTTP to a ssl-only listener produces the same empty reply; use https:// and the right port.
• If it is a rate-limit drop, decide whether silently closing is what you want, or switch the zone to answer 429 with a Retry-After so legitimate clients can back off.

When to Escalate

• If the 444 originates from a CDN or proxy in front of nginx (Cloudflare, a load balancer, an ingress controller), the drop rule may live there, not in your nginx config — check the edge’s firewall, bot, and rate-limit rules before touching the origin.
• If error.log shows upstream crashes rather than a clean 444, treat it as an application stability problem: capture the timing against deploys and traffic, and investigate memory limits, worker timeouts, and the upstream’s own logs rather than the nginx rule set.