444 は実際の HTTP ステータスコードではありません。nginx の特別な値で、return 444; と指定すると、nginx はレスポンスヘッダーもボディも送らずに接続を閉じます。444 が現れるのは nginx のアクセスログの中だけで、クライアントがこれを受け取ることはありません。
管理者はこれを使って、不要なトラフィックを低コストで遮断します。たとえば、未知の Host ヘッダーを持つリクエスト、wp-login.php や .env ファイルを探るスキャナー、ブロック対象のユーザーエージェントです。クライアントから見ると単に接続が閉じられるだけで、ブラウザーには ERR_EMPTY_RESPONSE などのエラーが表示され、curl は「Empty reply from server」と報告します。
サイトが Cloudflare の背後にある場合は、Cloudflare がオリジンから空のレスポンスを受け取るため、訪問者には代わりに 520 が表示されます。
レスポンス例
HTTP
# 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 とリダイレクトチェック
レスポンスが送られないため、クローラーはステータスコードではなく接続エラーを記録します。Google はこうしたエラーをサーバーエラーと同様に扱うため、クロールが遅くなり、問題が続けばページはインデックスから削除されます。444 のルールが不要なトラフィックだけに一致し、本物のクローラーには決して一致しないようにしてください。表示できるステータスがないため、リダイレクトチェッカーはそのホップを接続エラーとして報告します。
よくある原因と主な用途
- デフォルトの
serverブロックが、return 444;で未知のホスト名へのリクエストを遮断している場合。 - セキュリティルールが、脆弱性スキャナーや悪質なボットを遮断している場合。
- ルールの範囲が広すぎて正規のリクエストにも一致してしまい、一部の訪問者に空の応答が返っている場合。