First of all, nginx doesn't favor HEAD requests with compression, so the exact mentioned attack doesn't work against a standalone nginx installation.

If you're using nginx in combination with proxying to apache backend, please check your configuration to see if nginx actually passes range requests to the backend:

1) If you're using proxying WITH caching then range requests are not sent to backend and your apache should be safe.

2) If you're NOT using caching then you might be vulnerable to the attack.

In order to mitigate this attack when your installation includes apache behind nginx we recommend you the following:

1. Refer to the above mentioned security advisory CVE-2011-3192 for apache and implement described measures accordingly.

2. Consider using nginx configuration below (in server{} section of configuration). This particular example filters 5 and more ranges in the request:

if ($http_range ~ "(?:\d*\s*-\s*\d*\s*,\s*){5,}") { return 416; }

We'd also like to notify you that for standalone nginx installations we've produced the attached patch. This patch prevents handling malicious range requests at all, instead outputting just the entire file if the total size of all ranges is greater than the expected response.