The warning means an audit did not find Vary: Accept-Encoding on a response where content may be selected according to a visitor’s compression support. First inspect the response as visitors receive it; then adjust the layer that serves or transforms it. NGINX’s gzip_vary on; or Apache’s compression modules may already handle the header, while a CDN or managed host may control the public response.
What the warning means
Accept-Encoding is a request header: a client uses it to indicate which content encodings it accepts. A server can use that information to choose a compressed or uncompressed representation. Vary is a response header that tells caches which request headers influenced that choice. With Vary: Accept-Encoding, a cache distinguishes responses according to the request’s Accept-Encoding value rather than reusing one representation indiscriminately. See RFC 9110, HTTP Semantics.
RFC 9110 says an origin server “SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests.” The warning is a prompt to check the actual response and its serving path. It does not prove that compression is enabled, that every response needs a manually added header, or that the origin server is responsible for the missing field.
Find which layer serves the response
Check the exact URL flagged by the audit, using the same hostname and public path visitors use. The response may be generated or changed by the application, web server, reverse proxy, CDN, or managed host. If the audit is checking a third-party resource, only the party controlling that resource’s host can change its headers; see Kinsta’s explanation of third-party requests.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors#1 Best Overall
- Origin or application: Check whether it generates compressed and uncompressed responses and whether it already sets
Vary. - Apache or NGINX: Check compression settings and existing response-header rules.
- Proxy, CDN, or managed host: Inspect the response after it passes through that service and review its compression and cache configuration.
Do not add a second or overriding header until you know what the current response contains. An existing Vary value may identify other fields that also affect representation selection.
Fix it on NGINX
Google Cloud external Application Load Balancer setup
For the NGINX configuration described in Google Cloud’s Cloud CDN troubleshooting guide, add these directives in the http section of nginx.conf:
gzip_proxied any;
gzip_vary on;gzip_proxied any; enables compression for requests forwarded by a proxy in this documented setup, and gzip_vary on; adds Vary: Accept-Encoding. The field allows Cloud CDN to keep compressed and uncompressed variants separate; multiple cache fills for the same resource can therefore be expected.
This is guidance for the described Google Cloud proxy arrangement, not a universal NGINX recipe. Confirm that your proxy topology and existing gzip configuration match before applying it. After changing the configuration, restart NGINX using the service-management method for your host so it loads the change. Google identifies /etc/nginx/nginx.conf as a common file location, but installations can differ.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix it on Apache
Check the compression modules first
Apache’s mod_deflate and mod_brotli documentation says these modules send Vary: Accept-Encoding for compressed responses so proxies can serve a cached compressed representation only to clients that sent a suitable Accept-Encoding request. If either module handles the flagged response, inspect its public headers before adding a manual rule. Documentation: mod_deflate and mod_brotli.
If a manual header rule is needed
Apache’s mod_headers can modify response fields in server, virtual-host, directory, and .htaccess contexts. Its Header directive supports operations such as append, merge, and set. Apache generally recommends those operations over add, which can create multiple fields with the same name.
Choose the directive and its placement only after checking the response and the site’s configuration. In particular, avoid using set in a way that discards existing Vary dimensions. If compression selection also depends on another request field—for example, a User-Agent-based exclusion—that field may also need to appear in Vary. When the response depends on information outside request headers, Apache’s compression documentation discusses Vary: *; this prevents compliant caches from reusing the response and is a special case, not a general fix.
When a CDN or managed host is involved
If a CDN or hosting platform produces the public response, an origin-only change may not alter what the audit sees. Check the final response through that provider and review its compression and cache settings. Google’s Cloud CDN guidance demonstrates why the origin and CDN need to handle compressed and uncompressed variants consistently. If you cannot edit server configuration, look for the provider’s controls or ask its support team to confirm which layer sets the public response headers.
Verify the change
- Request the exact flagged URL through the same hostname and CDN or proxy path used by visitors.
- Inspect the response headers. For a response whose representation is selected based on
Accept-Encodingand is cacheable, confirm thatVaryincludesAccept-Encoding; also check whether theContent-Encodingis appropriate to the request. - Compare requests with different
Accept-Encodingvalues. Confirm that the response and any cached variants are handled according to those preferences. - Recheck the audit target. If the header was already present, investigate another flagged URL, a different response layer, or a third-party resource rather than adding a duplicate rule.
These checks follow the selection and cache-reuse semantics in RFC 9110; Google’s Cloud CDN guide describes separate variants for compressed and uncompressed content.
Apply Vary only to fields that affect the response
Vary helps caches retain negotiated representations side by side, but each additional field can increase the number of cache variants. Apache’s caching guide cautions that high-cardinality fields can produce many duplicate cache entries. Include the request fields that actually influence representation selection, preserve existing dimensions, and avoid adding a blanket list.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
