When Varnish Logs Out Your Magento Customers : It’s Not Magento’s Fault

In the complex architecture of a high-performance Magento 2 store, identifying the source of a session-related bug can feel like finding a needle in a haystack. While troubleshooting a recent issue where customers were being unexpectedly logged out while navigating their dashboard, a development team discovered that the culprit wasn’t the application logic or the database, but rather the caching layer sitting in front of it: Varnish.

This breakdown explores the technical oversight within a Varnish VCL (Varnish Configuration Language) file that led to broken user sessions and how a simple route exclusion restored functionality.

The Problem: Mysterious Session Loss

The issue manifested specifically when users interacted with the customer dashboard. The implementation of the store appeared functional; standard Magento operations were running smoothly, and the login process itself worked without error. However, a specific pattern emerged: whenever a customer attempted to access links associated with a custom route, they were immediately booted from their session.

In this instance, the custom route being used for dashboard-related content was: /sales/…

To the end-user, this looked like a critical failure of the website’s security or session management. From a developer’s perspective, it initially seemed like a Magento problem perhaps a misconfigured session cookie life, a Redis session storage issue, or a conflict in the PHP code handling the customer session. However, after deep-diving into the application code, it became clear that Magento was behaving exactly as it should given the data it was receiving. The data it wasn’t receiving, however, was the session cookie.

The Root Cause: Overzealous Varnish Rules

The investigation shifted from the application layer to the server configuration, specifically the Varnish VCL. Varnish is used to significantly improve Magento’s performance by caching fragments of the site and serving them directly from memory, reducing the load on the web server.

To maximize the “cache hit rate,” developers often implement rules to strip cookies from requests. This is because Varnish, by default, will not cache a page if it sees a Cookie header, as cookies usually imply user-specific data that shouldn’t be shared with others.

The team found the following logic in their VCL configuration:

Code snippet

How This Rule Functions

The logic above follows a “whitelist” approach:

1. It checks the request URL (req.url).
2. It looks for specific prefixes that must remain dynamic (like the checkout, the cart, or the admin panel).
3. The !~ operator means “does not match.”
4. If the URL does not match any of those excluded paths, Varnish executes unset req.http.Cookie.

This instruction effectively “blinds” the backend (Magento) to the user’s session. When the req.http.Cookie is unset, the request arrives at the Magento application looking like a brand-new, anonymous guest request. Because the custom /sales/ route was missing from this exclusion list, Varnish stripped the session cookie every time a user clicked a link in that directory. Magento, seeing a request for a protected dashboard page without a valid session cookie, did the only logical thing: it treated the request as unauthenticated and ended the session.

The Fix: Updating the VCL Whitelist

The solution was straightforward but required a precise update to the Varnish configuration to ensure the custom route was respected as an “authenticated-only” zone.

The team updated the regex pattern to include the /sales route, ensuring that any request directed to that path would retain its headers, including the vital session cookies.

The updated configuration rule:

Code snippet
# Added ‘sales’ to the exclusion list to preserve cookies

By adding sales to the pipe-delimited list of excluded paths, Varnish now permits the Cookie header to pass through to the backend. This allows Magento to identify the user via their session ID, verify their authentication status, and serve the dashboard content without triggering a logout.

The Takeaway: Performance vs. Persistence

This scenario serves as a vital reminder for Magento developers and DevOps engineers: The unset req.http.Cookie rule is a double-edged sword.

While this rule is highly effective for improving cache performance on public-facing pages (like CMS pages, category listings, and product details), it should never be applied to authenticated routes or paths that require user-specific data.

Key Lessons Learned:

• Audit Custom Routes: Whenever a new extension is installed or a custom module is developed that introduces a new URL prefix (e.g., /loyalty , /subscriptions , or in this case, /sales ), that route must be audited against the Varnish VCL.
• Varnish is Part of the Stack: Troubleshooting session issues in Magento requires a full-stack perspective. Don’t stop at the PHP code; look at the headers being passed through the proxy.
• The Danger of “Silent” Failures: This was a subtle issue. The site didn’t “crash,” and there were no error logs in Magento indicating a bug. The session simply vanished because the communication between the browser and the server was being filtered by the caching layer.

Ultimately, maintaining a high-performance Magento store requires a delicate balance. You want Varnish to be aggressive enough to keep the site fast, but precise enough to stay out of the way when a customer is trying to manage their account. Always ensure your “authenticated routes” are clearly defined and protected within your Varnish configuration.